Any plugin conversion tool available/necessary for Vanilla 2.5?

rbrahmson

Noticed the new json format in the vanilla plugin source of 2.5 and I wonder whether the changes to the plug-ins were manual or perhaps there's a conversion tool. Or perhaps it's not necessary because vanilla will support both old and new formats;-)

Linc

We're trying to support both formats for a sunset period. Trying to guarantee the addons directory can do both is actually the thing that's got me stuck on the 2.4 release lately - we'd already moved to it for that.

Linc

Also, for the record, 2.5 is not anywhere near release. It's an alpha build, which means more features are yet to be added. I really don't recommend building anything for it yet.

rbrahmson

Thanks. I'm in the final phase of developing a plugin (being beta tested by some users over here) and wanted to check whether I need something to make it "future proof". If you care to learn about the plugin shoot me a pm.

R_J

I have tried something similar (making a plugin futureproof) and had not many problems on the frontend side.
The backend has many changes though. Most things work out of the box, but they might look a little bit awkward. The only thing that you most probably will stumble upon is that addSideMenu is replaced by setHighlightRoute. I have come up with this simple snippet:

        if (method_exists($sender, 'setHighlightRoute')) {
            $sender->setHighlightRoute('settings/plugins');
        } else {
            $sender->addSideMenu('settings/plugins');
        }

terabytefrelance

@Linc a dit :
We're trying to support both formats for a sunset period. Trying to guarantee the addons directory can do both is actually the thing that's got me stuck on the 2.4 release lately - we'd already moved to it for that.

I know that the ideal would be to keep the compatibility of addons and plugins back, but also remember that php has had many changes, and sometimes many systems lose those compatibility due to new developments which is normal, in my personal opinion, launch a version 2.4.x incorporating the automatic cache cleanup function for themes, addons and plugins, and launch a new branch vanilla 3.0, which indicates that the addons and plugins should update, the truth I do not see more problem, the addons and more important plugins are maintained by the team vanilla, it will be a great job but the reward will be more efficient, faster and safer software using the new api.

Regards,

rbrahmson

I still vote for a long sunset period of backward compatibility. The reality is that for various reasons many communities are late to upgrade.

It would be great if there was an automated script (even an editor macro) that would apply the compatibility changes. I don't know if R_J's code snippet above is the only required change... Would be nice to know the answer to this question.

P.S. I don't even know whether the statement that the "more important plugins are maintained by the team " is accurate. There will be users out there for whom a specific plugin is very important regardless of it's authors.

terabytefrelance

@rbrahmson What is being proposed is to leave the compatibility to version 2.4.X, imagine all the PHP systems that have broken for not supporting the version 7.X +, also up to version 2.4.X will have an excellent forum, and after that version if you have an incompatible plugin will have to work a little in the, my specific case I did not know vanilla until two months ago and until a plugin I have programmed with the help of the forum moderators, so I do not see problem in moving forward,

Regards,

Bleistivt

There is a conversion tool:
https://github.com/vanilla/vanilla-cli

In my experience you don't need to worry about deprecated functions as they will tell you if they are deprecated and there is an alternative.
See addSideMenu, for example:
https://github.com/vanilla/vanilla/blob/63bfdded1a2ed818857cb4a101c20405a56a2b76/applications/dashboard/controllers/class.dashboardcontroller.php#L146

You basically just need to turn on debug mode and go through all warnings and notices.

Linc

@rbrahmson said:
I still vote for a long sunset period of backward compatibility.

We too are fans of backwards compatibility. When we decide against it, it's because we don't have the resources necessary to keep doing it.

River

@rbrahmson said:
Noticed the new json format in the vanilla plugin source of 2.5 and I wonder whether the changes to the plug-ins were manual or perhaps there's a conversion tool. Or perhaps it's not necessary because vanilla will support both old and new formats;-)

yes a simple conversion tool would be the best thing that could be done for all the broken plugins.

more time spent with that and creation of .json file would be far better than redesigning a ratings system to rate broken plugins.

this should be run automatically on all plugins in addon section.

Caylus

For my own use I've created this plugin:

