I did one of these ~6 months ago and I'd like to followup on it and give out some additional roadmap context.
How'd we stick to our previous roadmap
- Shipped new Embed System. (Documentation)
- Alt-text for images in Rich Editor.
- Emptied the Security Backlog (Over 300 security fixes since launching our HackerOne program!)
- Testing Pull Requests on CircleCI. (CircleCI)
- Improved automated testing - Code Coverage reporting & Visual regression testing.
- Refactored the text formatting pipeline (
Gdn_Formatis mostly deprecated. see
DateTimeFormatterfor new methods. )
- Splitting the frontend into different independant packages. (See
Still In Progress
- New Controllers & Routing. The new structure has matured significantly as we've worked on new projects, and documentation is forthcoming.
- Rich Editor mobile improvements.
- Builtin Docker Images - I was working on this personally and got burnt-out of it before I could get it polished enough for code review. Unfortunately I don't have much motivation for it. It looks like the community is starting to take it up though. I'm available for questions of anyone working on projects like this.
New Roadmap Objectives
Warning: These notes are not a guarantee of any particular version number or release date. It just represents some of our development goals.
Complete the 4.0 release
The 4.0 release is currently in progress. Main improvements will include:
- New Base Theme & New theming system.
- Hero Image plugin no longer a plugin. Instead it is built-in to core.
- 100s of bug-fixes
- Performance improvements.
- New PHP version requirements.
As we move our developer documentation over to it's new home in our Success Knowledge Base, we are updating outdated articles, adding new ones, and moving some new technical documentation from our internal documentation to become public.
Items that are set to receive new documentation:
I'll link the documentation here as it becomes available.
- New Controllers & Routing.
- Using Twig for Views.
- Using React for Views.
- Using the new Theming system.
- Using the new FormatService.
- Advanced custom embeds for Rich Editor.
- Improved local installation instructions.
- i18n & Localization.
- New Model Class & Pipelines.
- Dependency Injection.
As we write these we will primarily looking to provide "quickstart" guides with code examples. For for more technical understanding it's best to look at the key source code files, which will be linked at the bottom of documentation, where possible.
I've been using Vanilla for about 5 years, and have developed a maintenance process along the way that has broken down. My goal was to version control our setup (customisations, theme, plugins), and allow for automated deployments like the rest of our stack. I did this by forking the repo and adding to it: for plugins that were on GitHub, I added them as submodules; when they weren't on GitHub, I added their contents to our repo.
This worked for the most part, but upgrading the forums was always a bit of a pain, as we had to rebase and deal with any merge conflicts. We now have a huge number of merge conflicts, to the point that I'd like to start over and make a better setup.
The goal is to create a version controlled forum setup, with reproducible builds, that can run on an ephemeral filesystem (even heroku) so we can load balance it and even blow it away and reconstruct it if necessary. The twelve-factor app provides some background and general principles for this.
To do this, I figure I'll need to:
- Start from a specific Vanilla release: either a distributed package (zip) or the GitHub codebase (in which case I'd need to run composer).
- Fill in
config.phpwith settings and secrets, without putting secrets into version control.
- Pull in our theme, either from a separate git repo or from a directory within this repo, and move it to the
themesdirectory of the Vanilla codebase.
- Do the same for 10+ plugins, some of which are on GitHub, others which are just .zip files on the addons website.
uploadsto be writable by PHP.
- Somehow make
uploadsa separate volume (like S3) so it can be shared across multiple instances and can persist (even be backed up).
I've started implementing this in a Dockerfile. You can see my progress so far at this repo.
Where I need help
I'm having some trouble with
config.php because Vanilla writes to it when an admin makes a change in the admin dashboard: it replaces
getenv(...) with the plaintext value. Therefore, if you want to commit any changes made in the dashboard back to source control (say, by mounting
config.php as a volume and then making the changes), you'd be committing secrets unless you remember to go back in and change them back to
getenv . Solutions to this I've thought of so far are: (a) make it read-only, so the application cannot change it, or (b) consider it a secrets file, outside of source control. But then how would you do an automated deployment? Is there a way to stop Vanilla from writing to
config.php ? I would think the database would be better suited for some of these settings, no?
2. Pulling in the theme and plugins
The simplest approach here is for the Dockerfile to just curl and unzip the theme and plugins. I can either put them in the appropriate place in the Vanilla codebase, or symlink them; it doesn't make much difference, I don't think. But it starts to feel like the job of a dependency manager. I could use composer here, but I'd have to either move the installed directory or symlink it to the appropriate place, and I don't think composer can do that, can it? Does anything else come to mind here?
Let me know if there's been any prior work on this, or if anyone wants to collaborate. I'm sure there's ways we can make the repo generic.
I bet you are all fed up by those massive "IT'S BLACK FRIDAY! CONSUME! CONSUME!" attacks all around you just like I am.
And I thought I turn it the other way around: ask me for a simple plugin, some code snippets or anything like that and if I provide them to you, you are morally obligated to do something good: be kind to a homeless person, help the old lady in your neighbourhood to carry her bags home or simply feed the birds and hedgehogs outside, anything like that. You get the idea.
Missed the 3.2 release? Check out the upgrade & release notes here.
Vanillicon Changes Incoming
Changes to your Vanillicon are here. You'll see a new avatar after this update. To find out more, checkout "Why Vanillicon Avatars Changed" on what is changing and why.
- Rich quotes of Discussions now display the user profile image.
- All rich quotes now use the improved expand/collapse UI from reported posts.
- Multiple images can now be uploaded at the same time.
- Fix a bug where nested lists in Rich Editor would render improperly after being posted. vanilla#9332
- Fix emoji suggestions not displaying. vanilla#9250
- Update Vanillicon email hashes. vanilla#9244
- Fix notifications not being sent to participating users. vanilla#9406
- Fix invalid/expired state token error when signing in. vanilla#9356
- Update Twitter addon to use platform's share links.
- Fix dashboard category name rendering.
- Improve URL handling in API v2 /media/scrape endpoint.
- The time formats for some locales have been changed to the 24-hour format in accordance to their locale standards.
- Fix unicode character handling in "leaving" page links.
- Fix photo ID encoding in Getty Images embeds.
- Fix preemptively join conversations.
- Addons may now define PHP files in arbitrary namespaces in any subdirectory of the addon. Previously this was only possible with the
- Logging of PHP warnings has been disabled again. After fixing a few common cases, this may be re-enabled in a future release.
- Move the private community middleware to the /api/v2. vanilla#932
- Fix header link in
- Fix loop when dispatching exception page. vanilla#9359
- Fix Attributes JSON encoding for special data types. vanilla#9326
Get it over in the addon directory. https://open.vanillaforums.com/addon/vanilla-core-3.3
There are several reasons why installing a new plugin/addon/theme can fail. I don't think there is a comprehensive overview of what an admin can do when problems arise...
1. Target Folder Structure
Note: in some older plugins the main plugin file might be named
default.php. That is perfectly okay and no reason for any worries.
When you download a plugin you have to unzip it and move its content to the
The file structure afterwards must read:
When you end up with
/plugins/somePluginsName-1.0.0/somePluginsName/class.somepluginsname.plugin.php you have done something wrong and you will never be able to enable the plugin.
Addons must be unzipped to the
/applications folder. Check if you can find
If there is one more folder or one folder less in that structure, you've messed something up.
All files must be directly unzipped to the
/themes folder and all themes have an
about.php file in their root folder. So you can check if you have unzipped it correct if the path to the new theme looks like that
2. Target Folders Name
Note: upper-/lower case is important!
If you unzip what you have downloaded, the folder name will in almost all cases already match, so this paragraph is only useful for trouble shooting.
Open the plugin/the about.php file. Depending on what you look at, one of the first lines of code would look like that
$PluginInfo['somePluginName'] = array(
$ApplicationInfo['someAddonName'] = array(
$ThemeInfo['someThemeName'] = array(
The key of the array (the "someName" part) is how you would have to name the folder. If it is all lower case, your folder must be all lower case, if it is all mixed case, the folder must reflect that, too.
Uploading a plugin/addon/theme doesn't change your forum. You have to enable it first in the dashboard.
3.1 Errors When Enabling
Enabling a plugin/addon/theme ("extension") throws an error. There are some things you could solve by yourself, but normally you are lost:
- If the extension requires another extension, enable that extension first.
- If the extension throws a "Vanilla version x.y required" error, you can try to change a line in the PluginInfo array that begins with "RequiredApplications", but there is no guarantee that it will work
- Try to disable all other plugins, addons and revert to the default theme and retry to enable ths extension
- Visit the addon page here at the community and click on the "Ask a Question" button. Describe your problem as good as you can and give information which theme and plugins you are using and what you have tried by now to solve the problem. Afterwards wait patiently...
- If enabling a theme fails, make sure the folder of the current theme is spelled correct
3.2 Plugin/Addon/Theme is Not Visible
Although an extension has been uploaded to the correct path, it might not be included in the list of available plugins/addons/themes in the dashboard. The reason is, that the info in the header of an extension is cached. The only thing you have to do is to invalidate the cache so that it is renewed and the new extension will be included in the list.
But invalidating that cache isn't always easy.
- If you are using memcached, restart the memcached service. If you don't know if you are using memcached, I'm convinced you do not use it.
- Look in the
/cachefolder. There should be a file called
addon.phpwhich caches information about plugins and addons and a
theme-index.phpfile which holds information about the available themes. Delete the file you need (or even both if you are unsure) and refresh the plugins/addons/themes list
If something unpredictable is going on, your extension still might not be included in the list. There is one thing you can do, but it could temporarily create an error message in your forum, for a few seconds only and it is not said that there really would be an error message, but at least it could happen. Nevertheless the process itself isn't dangerous.
- Make a backup of the
- Open that file in an editor
- If you have a problem with a plugin, search for a line like
$Configuration['EnabledPlugins']['somePluginsName'] = false;. If you find that line, you simply have been too dumb to see the plugin in the list. Go and open the list again. The plugin is contained in the list. You just have to search harder.
- If the entry is not present in the config file, add it to the bottom. Change
falseto true and quickly(!) do the next steps.
- Open your forums dashboard, go to the plugins page, refresh it and you would see the plugin now. Disable it! Yes, that is an important step, disable it. Now you can enable it the normal way. The reason why you should disable and re-enable it is, that some plugins do some extra actions when they are enabled through the dashboard. When you enable them manually they skip this extra step and might not work correct
4. Disabling Fails
Check "2. Target Folders Name"