Vanilla 2.6 is coming! Are you ready?

It features a new "Category Following" system that replaces the old "Hide Category" functionality. It allows users to "follow" individual categories, and then filter their Recent Discussions views to include all discussions or only those from followed categories. It also will include new endpoints for the native API, and the new "Vanilla Connect" single sign-on system.

Vanilla 2.7 will follow later this year. I'll announce details once its scope is completed, which may be a month or more in the future. Its marquee feature is a new rich text editor.

Now is the time to verify your system is running PHP 7.0 and make a plan for how to upgrade if it isn't. We do not plan to backport patches to the 2.5 branch after 2.6 is released, which means your install will fall out of date if new security issues are found.

Didn't 2.5 just release in December?

Yes, accelerated releases is part of our new unified release process that keeps open source up-to-date with our cloud offering. We expect 4 months will be an average or even "long" release cycle going forward. We schedule releases based on their projected completion, not based on a fixed deadline determined in advance. Projects we expect to take longer than 4 months are generally slated for multiple releases in the future. Lastly, we are continuing to refine this process, so expect more changes along the way.

Is there a public roadmap?

Not officially, but we do intend to pre-announce features in advance whenever possible. And, as ever, much of our planning & work is done on our public repositories where you are free to follow along. For instance, we've been working on the rich text editor in public for a number of months now (on the feature/rich-editor-mvp branch of the vanilla/vanilla repo).

Comments

Not officially, but we do intend to pre-announce features in advance whenever possible. And, as ever, much of our planning & work is done on our public repositories where you are free to follow along. For instance, we've been working on the rich text editor in public for a number of months now (on the feature/rich-editor-mvp branch of the vanilla/vanilla repo).

Happy to answer any other questions as best I can.

I have several questions!

I saw that you have been investing time on developing yet another templating engine. I was wondering
a) why you haven't chosen an existing template engine and
b) why a template engine came to your focus.
Smarty is used only very basically in Vanilla by now. For the purpose that Smarty serves in Vanilla, there would be no need to do anything at all or
c) do you have themes that make use of Smarty heavily?

d) Do you have plans to release a theme that uses ebi?

And when speaking about themes: now that the dashboard received a major make-over,
e) will there be a new default Vanilla theme soon?

I read most of what is going on on GitHub and I think I've read one comment which has something that appeared to me as something like a project name for a theme I do not know, but I deleted the mail and only thought of it again a few days later when I had no chance to find that special mail...

Are you able to give more details about the new API methods available and the Vanilla Connect you mention? I'm particularly interested in external login / registration, which I've done before with hacks in 2.1-3, but have just been looking into 2.5 and it looks like I would need new hacks. If 2.6 is going to have a native way to let me send a request to an API to say "sign this user in (checking their password)", I'll skip 2.5 and really look forward to 2.6!

@allanjard said:
Are you able to give more details about the new API methods available and the Vanilla Connect you mention?

Vanilla Connect is an update to jsConnect and works in fundamentally the same way. We've simply updated it to use JSON Web Token (JWT) formatted data and built an /authenticate endpoint to replace the twisted logic of /entry/connect. For more detailed info see this PR: https://github.com/vanilla/docs/pull/171

@allanjard said:
If 2.6 is going to have a native way to let me send a request to an API to say "sign this user in (checking their password)", I'll skip 2.5 and really look forward to 2.6!

No, that's not on tap for 2.6, but it is on tap for 2.7. That said, because there are security fixes in 2.5, I strongly recommend biting the proverbial bullet and making the upgrade ASAP. I'll also note that hacking SSO is rather dangerous from a security perspective.

@R_J said:
I read most of what is going on on GitHub and I think I've read one comment which has something that appeared to me as something like a project name for a theme I do not know, but I deleted the mail and only thought of it again a few days later when I had no chance to find that special mail...

What it's really missing and I know many of others would agreed on this, is simplified process of updating to new version(s).
That "overwrite old files with new one" is really painful for production sites (and could be really problematic one, too) and, if I may say, really outdated.

Some update method from admin panel would be great.

And it would be nice to add some of those "undocumented" links directly to admin (like dba/counts for example).
(together with /update link which is documented but without direct link from admin).

hmmm...my biggest concern is the amount of breaking changes and where they are documented. I'm not even updating all clients to 2.5 yet.