https://github.com/Caylus/PluginFixer/blob/master/class.PluginFixer.php

You download a zip file from the addon section, go to the settings page of this plugin, upload the zip file and download a "fixed" zip file.

It basically creates a addon.json file inside the zip file, and makes sure the classname is called KeyPlugin (older plugins sometimes only have a Key as name).

I'm strongly against running any automatic "fix" against the addon section though, since it's really hard to protect against all the exceptions to general rules, and odds are you break quite a few plugins by trying to fix them.

I just convert individual plugins, then I can at least test them individually to make sure they still work after my "fix".

rbrahmson

I haven't had time to research it but I noticed that there's a file created in the cache directory for the activated plugins, so perhaps some content can be derived from that file and added to the individual plugins... Again, just an unresearched notion.

R_J

@Caylus said:
For my own use I've created this plugin:

https://github.com/Caylus/PluginFixer/blob/master/class.PluginFixer.php

I'm strongly against running any automatic "fix" against the addon section though, since it's really hard to protect against all the exceptions to general rules, and odds are you break quite a few plugins by trying to fix them.

I just convert individual plugins, then I can at least test them individually to make sure they still work after my "fix".

I strongly agree that this is a better approach.

Here is my contribution for the addon.json update: https://github.com/R-J/addonjsonexporter
The plugins setting screen shows a dropdown with all available plugins and shows all internally stored plugin info keys in json format

River

@rbrahmson said:
I haven't had time to research it but I noticed that there's a file created in the cache directory for the activated plugins, so perhaps some content can be derived from that file and added to the individual plugins... Again, just an unresearched notion.

There should ALWAYS be an option to delete the two cache files available from the dashboard (but there is not) - the plugin related one and the theme cache as well. Deleting the themeindex and the files from compile folder would be nice as well from the dashboard. The cache file can be out of synch and the dashboard code isn't smart enough to know there is a a change. Sometimes it knows there is a cache change if you add a plugin and then you will you get the option to clear cache. But I see no harm in making the option persistent and consistent and permanent, since there may be other reasons cache will be out of date.

nice that you two created programs to create json files., should have been part of vanilla 2.5 since the json file is required in some cases or the plugin breaks despite the documentation saying otherwise.

Linc

@River said:
since the json file is required in some cases or the plugin breaks despite the documentation saying otherwise.

What cases? Is there an issue filed for this?

Caylus

@Linc said:

What cases? Is there an issue filed for this?

Hey Linc,

For example pn.js seemed to need a .json file (at least in my setup):

https://open.vanillaforums.com/discussion/comment/251595#Comment_251595

But since other people didn't have the same issue, I figured it was something specific to my setup.

Linc

I'm able to enable that plugin and navigate to /plugin/PrivacyNotice successfully and see a privacy notice. This is using the latest master branch. I believe you have misdiagnosed the root cause of whatever issue you are having.

Caylus

I've finally identified the root of my issue!

It had been bothering me quite a bit. Plugins in 2.3 were allowed to have class.FancyTitle.php as a title. In 2.5, the PluginInfo doesn't get read from class.FancyTitle.php.

(Same issue as I had with uploading a new version of my plugin: https://open.vanillaforums.com/discussion/35936/cant-upload-update-to-plugin#latest)

When an addon.json file is present, PluginInfo doesn't need to be extracted from class.FancyTitle.php, so it just works (because the autoloader has no issue including class.FancyTitle.php).

Which is why most of my own plugins suddenly broke. They were all named "wrong", so they all needed an addon.json file. Which is also why other people don't have the same issue, because they don't have the same naming habit as I have.

Linc

@Caylus said:
Plugins in 2.3 were allowed to have class.FancyTitle.php as a title. In 2.5, the PluginInfo doesn't get read from class.FancyTitle.php.

Classic case of breaking compatibility we didn't realize existed.

R_J

... and when we are already talking about naming conventions (something I really love), may I ask another question?

From looking at newer plugins I got the impression that the convention now seems to be "/plugins/newfunctionality/NewFunctionalityPlugin.php". Is that correct?