Best Of

2017 marked the completion of Vanilla's migration to composer for its PHP dependencies..

This means it is no longer possible to simply clone the repo into a web directory and run Vanilla. In developer parlance, the source code and the runtime code have diverged. Now to build Vanilla's runtime code, you must install Composer. This is only necessary if you are running a non-official version directly from GitHub - the releases on this site will continue to work normally because we will be pre-building those for you (using Phing, if you're interested).

As Vanilla's frontend becomes more complex it began to use frontend dependencies through bower, then through npm. With Rich Editor the complexity of Vanilla's frontend has grown and will continue to grow. As a result Vanilla's frontend adopted Typescript and webpack to handle its growing javascript code base.

Recently a change was merged to master that removed the compiled/pre-build frontend assets from git. Instead they must be built after cloning the repo. This build has been added as post-install step for composer, so assuming you have the right dependencies, a composer install is all that you should need to get it working.

New dependencies

Building Vanilla's frontend has additional dependencies beyond PHP and composer. See our build tooling documentation for details.

How does this affect my usage of Vanilla

The affect of these changes will depend on how you install Vanilla.

I use the pre-built version of Vanilla

If your use the phing compiled version of Vanilla from or addon listing or the github releases page the nothing changes. We build these assets into that zip file.

I use Vanilla cloned from the github repo

See our build tooling documentation for details. The dependencies here are required. Once they are installed running composer install will ensure that all frontend dependencies are also installed and that all frontend assets are built.

The idea that removing a function call that calls the singleton method anyway, would provide any significant performance boost make no sense, so not sure what is meant by 'optimising'. There could be other reasons such as reducing and rationalising the code base to focus on core objectives. Fair enough.

@RJ I agree about val it is a convenience method that I'm guilty of using a little too much. Bad habit.

I'm all for improvement, however the lack of engagement with addon developers is just goign to mean they less inclined to maintain them, they will just move on and more ad more of them will be broken. Very few of us have time to completely re-factor them every new release. Breaking changes may have to be made, but sometime breaking changes aren't made to improve anything and are just code idealism, and that can be frustrating.

Perhaps it is to make it easier for the core team and easier for developers, that is fine, but unless this is communicated what is required, addon developer aren't going respond in time, if at all. Right now there is no relationship between core releases and addon releases. Merely the implication exists.

Also if the core team are goign to make sacrifices for the greater good then addon developer should be able to too. I want to cut down on what I wish to support, becuase they are either obsolete, my time is better focus on the ones that matter.

2.7 release branch has forked and we've started using it on cloud. I expect the open source official release will be along shortly. The marquee feature is a brand new text editor with a new interface designed from the ground up. It's available as an addon, so you can move to it when you're ready, regardless of when you upgrade core. I should also note that file uploads in it are currently restricted to images, so you may not be quite ready to switch if your site does a lot of file swapping via comments.

Full release notes will accompany the actual release.

It also introduces new requirements for building Vanilla from scratch (we have a Javascript build process now in core), so please beware if you like living dangerously and want to grab the branch directly. You don't need to worry about this if you get the official release when it comes out.

Don't use c() and t() because they will be deprecated:
https://github.com/vanilla/vanilla/issues/7688
https://github.com/vanilla/vanilla/issues/7687

Instead use the longer form Gdn::config() and Gdn::translate().

Something which might not been known, but has been said long before: avoiding val() is a good idea, too. Not because it will be deprecated (soon :shrug:), but simply because it is not needed oftentimes. If you now the type of the variable simply use the correct code to get the arrays element/objects property. Right now val() is purged out of Vanilla from all the places where it is possible:
https://github.com/vanilla/vanilla/pull/7689

By the way: I don't know such things because someone tells me, I simply follow what's going on on the GitHub repo. If you want to stay up to date, I recommend watching the repo

I'd also suggest reading on Gdn::get() and Gdn::set() in https://docs.vanillaforums.com/developer/framework/helpers/