There have been breaking changes over the years and often you find many things out by accident it can be a daunting task updating addons. Like methods with swapped round parameters claimed to be made in the name of backwards compatibility (more trying to be consistent with other methods) when in fact it is a breaking change. Instead of that a new method would be better, then you can depreciate the old one.

Lets be honest it is not the easiest framework to work on, compare to others, It is not the worst either, but development tend to be slowed down it due to consistency issues. There are conventions, but there have been a number of different ones over the years and it can be very mixed for quite similar things.

I'd also be worried about the motivation and engagement of developers, which I predict is waning. I think there is a pattern of developing pluign and not updating them. heck I don't feel motivated to to that given little time. I would like to take some of them off the repository so I can focus on what it is possible for me to support with limited time. Some of them aren't too relevant, I'd like to be able to prune those out.

I do totally understand the progress involves pain and that is necessary, but those changes need to be documented better, perhaps as momentum is picking up thing will get better. I hope that is the case. maybe there need to be a system, so developer are more prepared rather then playing catch up. it is quite daunting, I can't really blame people for moving on.

Working with client most of them are very externally minded it is all about the interface. One of the weakens of the framework is the views. We are in an era beyond basic MVC and we are morning into more dynamic front end such as angular.

You could for example have view models to dynamically drive your templates, which employ services to communicate with the controllers. On request the controller could employ the view model (which would be backward computability for old style views).

JQuery as much as I loved it over they years it is like the hand of god. It is not context based or obvious, it can come in from up hight and manipulate things, except it is often not one god but many, which can work at cross purposes.

The current view are no better or less entangled than they were under Vanilla 1.

Separation of concerns and being able to more thing around is limited except through non context based hand of god methods. Normally view model would also control the view resources too. However that could be figure out how that might work and a compromise be made

Or you could django style of template "blocks" where at these then it is at least easier to move things around. I think you also need rid you self of these informal "vanilla selectors" classes/id in order to manipulate the views as this is easily broken.

@x00 You seem to be summarizing all the major challenges of software development.

API v2 is being built precisely to provide stability. Our hope is that eventually, addons will use the internal API rather than data queries. This will standardize the interface, allow for thorough testing & documentation, and provide the stability you seek.

The key goal of a new default theme is to provide a thoughtfully designed canvas that does not require view overrides. It will also be deprecating our use of jQuery. We're also building it as a backward-compatible system so that existing themes are not broken by it, which is a tremendous amount of overhead for a small team to handle.

On a smaller scale, we've built Category Following so that it will be off by default in existing installs. This is because it adds UI elements to the page, which can cause theme breakage. That allows you to opt-in when you're sure it's safe to do so, and upgrade your system without worry.

We've certainly been emphasizing backwards compatibility as a requirement not a "nice-to-have" feature on our team internally. I'm sure we'll never be exactly perfect, but we're taking it seriously and moving as quickly toward a more stable and thoughtful system as we can.

We should open a survey if we want Vanilla to advance unfortunately we will have to divide the software into two branches, one that supports up to a certain version all the changes made so far with compatibility with previous versions, and a new branch that allows progress without worrying about compatibility. , many times for wanting to do something compatible in a world where everything progresses drastically, we end up with a remedy but the disease itself, bet the example frame yii2, has two branches yii1 and yii2, Vanilla could have branch v2 and v3 development new not compatible previous versions.

At some point the compatibility is broken, best example boostrap3 y boostrap4.

There have been breaking changes over the years and often you find many things out by accident it can be a daunting task updating addons. Like methods with swapped round parameters claimed to be made in the name of backwards compatibility (more trying to be consistent with other methods) when in fact it is a breaking change. Instead of that a new method would be better, then you can depreciate the old one.

I have to say, I wholeheartedly agree with this.
So many plugins are slightly broken. But if they don't get fixed, it's the same as them being completely broken.

Even plugins where it's claimed to be "This product is maintained by the Vanilla Forums staff and core team." just... aren't.

I know the most recent versions are on Github, but new users won't be aware of that. They'll just see a plugin from 2014 (2014!) that doesn't work anymore and still has a stamp of approval of the Vanilla staff.

And I (And others) can fix plugins, but we can't upload them without changing the name.

So if I can make a suggestion: Let developer users reupload plugins with the same name as existing ones if the community has stated the old ones are broken, and put a protocol in place that every six months all official plugins are reuploaded to the plugin section from Github.

Because I'm seriously going to cry if 2.6 breaks all my plugins again like 2.5 did.

@Linc this is good news. It is a lot of work but for both the vanilla team and developers, but I'd appreciate it is for the best.

