Supervise the crash of system plugins.

[garstud]

How to interact with the triggering of errors within the Joomla framework.
More exactly, where is the code that catches errors when a system plugin crashes?
I tried to find it around the execute() method of the CMSApplication (in joomla3) and the doExecute() of the SiteApplication (Joomla4), but I couldn't find it.

In the context of the crash of a plugin which causes a blocking of the site, I would like to execute a treatment.

• What would be the best way to intervene?

[nikosdion]

Joomla 4 uses the Symfony ErrorHandler component as its global error code handler. This is registered in

joomla-cms/libraries/bootstrap.php

Line 55 in e7f5cc1

$errorHandler = \Symfony\Component\ErrorHandler\ErrorHandler::register();

Not that knowing this does you any good as a developer. This part of the code is unreachable to you as a 3PD.

As far as 3PD code goes, the earliest point where we can execute code is normatively the onAfterInitialise event of system plugins which is called by

joomla-cms/libraries/src/Application/CMSApplication.php

Line 739 in 98247b9

$this->triggerEvent('onAfterInitialise');

There are some underhanded ways to load code earlier than that but it falls under “if you have to ask how to do it, you should not be doing it”.

Going back to what you said: “I would like to execute a treatment”.

I know what you are thinking. You can see what broke and figure out which plugin it is based on the namespace in the stack trace so you can disable it. Please don't.

It is very easy to accidentally disable a plugin critical for the operation of the site. I am not talking just about the well-known plugins shipped with Joomla itself. Some third party templates require one or more system plugins. Disabling them breaks the site. There are many more non-obvious examples.

Meanwhile, most of these problems tend to be transient. For example: temporary database connection issues while the DB server is restarting, temporary network timeouts when an interface is restarting / an upstream provider has issues, a stuck OPcache, etc.

Yes, WordPress does disable plugins automatically… and it causes exactly those problems I described. There's a reason this feature and automatic updates are the first two things seasoned WordPress site administrators disable on their sites.

FWIW, we had that idea as well for our own software — before WordPress started doing it. We realised the problems and decided to just implement a feature which sends emails about unhandled exceptions instead, describing it as an auxiliary site debug feature.

[garstud]

Ok I completely understand. Thank you @nikosdion for this detailed answer.
Indeed, this case is a study following feedback from Joomla integrators in my country.
Some report problem while migrating from joomla3 to joomla4 with system plugins.
This can crash the site and the update!

So that's exactly the idea you were quoting that we were thinking of.
I completely understand the problems this can cause, and i agree.

So just to simplify the J3 to J4 migration, there might be some thought to be had in order to activate an "expert" mode to prevent a system plugin from crashing during the migration?

[garstud]

Very interesting @nikosdion.
Just to understand the case where a reactivated plugin crashes, what happens?
It is then necessary a system to activate the plugins by managing the generation of an error?

[nikosdion]

@garstud This is covered in my comment here: #39484 (comment) (see under My Proposal).

Basically, I would like Joomla to tell the user here's where the problem happened, here's the debug info to send to the developer, here's how to get in touch with the developer, and here's how to disable this extension if you need to access your site pronto.

If I missed anything, please do tell me. I am trying to reconcile the use cases and experience levels of a few hundred people in my head. Missing something is expected.

[zero-24]

That's what I was trying to get y'all to do 2 ½ years ago. You just told me I don't know how Joomla is used and what I warned you would happen cannot happen. Here we are, 30 months later, and it looks like I was right.

I will fakt check this thing. I do remember people where talking about that and we have been told 'you can use a system plugin to setup your database connection or do other critical stuff' so the decision was to not do what you suggested above forbexample for that reason.

[garstud]

Ok thank you @nikosdion, I will read your proposal and try to formulate my opinion.

[zero-24]

This is what I had in mind when we where discussing this kind of thing in the pre upgrade checker the last time:

@nikosdion wrote in reply to Fedik:

@Fedik Fair points and they do have reasonable answers 😄

Why a plugins need to be enable at time when executed "update script" and "update SQL"? There nothing to do for them.

Top reason off the top of my head: you are using a MySQL cluster which necessitates installing a custom database driver, only possible with a system plugin. Disabling the plugin would update the (meant to be read-only) slave but not the (meant to be write-only) master.

The other reason is that system plugins are loaded very early in the application boot, before you can run custom code. So in the failure mode that we are discussing here you'd have to disable these plugins in the database. However, this can only be done BEFORE you start the extraction. This means that an extraction problem or a post-install script failure would end up with your site's system plugins being permanently disabled. Let's say that magically this wasn't an issue. Where you'd store the IDs of the system plugins previously enabled? It can't be the session because there's no guarantee it will still exist at the end of the update (especially when you're moving to a new major version). You'd have to store them in the database and modify the post-installation script to use that information. This makes recovery from a failure possible but VERY HARD for the target audience. You could try to solve it by having the application always look for that information in the DB and enable system plugin the next time it boots up, before it looks for system plugins. However, this now opens an exploitable security hole. I can think of at least three fun ways I can hack your site with file-only access and you'd be none the wiser – my evil plugin would never show up enabled and you'd see no modified files.
[...]

Ref: #30913 (comment)

Disabeling extensions at the time of the update was even discused and proposed a few times we have not gone forward for the reason mentiond above for example also here: #30930 (comment)

This would also not solve the problem only on the first view as as soon as we enter step:

Enable those plugins, again logging each plugin being enabled

The sites using isAdmin/isSite will break the backend / frontend again. If anything we could have disabled it but not enabled them again but also that has it drawbacks.

[brianteeman]

Also see #39484

[nikosdion]

It is still a bad idea and @laoneo put it very succinctly in his comment #39484 (comment) This is exactly what would happen when Admin Tools catches a request that cannot be sanitised.

Also see my comment about a lot more real world cases where this thing would BREAK SITES.

Implementing this kind of solution would end up with 3PDs putting their own exception handlers, catching more exceptions than they should, outputting random HTTP headers and then die(). This will make Joomla harder to work with than back in Joomla 1.0.

[garstud]

Ok, thanks @brianteeman for that link that's exactly what I was looking for (didn't find it).
I will follow it closely and participate in the tests ;)

But I also agree with @nikosdion's warning... maybe this feature should only be available to certain people (SUsers?) or if certain settings are enabled (an 'expert' mode?) ?

[brianteeman]

not endorsing it just sharing the link

[nikosdion]

I understand that, I am just saying why this PR is bad. I'll comment on it.