If this is something that gets accepted, then would it be possible to also port this to Joomla 3?
The changes are minimal, and it is fully backwards compatible. It does not change anything for existing log messages or action log plugins. It just adds functionality available for extension developers (or even core).

Can you explain how the comma separated string keys get into the action log record in everyday use. I don't see any other method than hard-coding.

What do you mean by hard-coded?
The action log plugins are responsible for adding records to the action_logs database table.
This PR gives the (3rd party) action log plugins the ability to add extra information that is too long or messy to add as the main title.

So a 3rd party action log plugin could do something like this:

$messageLanguageKey = 'MY_ACTIONLOG_STRING,MY_ACTIONLOG_STRING_EXTRA";

$this->addLog(array($message), $messageLanguageKey, $context);

And pass on any data in the $message that can either be displayed by the first main title or by the extra info string (or both).

This PR does nothing to the behavior of any core action log plugins. So the test with the extra PLG_SYSTEM_ACTIONLOGS_USER_UPDATED_EXTRA was just a way to test if it works, without having to create an action log plugin that uses this functionality.

Looks like a great idea

I would for instance use thins for my extension DB Replacer:

In the panel on the Admin home screen (dashboard) nothing changes. So it still just shows:

I have tested this item ✅ successfully on 0c937f9

Thanks for the clarification - this works as described in the test and I understand now it is intended for use by third party plugins.

I have tested this item ✅ successfully on 0c937f9

Is there a reason you went for a comma separated list of language strings rather than a more normal PHP Array?

Is there a reason you went for a comma separated list of language strings rather than a more normal PHP Array?

Because the addLog expects a string

• It would need a lot more code changes for that to accept a mixed value (string|array): type checking, converting from string to array and/or back, etc.
• I don't like it when a method accepts mixed data types in attributes.
• It would change the public signature of the method... which could potentially cause issues with classes extending on that model.

So this is the path of least resistence.

So this is the path of least resistence.

I hear ya...

So I looked at the PR again and I'm unsure if we really need the change in this PR? What prevent us from merging content of the two language items into a single one and don't have to change code? For example, I can change the language item and get the result in this screenshot

Also, could not say that I like the way we put multiple language items into a single field in database like this. If we can add extra language item, someone could ask why he could not add the third language item... The way we are using here looks like a workaround only.

@joomdonation Because that will also make that extra info show up in the control panel on the dashboard. Which we don't want, as it is supposed to stay clean and simple.

Regarding the 'workaround': yes, of course it would be nice to have a separate table column for this string, and add it as the 3rd attribute in the addLog() method (pushing $context to the 4th).
But like explained before, I don't think we are at a stage now to cause that much disruption and BC breaks for something like this.

Even more so if we also push this change down to Joomla 3 (which I hope may be done!)

Because that will also make that extra info show up in the control panel on the dashboard. Which we don't want, as it is supposed to stay clean and simple.

Thanks Peter. I understand the reason now.

of course it would be nice to have a separate table column for this string, and add it as the 3rd attribute in the addLog() method (pushing $context to the 4th)

We can always add that new parameter to the end, thus backward compatible, and the code would be nicer and gain a tiny performance improvement. But I'm unsure if it is really needed. I would do that if it is possible, but that's just my personal feeling. If everyone else is OK, I'm fine.

Even more so if we also push this change down to Joomla 3 (which I hope may be done!)

From what I see, look like maintainers does not accept new features anymore. So guess this could not be backported to Joomla 3.

@regularlabs If you don't want to make that extra change, please let us know. We will ping testers for testing it again and let's maintainers make decision.

Well, the change to the addLog() method still means:

• It would change the public signature of the method... which could potentially cause issues with classes extending on that model.

I am happy to change it. But I cannot oversee the issues it might cause...

I could not see reason someone would extends that class or override that method. So if you could make the change, that would be great. But please only do that if you think that it's right. Otherwise, keep it as how it is and let's maintainers decide about it. This is just my personal feedback.

And it would change from:

public function addLog($messages, $messageLanguageKey, $context, $userId = null)

to:

public function addLog($messages, $messageLanguageKey, $context, $userId = null, $messageLanguageKeyExtra = '')

Which to me does not seem very logical, tbh.

Which to me does not seem very logical, tbh.

Agree. But sometime we will have to accept the illogical for backward compatible reason :)

There is a ActionLogPlugin::addLog() too, with the same signature. That would also need changing.

So I would say: let the maintainers decide about it...

Can you please rebase this on 4.1 or I can do it for you. Adding this could make sense but not for 4.0 at this state

Can you please rebase this on 4.1

Is there a date for that release, or timeframe after Joomla 4.0.0 Stable decided yet?

Why not for Joomla 4.0? It doesn't change any core behavior...
And release of Joomla 4 stable is still 18 months away!

sed -i 's/months/hours/g'

"Can you please rebase this on 4.1"
Nope, not doing that. Joomla 4.0 is far from done. I tried again to improve the current Joomla. But alas.

Joomla 3 has been stale for ages - 350 million children have been born since Joomla 3.9.0 released.
Joomla 4 is not ready, but for some weird reason, 'we' decide to not accept things that improve it (for core or extension developers), but push anything to a next version that will probably take another 300 million babies before it sees the light of days.

This sucks the fun right out of trying to contribute.

I know, I know... writing this here solves nothing and s same-old same-old.
But again, I feel like I wasted my freaking time and am again deciding to forget about trying to contribute to a big slow behemoth. Of to my own coding.

Do with this what you want.

PS: next time I create a PR for whatever, please close it and refer me to this!