Don't rush the canvas idea. See what options are available for the best possible fit. No point in reinventing the wheel if there is something that works well. It was a bold move event to base Garden on an existing framework foundation, and I understand the reasoning behind that, however these day you have enough work as it is, if you can save time and get a suitable solution that woudl be a good idea.

@Caylus said:
Even plugins where it's claimed to be "This product is maintained by the Vanilla Forums staff and core team." just... aren't.

I know the most recent versions are on Github, but new users won't be aware of that. They'll just see a plugin from 2014 (2014!) that doesn't work anymore and still has a stamp of approval of the Vanilla staff.

What we need here is automation. I'll see if I can get this moving as an internal project because I don't think this is something the open source community needs to be responsible for; we're the ones maintaining that code and it should be updated properly wherever we present it as such.

@Caylus said:
And I (And others) can fix plugins, but we can't upload them without changing the name.

So if I can make a suggestion: Let developer users reupload plugins with the same name as existing ones if the community has stated the old ones are broken, and put a protocol in place that every six months all official plugins are reuploaded to the plugin section from Github.

The addon directory is open source and a community asset. I'm open to altering its design (within limits) if someone will take responsibility for organizing that. Maybe we alter our policy to allow an addon to be taken over if X conditions are met, or allow multiple owners. Lots of ways to go about that. Unfortunately this is a very open-ended task that I don't think I can assign devs to in the near future. I'm willing to guide that discussion, but not be responsible for implementing a new system.

I think right now just being able to mark an addon as deprecated, unmaintained or remove it would be useful. Perhaps including version in the search.

I think there is an issue with other user taking over other's projects, really this is a fork and should be mark as such. A project may have a certain scope. If someone wants to go outside of that it should be a fork. In order not to cause issues, in that respect it should be uploaded as a fork and marked as such.

contribution to the core you are looking at the odd true believer, don't count on the bulk doing it, as it is enough to maintain their own projects (and you should value this). The more active developer the more likely they will support the project becuase you are obviously doing something right so there they have also believe in the developer program, which includes systematic documentation.

It is unlikely that many people will give up time to run a developer program for nothing, unless they have a lot of time on their hands and are comfortable or are very charitable toward businesses they like.

If you believe in a market place for addons then as a company it is in your interest to fund it. Regardless of how you feel about OS, or whether you feel they owe you.

Don't assume that becuase you have generously provided this OS solution developer will automatically work in your interest or act like staff would.

@x00 said:
I think also being realistic about the OS community will help

Don't assume that becuase you have generously provided this OS solution developer will automatically work in your interest or act like staff would.

I'm attempting to explicitly delineate where I think our interests lie and what our priorities are so that reasonable expectations are set. With unlimited resources I'd do everything that was in our interest. Given reality, I need to be stingy with everyone (internally at our company included), and thus the compromise line I drew above.

@Linc said:
What we need here is automation. I'll see if I can get this moving as an internal project because I don't think this is something the open source community needs to be responsible for; we're the ones maintaining that code and it should be updated properly wherever we present it as such.

Nice! Thanks

The addon directory is open source and a community asset. I'm open to altering its design (within limits) if someone will take responsibility for organizing that. Maybe we alter our policy to allow an addon to be taken over if X conditions are met, or allow multiple owners. Lots of ways to go about that. Unfortunately this is a very open-ended task that I don't think I can assign devs to in the near future. I'm willing to guide that discussion, but not be responsible for implementing a new system.

>

Is it possible to split off this branch of discussion with the relevant comments to a new discussion? Or should I create a new topic?

Because my personal idea was that if A ) The last update to a plugin is > 3 months, B ) community has indicated it's broken (through the existing "It's broken" button), C ) you have a custom PluginFixer permission (to prevent scammers), you're allowed to contribute to a plugin even if you don't own it (There will also of course be an option for the plugin owner to disable this update functionality entirely).

Then if a user clicks the big "download now" button they'll get the latest version, but there will also be a list available with different versions of the plugin (grouped by author/minimum Vanilla version).

So if user A owns a plugin that requires Vanilla 2.2, and uploads a new version that requires the same version, it simply gets overwritten. If user B would upload an update to user A's plugin, both A's and B's version are available, but if one clicks download now they'll get user B's version.

