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

R_J · Cheerleader & Troubleshooter · Moderator


Last Active
Moderator, Developer, Community Developers
  • Re: pn.js

    @River said:
    The other thing I found in the plgins for 2.5 is that with some plugins the Settings don't show completely if there are many settings on a separate setting page in views.

    You can add "usePopupSettings":false in addon.json (and I expect "UsePopupSettings" => false in PluginInfo) in order to avoid that the setting page will be opened as a popup

    @Caylus said:
    The docs may say that it's still supported, but that's not my experience up until now. With addon.json plugins work, without them plugins that worked fine in 2.3 fail in 2.5 (at least in my specific setup).

    Was fun figuring that out, I can tell you that /sarcasm.

    @River said:
    FWIW default.php name seems to work currently as long as Class in the plugin has Plugin in the class name withing the plugin.

    Naming conventions seems to be evolving, just take a look at the vanillaconnect plugin and you will find the file 'VanillaConnectPlugin.php`. So we end up with the following options:

    • default.php
    • class.somename.plugin.php
    • SomeNamePlugin.php

    And maybe you can even name it any way you want as long as the class name is "correct"?
    The correct class name for a plugin which resides in the folder /plugins/someExample would be SomeExamplePlugin

    The addon.json would allow differing class names, though: "className":"SomeExamplePug" would allow you to give your plugin a ridiculous name.

  • For Plugin* Authors: Changes of Interest in Version 2.5

    Quite a lot has changed with Vanilla version 2.5 and I thought it would be a waste of time if everything that I've already stumbled upon would be forgotten. So I will write it down here.

    Before I start: the Vanilla repository on GitHub has a label "Good first contribution". So if you are reading this discussion out of curiosity and not because you are a plugin author, think about becoming one :wink:


    The most obvious change for a developer is the addon.json file. It is already good documented (here and here). The online documentation is getting better and better now and I would be happy if some of the info I pin down here would be carried over to the official docs by some volunteers whose English is good (enough). After all the documentation is just another public repository.
    I'll be happy to check your writings if you like to before you contribute.

    Here are the keys that are used in the addon.json that I found are used, not all of them are yet in the official docs ("Good first contribution" :wink:)

    • type
    • key
    • className (string): If the plugins class isn't named "KeyPlugin" ("key" like the value of the key above) you can give that name here.
    • nameSpace: the namespace of the plugin class
    • path: the plugin files path
    • name
    • description
    • icon
    • iconUrl (url): allows showing an external image in the dashboard
    • mobileFriendly
    • version
    • pluginUrl (string): Shown as a "Visit Site" titled link in the plugin list
    • newVersion (string): pluginUrl must be set and it must be a link to the addons application here, otherwise it generates a useless link. Link text is buggy in 2.5, but already fixed in master
    • license
    • settingsUrl
    • usePopupSettings (bool): setting this to false will open the settings page in a new page instead of showing it in a popup
    • authors: What is not said there is that "AuthorEmail" is never used anywhere.
    • author, authorEmail, authorUrl: don't use them anymore
    • require: replaces "RequiredApplications", "RequiredPlugins", "RequiredThemes"
    • conflict (array): if you know that your plugin doesn't play well with another plugin you should give the key and the version number here. Implementation isn't working yet (Advanced Editor and Button Bar use it already, but you can activate both of them nevertheless).
    • hasLocale (bool): if your plugin has translatable strings
    • documentationUrl
    • registerPermissions
    • priority
    • meta (array): if you want to provide additional info that should be displayed in the plugin list

    You can surely use whatever key=>value pair you like.

    One word of caution: a key that you can see quite often is "settingsPermission", but that has no effect at all! You always have to do permission checks in your public endpoints by yourself. Specifying this key is merely informational and therefore you should consider to stop using it.

    By the way: I found this information by looking at
    /applications/dashboard/views/settings/helper_functions.php and
    and last but not least /cache/addon.php

    * = this information might also be of interest for theme authors. At least everything you can read about the addon.json file, although there are even more keys available, just look at the class.thememanager.php

  • General 2.5 Plugin Compatibility Issues

    If you have a plugin with the plugin key called "Something", the plugin class must be named "SomethingPlugin" like so

    $PluginInfo['Something'] = array(
        // ...
    class SomethingPlugin extends Gdn_Plugin {

    Sometimes you find plugins which only use class Something extends Gdn_Plugin. Plugins like that seem to "not work" with Vanilla 2.5 any more. It can be simply fixed by renaming the class. Afterwards you have to delete the file /cache/addon.php and the problem should be gone.

    @Vivant: you have mentioned problems with the "I Like This" plugin.
    @Dr_Sommer: you have problems with the Add Registration Question

    You both should be able to fix these problems by replacing class LikeThis extends Gdn_Plugin { with class LikeThisPlugin extends Gdn_Plugin { for the "I Like This" plugin and class AddRegistrationQuestion extends Gdn_Plugin { with class AddRegistrationQuestionPlugin extends Gdn_Plugin { for the "Add Registration Question" plugin and deleting the file /cache/addon.php afterwards.

  • Re: Vanilla Porter for Discuss ( Modx )

    Doing a port from one forum script to another is something I never did before but which I would really enjoy.
    But I would need two things for that:

    a) a complete dump of the database
    b) an admin account on a running instance of that forum

    So if you are interested, drop me a note.

  • Ozapft is!

    If you ever thought about contributing to Vanilla, then this is the best time for it: it's Hacktoberfest!

    Each year DigitalOcean announces the Hacktoberfest. Everyone who makes four qualified pull requests to any project on GitHub between October the first and the 31st will get a shirt.

    So you think that is only for developers? Nope. If you find a typo anywhere, create a pull request! Start by creating a GitHub account and register on DigitalOcean

    Afterwards go through the Vanilla repos and see how you can help. Well, you certainly can contribute to any project you like, but if you invest time, why not doing it for your favorite forum script? :wink: