Question Joomla 6 support?

xillibit wrote:

Hello,

For the install script by looking in the manual it's not the right way : manual.joomla.org/docs/next/building-ext...ion/install-process/

By using a clean sample like gived in the manual, i do'nt have a white page during the install. I need to reimplement of the features of the older script. How to get the manisfest data now ?
I have still whites pages on Kunena dashboard, categories manager...

I have created a 6.5 project on github repo, empty for now, do-you want an access to it ?


 

That depends on what you need from the manifest.
Joomla itself has an installer script class that you can use (currently not able to check what the name / location is).
Or you can have a look at the installer helper I use in my extensions: it has all the methods I ever needed.

Hello,

Yes the 6.5 branch exists : github.com/Kunena/Kunena-Forum/tree/K6.5 . Yes your PR about captcha was done against 6.5 branch : github.com/Kunena/Kunena-Forum/pull/9888

Ok i let you work on system plugin

ruud wrote:

That depends on what you need from the manifest.
Joomla itself has an installer script class that you can use (currently not able to check what the name / location is).
Or you can have a look at the installer helper I use in my extensions: it has all the methods I ever needed.


 

It's to just retrieve the version of Kunena to be installed for the requirements checks

The manual say the script needs to use libraries/src/Installer/InstallerScriptInterface.php actually the class acutally in script extends InstallerScript or the other method is to use a Dependency Injection Container

P.S. : i have just seen that i forgot to copy some lines which defines the versions allowed, now the check of requirements works

Okay, started to rebuild to plg_system_kunena into a J5/6 new SubscriberInterface plugin.


I have the following questions:

1. the onBeforeExtensionInstall and onBeforeExtensionUpdate are imo 'useless' as they only execute and stop the installation when somebody tries to install version 2.0.0 or below... Who would do that, that is like ancient version. So I would suggest to completely remove these triggered event methods, even if someone tries to install a version before 6.4 then these methods will NOT execute as in the constructor of the plugin this is disabled.
   If the check is still needed then IMO it should be in the installer script preventing these old versions from installing
2. in the plugin there is a function: runJoomlaContentEvent but when searching the complete repository I cannot find anything that calls this function? So can this be removed?
3. we need to discuss triggered events as these have changed in J4/5 and in J6 things will be removed as they where already deprecated some time ago (not in J6 alpha 6 they are not removed and Joomla core is also still useing triggered events). So remark below.

Triggered events:
search the code for 'triggerEvent' and you will fing Kunena 'events like onKunenaGetAccessControl, onKunenaBbcodeConstructs, etc.

These are currently implemented e.g. like this:         $classes = Factory::getApplication()->triggerEvent('onKunenaGetAccessControl');

but they should be implemented like:
$event = new KunenaGetAccesControllEvent('onKunenaGetAccessControl', []);
Factory::getApplication()->getDispatcher()->dispatch('onKunenaGetAccessControl', $event);
$classes = $event->getArgument('result');

in the example above I use KunenaGetAccesControllEvent, this is a choice as that then would be an event created for Kunena, this is something to discuss and decide if Kunena needs / wants its own events, or will workaround the (limited) Core provide Event that can be used for genereric use cases

Hello,

1°) The onExtensionBeforeUpdate is to prevent that people to try to downgrade by installing previous version, something need to be done on the install script to prevent that. 
2°) I don't know what was the purpose of runJoomlaContentEvent, i have looked into kunena addons (discuss plugin...) but it's not used here neither so it can be removed.
3°) When the usages of triggerEvent will be removed the defintion class will disappear. The purpose of these events in Kunena was to be able to use it in plugins which can be provided separatly from Kunena. From my point of view these events should be keep.

xillibit wrote:

Hello,

1°) The onExtensionBeforeUpdate is to prevent that people to try to downgrade by installing previous version, something need to be done on the install script to prevent that. 
2°) I don't know what was the purpose of runJoomlaContentEvent, i have looked into kunena addons (discuss plugin...) but it's not used here neither so it can be removed.
3°) When the usages of triggerEvent will be removed the defintion class will disappear. The purpose of these events in Kunena was to be able to use it in plugins which can be provided separatly from Kunena. From my point of view these events should be keep.
 

ad. 1) The kunena install script extends the Joomla Core 'InstallerScript'. That has already the possibility to disallow downgrades:
[code]
    /**
     * Allow downgrades of your extension
     *
     * Use at your own risk as if there is a change in functionality people may wish to downgrade.
     *
     * @var    boolean
     * @since  3.6
     */
    protected $allowDowngrades = false;

In the script you need to call the preflight function and if correct, then downgrading is not possible.
I will test this and if that works will remove the onExtensionBefore things from the plugin.
ad 2. I will remove runJoomlaContentEvent

ad. 3 we should refactor the way these events are called, in J5 / J6 these need to be refactored and use 'real' event classes' instead if the way you are doinging it now (using an eventTrigger and then pass an array with the data, which gives back the results (if any).
This needs to be discussed on impact as changing this and start using own Events has impact on 3rd party plugins that have no knowledge of these events. J5 had a B/C thing in place, but what I see in J6 this will be removed.

I'll do a setup for this for the onKunenaGetConfiguration events (also in the system plugin), so based on that we can see what the impact is and if that is a way forward.

Also something to think about.
Currently the system plugin also puts load on every (!) page visit where it does (or does not) cleanExpiredBans.
It would be 'better' to have a task plugin that does these chores on a timed interval (cron).

Just to add. I think that onKunenaGetConfiguration can also be removed both from the plugin as well as from the KunenaConfig where it is triggered.
It is triggered in KunenaConfig, but nothing is done with the result of the triggered event:
So $plugins holds the parameters for the system plugin, but is not used . The function load() that triggers this event is void and does nothing with $plugins.

Correct?