If user A then subsequently uploads a new version, their version gets overwritten and will become the default to download again (B's version will still be available).

If user A uploads a new version that requires Vanilla 2.5.1 though, there will be three versions available: User A's 2.5.1 one, User B's, and User A's original one for 2.2.

In that way, as a plugin author you also don't have to be backward compatible as much. If a new version doesn't work with an older version of Vanilla, people can still download the old version anyway.

I hope this image helps illustrating what I mean:

If this idea has merit and you guys are open to alter the design in the manner I described above, I'm willing to work out a first version. But to be frank, I'll need help polishing the code I crap out to make it up to par to the rest of the code of Vanilla. Which practically means I'm going to need help from either @R_J or @hgtonight since as far as I can see from the Vanilla Github they're the two open source people who have experience contributing to the Vanilla core.

So... would you guys have time to check my code if I get the go ahead to write it? O:)

I wouldn't know how to split this discussion and since the discussion has evolved, I don't think it's necessary.

You should discuss and gather ideas form the OS community in a new discussion.

You should open a GitHub issue in parallel to get feedback from Vanillas developers.

Fork the repo and start working on it. My time is currently very, very limited, but doing some code cleanup will always be possible and will also try testing. But you will find that if you make small steps and do pull requests to the official repos, you will get very valuable feedback from the Vanilla team

@Linc said:
What we need here is automation. I'll see if I can get this moving as an internal project because I don't think this is something the open source community needs to be responsible for; we're the ones maintaining that code and it should be updated properly wherever we present it as such.

Nice! Thanks

The addon directory is open source and a community asset. I'm open to altering its design (within limits) if someone will take responsibility for organizing that. Maybe we alter our policy to allow an addon to be taken over if X conditions are met, or allow multiple owners. Lots of ways to go about that. Unfortunately this is a very open-ended task that I don't think I can assign devs to in the near future. I'm willing to guide that discussion, but not be responsible for implementing a new system.

>

Is it possible to split off this branch of discussion with the relevant comments to a new discussion? Or should I create a new topic?

Because my personal idea was that if A ) The last update to a plugin is > 3 months, B ) community has indicated it's broken (through the existing "It's broken" button), C ) you have a custom PluginFixer permission (to prevent scammers), you're allowed to contribute to a plugin even if you don't own it (There will also of course be an option for the plugin owner to disable this update functionality entirely).

In that way, as a plugin author you also don't have to be backward compatible as much. If a new version doesn't work with an older version of Vanilla, people can still download the old version anyway.

Probably be better to get a trusted volunteer to upload fixes to an authors plugin, if the author agrees. there are moderators here, there are admins, there could be a plugin fixer.
Some fixes of plugins are already provided but the author doesn't have the 5 minutes to upload the fixes to the plugin and update the plugin for whatever re4ason, so the plugin fixer could take the 5 minute job to assemble the provided bug fixes.

If this idea has merit and you guys are open to alter the design in the manner I described above, I'm willing to work out a first version. But to be frank, I'll need help polishing the code I crap out to make it up to par to the rest of the code of Vanilla. Which practically means I'm going to need help from either @R_J or @hgtonight since as far as I can see from the Vanilla Github they're the two open source people who have experience contributing to the Vanilla core.

So... would you guys have time to check my code if I get the go ahead to write it? O:)

Of the 800 themes and plugins in the add-on section, probably less than 50 are bug-free and work with vanilla 2.5.1. Many probably haven't worked in years from the comments

Maybe all of them should default to broken. Despite bug reports with corrections, the downloadable code often remains unchanged by author. It would be advantageous if a simple update to downloadable plugin could be made with bug fixes, if the plugin author didn't have the 5 minutes to make the provided bug fix changes that were tested, the new position of "plugin fixer" could update the plugin.

I see a lot of potential abuse when multiple authors beyond plugin authors start adding mods instead of plain old bug fixes. willy-nilly versions and questionable improvements that might break more in the future.

linc commented on Jul 16 2017 •
>What would be a reason to remove one of the plugins?
•Addon has become obsolete by core changes, another addon, or exterior changes. I think the two 'compatibility' addons may fall in this camp, now.
•Addon is broken and no one cares enough to fix it. I suspect Mollom falls in this category.
•Addon has issues that are not resolvable or experience has taught us it wasn't as good an idea as we thought. Example: CustomizeText, Whispers.
>And it could still serve a) as an inspiration and b) as a code example.
Dead code should be used for neither, IMO. Our ecosystem is already littered with examples that are the opposite of a good idea and/or full of illegible code. Our examples should be our best curated work, not the junk heap.