Blog Documentation Book a Demo
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

Vanilla 2.6 is coming! Are you ready?

LincLinc Admin
edited March 2018 in Community Addons & Development

Vanilla 2.6 is coming in April. It requires PHP 7.0.

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

Happy to answer any other questions as best I can.

Comments

  • R_JR_J Admin

    @Linc said:
    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).

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

  • allanjardallanjard New

    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!

    Thanks,
    Allan

  • LincLinc Admin

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

  • LincLinc Admin
    edited February 2018

    @R_J said:
    a) why you haven't chosen an existing template engine and
    b) why a template engine came to your focus.

    What we want is Mustache but found PHP implementations to be lacking.

    Vanilla's UI & theming engine has been a perpetual topic of discussion, as you'd expect. That project was an offshoot of those discussions.

    @R_J said:
    c) do you have themes that make use of Smarty heavily?

    I don't think we've done anything on the cloud side that would qualify as "heavy" use, no.

    @R_J said:
    d) Do you have plans to release a theme that uses ebi?

    That is our eventual intention. We currently have none.

    @R_J said:
    e) will there be a new default Vanilla theme soon?

    There is a new default theme in the works.

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

    Ooooo sounds fancy :chuffed:

  • smokvinlistsmokvinlist New

    This is great!

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

  • LincLinc Admin

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

  • terabytefrelanceterabytefrelance ✭
    edited February 2018

    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.

    Regards,

  • CaylusCaylus ✭✭

    @x00 said:

    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.

  • x00x00 MVP

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

    grep is your friend.

  • LincLinc Admin
    edited February 2018

    @terabytefrelance said:
    Vanilla could have branch v2 and v3 development new not compatible previous versions.

    We've chosen to maintain compatibility (to the best of our ability) and not make a major-version break at this time. We may choose otherwise in the future.

  • LincLinc Admin
    edited February 2018

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

  • x00x00 MVP
    edited February 2018

    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.

    I like the idea of it being github driven as was discussed before.

    grep is your friend.

  • x00x00 MVP

    I think also being realistic about the OS community will help

    1. developers have limited time too.
    2. they have choice.
    3. 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.
    4. 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.
    5. 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.
    6. Don't assume that becuase you have generously provided this OS solution developer will automatically work in your interest or act like staff would.

    grep is your friend.

  • LincLinc Admin
    edited February 2018

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

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

  • x00x00 MVP

    fair enough

    grep is your friend.

  • CaylusCaylus ✭✭
    edited March 2018

    @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 :D

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

  • R_JR_J Admin
    1. I wouldn't know how to split this discussion and since the discussion has evolved, I don't think it's necessary.
    2. You should discuss and gather ideas form the OS community in a new discussion.
    3. You should open a GitHub issue in parallel to get feedback from Vanillas developers.
    4. 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
  • RiverRiver MVP
    edited March 2018

    @Caylus said:

    @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 :D

    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.

    Addons on github have a lot of discussion...

    https://github.com/vanilla/addons/issues/537

    with diverging opinion gridlock.

    from github ....

    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.

    probably the same standards should be true for addons here

    https://open.vanillaforums.com/addons

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

  • LincLinc Admin

    Due to expanding the scope to include some needed UI changes to the "connect" workflow, we're delaying the release of Vanilla Connect until the 2.7 release.

    Vanilla 2.6 will be released officially between April 5 and April 12. Ideally, it would be April 6.

Sign In or Register to comment.