@HLeithner I forgot to mention this. Over the course of last week @laoneo found a way to make the plugins installable without any change in core code! He moved the plugin attribute from <file> to <folder> and Joomla 4.0 handled it beautifully. We confirmed his change on our own company's extensions. That's what I did in the XML manifest.

@HLeithner I forgot to mention this. Over the course of last week @laoneo found a way to make the plugins installable without any change in core code! He moved the plugin attribute from <file> to <folder> and Joomla 4.0 handled it beautifully. We confirmed his change on our own company's extensions. That's what I did in the XML manifest.

perfect one problem less ;-)

moved the plugin attribute from <file> to <folder> and Joomla 4.0 handled it beautifully. We confirmed his change on our own company's extensions. That's what I did in the XML manifest.

Actually you can do this already since 3.4 f90ff60#diff-f1347eb6172ab8188fa384c60a35be15af08dc341072aad5e842e912679234de

@HLeithner any comments for triggerEvent usage here? Otherwise I give it a test and get it merged. Afterwards we can discus if we want to migrate more plugins as suggested by @nikosdion.

@laoneo @HLeithner IMHO the triggerEvent helper method shouldn't disappear forever. I have written a number of plugins which do not use it and my takeaway from this is that the alternative is clunky.

What I'd like to do is create a new trait where event creation and parsing the event results are separate methods. Think of calling something like $resultsArray = $this->getEventResults($this->createEvent('onFoobar', $argumentsArray, CustomEventClass::class)); where the arguments array could be associative (for named arguments) and the CustomEventClass::class could be omitted to use the generic \Joomla\Event\Event class.

Otherwise every time we call an event we need to use the same boilerplate code:

$result = $this->getDispatcher()->dispatch($eventName, $new Event($eventName, $argumentsArray));
$actualResult = !isset($result['result']) || \is_null($result['result']) ? [] : $result['result'];

I would argue that the boilerplate code looks clunky and inscrutable to newcomers. We don't want to dissuade new developers so a couple method calls may be better than lab clean code. What do you think?

Otherwise every time we call an event we need to use the same boilerplate code:

$result = $this->getDispatcher()->dispatch($eventName, $new Event($eventName, $argumentsArray));
$actualResult = !isset($result['result']) || \is_null($result['result']) ? [] : $result['result'];

This is true for J3 events for BC reasons. But for new ones you can use the argument from the event as result as we did in #35396.

In this pr here you can just replace $this->app->triggerEvent() with $this->app->getDispatcher()->dispatch() as there are no arguments and results to work with.

Since the events are not new I wouldn't require a proper event object. But we should get rid of all events without it own class as already discussed.

It would be a great time/pr to do this as part of the refactoring.

As allon already said for new event we can guarantee that $result['result'] exists (and of course should).

If you don't like to do it now or in a future pr, I'm fine with it but as it's also an example PR it would be great if can set a milestone how to do it for events so a refer to this single pr is easier then having a couple of PRs to refer to.

@HLeithner Just to be clear: you'd like me to create Event classes for all the events referenced in this plugin and use them without going through triggerEvent. Say yes and I'll start working on it tonight.

@nikosdion yes when I'm not wrong we discussed this in another Issue that we want to move all legacy events to the "new" event system. And iirc this is possible in a fully b/c way right?

I thought it was a 5.0 goal ? You are right that it can be done b/c as long as the event handlers parse the event arguments positionally instead of by name i.e. [$arg1, $arg2, ...., $argN] = $event->getArguments() AND use the generic \Joomla\Event\Event class for their parameter type hint (or use legacy Joomla 3 event handlers). To make things easier, the docblock should also or–type the specific Event subclass we will be expecting in the future.

Throughout the 4.x release cycle this is how event handlers should be written. Moreover, throughout the 4.x release we need to VERY CLEARLY document these specific event classes, which version they appeared and instruct developers to use them.

When we start working on 5.0 we can type hint with the correct event subclass and use its named arguments.

PS: About the “clearly document” we can also create a trait which generates the correct event class based on the event name. For example, if Joomla has a core event onFoobarScream which should be conveyed through an event object of the class \Joomla\Event\Foobar\Scream our Trait's makeEvent method would return a new \Joomla\Event\Foobar\Scream object with the correct arguments. This would be @deprecated 6.0 and would act as the b/c layer for the events system come Joomla 5.0.

