Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Try Vanilla Forums Cloud product

Any plugin conversion tool available/necessary for Vanilla 2.5?

rbrahmsonrbrahmson "You may say I'm a dreamer / But I'm not the only one"NY ✭✭✭
edited September 2017 in Development

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;-)

Comments

  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    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.

    rbrahmson
  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    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
  • rbrahmsonrbrahmson "You may say I'm a dreamer / But I'm not the only one" NY ✭✭✭

    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_JR_J Cheerleader & Troubleshooter Munich Moderator

    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');
            }
    
    rbrahmson
  • @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,

    R_JK17
  • rbrahmsonrbrahmson "You may say I'm a dreamer / But I'm not the only one" NY ✭✭✭

    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.

    phreak
  • @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,

  • 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.

    My themes: pure | minusbaseline - My plugins: CSSedit | HTMLedit | InfiniteScroll | BirthdayModule | [all] - PM me about customizations

    rbrahmson
  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    @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.

    rbrahmson
  • RiverRiver MVP
    edited March 5

    @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.

    Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.

    rbrahmson
  • rbrahmsonrbrahmson "You may say I'm a dreamer / But I'm not the only one" NY ✭✭✭

    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.

  • RiverRiver MVP
    edited March 6

    @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.

    Pragmatism is all I have to offer. Avoiding the sidelines and providing centerline pro-tips.

  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    @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?

  • CaylusCaylus ✭✭

    @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.

  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    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.

  • CaylusCaylus ✭✭

    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
  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    @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. :o

  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    ... 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?

  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    @R_J said:
    ... 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?

    That's a good question.

    As far as I can tell, everyone on the team but Todd & Ryan does /plugins/newfunctionality/class.newfunctionality.plugin.php. Todd does what you did above, and Ryan does /plugins/newfunctionality/newfunctionalityplugin.php basically combining the two. I hadn't even noticed the divergence. I'll have a word with them.

    R_J
  • R_JR_J Cheerleader & Troubleshooter Munich Moderator

    @Linc said:

    @R_J said:
    ... 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?

    That's a good question.

    As far as I can tell, everyone on the team but Todd & Ryan does /plugins/newfunctionality/class.newfunctionality.plugin.php. Todd does what you did above, and Ryan does /plugins/newfunctionality/newfunctionalityplugin.php basically combining the two. I hadn't even noticed the divergence. I'll have a word with them.

    Did you have found the time to raise this question?

    Since Vanillas coding standard is moving towards PSR standards, I think it is logical to adopt the PSR-4 standard: "The terminating class name corresponds to a file name ending in .php." which wouldbe the same standard as it is already used in /library/Garden & /library/Vanilla resulting in SomeFeaturePlugin.php. I would prefer that.

  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff
    edited March 21

    @R_J said:
    Did you have found the time to raise this question?

    I slid it into a conversation not 10 minutes ago. The verdict is full PSR-4 (SomeNamePlugin.php) from now on. We're not retroactively updating old files at this time, primarily because I think it will cause widespread issues with open source updates not deleting the renamed files and therefore isn't worth it yet.

    R_J
  • LincLinc Vanilla's Bard (and Director of Development) Detroit Vanilla Staff

    Todd has also requested that folder + key be formatted in dashed-case.

    We'll update the coding standards soon.

Sign In or Register to comment.