Should I give it a stab? Now that I've worked with events on real world stuff, not just the lab environment I was using back in 2015, I have a much better ‘feel’ for how to do things in a way that doesn't screw the core over in the long term and doesn't screw third party developers over in the short to medium term.

I would like to remove the old event system in j5.0 already and to have all Events have there correct classes already in 4.x ready and used. Maybe the validation have to be more relaxed with deprecation warnings if wrong values are provided.

About the trait I can't follow you for what it's needed maybe you can outline it a bit.

The plan to start on j5 is with release of 4.1, at this point we will branch out 4.2 and 5.0, we also have a project to migrate to PSR-12 withing 4.1 which is maybe too late... so it's possible that we do this in 4.1.x or 4.2. to reduce the impact on upmerge to 5.0 but I hadn't the time since the j3.10 phpunit and 8.0 comes into my way...

I was busy doing releases today. Tomorrow I'll write a POC as a console plugin so you can see what the Trait would look like and how we can tackle b/c. It's about 80% there in my head, I need to put it into code and get it to the next 20% (to make sure I don't mess up b/c with J3 plugins running in Joomla 4). Then we can get back on the discussion about this PR and how much we want to do now.

But as a general idea, yeah, I'd agree that if we convert all of the plugin events at least two minor releases before 5.0 we can definitely remove legacy event handling from 5.0.

Why two minor releases? Because this would allow for smooth updates based on my experience with the 3.x to 4.0 migration ? In August 2021 I had to simultaneously support 3.9, 3.10 and 4.0. This allowed clients using my software on Joomla 3.9 to follow a dead simple upgrade procedure: update extensions, backup, upgrade to Joomla 3.10, backup, upgrade to 4.0, done. My limiting factor was what the penultimate version of 3.x (i.e. 3.9) supported. In those versions I couldn't use any code that only appears in 3.10 and 4.0. So, if we're touching something as fundamental as events handling we should most definitely do it with this kind conservative upgrade process in mind.

Regarding PSR-12 I am NOT a big fan on two accounts:

1. Namespace bundling in use statements. Sure it makes sense if you use Vim to write PHP. Any half–decent IDE handles imports automatically... as long as you don't do bundling. Enforcing bundling makes for busywork AND simultaneously makes it harder to find all uses of classes when they are deprecated, moved to a different namespace etc.
2. Open braces at the end of the line. Yeah, it makes for more compact code and date back to K&R when 80x25 terminals were expensive. We now code in 27" monitors (or larger), typically in vertical orientation. Meanwhile, having braces like that makes the code harder to read and leads to stupid bugs. Why?!
3. 80 characters soft limit for line length. Again, it's no longer 1975, we are not limited to 80x25 terminals. 120 characters is more than reasonable, even on a 13" laptop with sidebars open in any decent IDE (phpStorm, Netbeans, Eclipse, ...).

I think Joomla should have its own code style, like it does now, because the objective of code is to a. perform a certain function; b. make it easily readable; c. minimise busywork and d. minimise the possibility of stupid bugs. PSR-12 fails miserably in the latter three. At some point CS people need to understand the historical context of K&R before trying to apply it indiscriminately on all modern code.

I was busy doing releases today. Tomorrow I'll write a POC as a console plugin so you can see what the Trait would look like and how we can tackle b/c. It's about 80% there in my head, I need to put it into code and get it to the next 20% (to make sure I don't mess up b/c with J3 plugins running in Joomla 4). Then we can get back on the discussion about this PR and how much we want to do now.

Sounds great thanks

Why two minor releases? Because this would allow for smooth updates based on my experience with the 3.x to 4.0 migration ? In August 2021 I had to simultaneously support 3.9, 3.10 and 4.0. This allowed clients using my software on Joomla 3.9 to follow a dead simple upgrade procedure: update extensions, backup, upgrade to Joomla 3.10, backup, upgrade to 4.0, done. My limiting factor was what the penultimate version of 3.x (i.e. 3.9) supported. In those versions I couldn't use any code that only appears in 3.10 and 4.0. So, if we're touching something as fundamental as events handling we should most definitely do it with this kind conservative upgrade process in mind.

I know the pain...

Regarding PSR-12 I am NOT a big fan on two accounts:

1. Namespace bundling in use statements. Sure it makes sense if you use Vim to write PHP. Any half–decent IDE handles imports automatically... as long as you don't do bundling. Enforcing bundling makes for busywork AND simultaneously makes it harder to find all uses of classes when they are deprecated, moved to a different namespace etc.
2. Open braces at the end of the line. Yeah, it makes for more compact code and date back to K&R when 80x25 terminals were expensive. We now code in 27" monitors (or larger), typically in vertical orientation. Meanwhile, having braces like that makes the code harder to read and leads to stupid bugs. Why?!
3. 80 characters soft limit for line length. Again, it's no longer 1975, we are not limited to 80x25 terminals. 120 characters is more than reasonable, even on a 13" laptop with sidebars open in any decent IDE (phpStorm, Netbeans, Eclipse, ...).

I think Joomla should have its own code style, like it does now, because the objective of code is to a. perform a certain function; b. make it easily readable; c. minimise busywork and d. minimise the possibility of stupid bugs. PSR-12 fails miserably in the latter three. At some point CS people need to understand the historical context of K&R before trying to apply it indiscriminately on all modern code.

This topic is heavily opinion driven but to be honest we don't have the resources to maintain our code style and it really doesn't make sense to do every thing different then the rest of the php eco system. We can discuss this to at a later time in another topic. Just to your mentioned things.

1. It's not a must to compound namespaces and I don't like either (namespaces at all haha)
2. To be honest earlier in my life I was unable to deal with other code styles as my own (and I hate open braces on it own line ;-) but I learned to life with other codestyles and in the meantime I'm happy if the same codestyle is use by the complete application and not 10 different (or none) codestyle. But yes that's opinionated and thanks good with have braces and don't need to care about the right indention.
3. The good thing is it's only a softlimit and I'm pretty sure we keep our 150 character limited (also because nobody want's to rewrite the codebase and work on a c64)

Anyway that topic can be discussed later and if we need exceptions or stick to psr-12 completely.

@nikosdion could you please fix conflicts here?

I'm not sure why the merge freaked out. Let me see if I can fix it.

I think GitHub is having a stroke — or trying to give me one. It finds three changed files... which are actually not changed!

• administrator/components/com_joomlaupdate/tmpl/joomlaupdate/noupdate.php I checked manually, it is the same as the file after merging https://github.com/joomla/joomla-cms/pull/36134/files
• api/components/com_installer/src/Controller/ManageController.php it is as merged through https://github.com/joomla/joomla-cms/pull/36376/files
• build/release-checklist.md it is as merged through ca42355

The other files are indeed what is part of my PR.

It's as if GitHub calculates the PR against the repository as it was YESTERDAY instead of as it is right now. When I do a diff between my brach, as it is checked out, and 4.1-dev I only see my four files changed.

The good news is that if you merge the PR right now you will have no adverse effects. As to why GitHub doesn't calculate the PR correctly, beats me!

@HLeithner @bembelimen Is there any chance this will be included in Joomla 4.1? It's nearly two months this is done and dusted, no feedback, everyone agrees plugins need to be refactored, what's the holdup here?

I think it should go into 4.2 and I'm willing to help out converting the other plugins as well.

@laoneo Thank you! I can help out with this as well.

@nikosdion can you rebase it to the branch 4.2? I will give it a test then.

Hallelujah! Merging 4.2-dev onto my branch and changing the base branch of the PR convinced GitHub to get out of its braindead space and only show the real files changed. @roland-d this is ready for actual review :)

You may also want to change the labels, unless they are assigned automatically.

I have tested this item ✅ successfully on 52e20e3

Made some menu items and browsed them on the front. Cache is created and served on next page load. Added a die on one of the default.php after the page is cached. On a reload the page loaded normally.

@nikosdion can you fix the conflicts here? Thanks.

@laoneo There you go.

I also fixed the docblock and inject the frontend router object; these should be the last two pending items.

The intendation is still not correct as the other docblocks do look like:

while on yours:

The funny thing is that the weird indentation comes from me copying that weird docblock from the original file. Whenever I have time (this week is really difficult) I will reformat the docblocks. Unless you want to do a PR to my branch if you have the time?

Guess now it is correct.

Thank you

Thanks for your patience! Now we can start to convert the rest of the plugins.

Thank you for merging!