What's New in Bolt 2.0
The beginnings of Bolt version 2.0 stretch back to late 2013 when work first started on a new-look responsive layout for the administration interface. Whilst this is perhaps the most noticeable change in Bolt 2.0 there's been plenty of more changes going in making the last six months the most active in Bolt's history. https://github.com/bolt/bolt/graphs/contributors.
The admin theme, based on Bootstrap 3 has been redesigned and rebuilt from the ground up to be faster, more flexible and responsive for multiple devices and screen sizes.
A Content Listing
Responsive View
The new navigation makes it even faster to navigate around the system and a new search system makes it easier to find whatever content, setting or file you need.
The new global search
All content type fields now support a group option which then organises the fields into tabs within the edit page.
Within the contenttypes.yml file you can optionally add a group to each field, for example
pages:
groups: ["content", "media"]
fields:
title:
type: text
group: content
slug:
type: slug
uses: title
group: content
body:
type: html
group: content
feature:
type: image
group: media
gallery:
type: imagelist
group: media
An improvement for contributors to Bolt, there is now a Grunt powered compile process for the JavaScript components and this has allowed the functionality to be neatly separated into smaller module files away from the previous monolithic bolt.js file.
A small but important new feature, upload buttons across Bolt now support adding multiple files.
Bolt's admin interface is now available in 15 languages with support for English, Czech, German, Greek, Spanish, Finnish, French, Hungarian, Indonesian, Italian, Japanese, Norwegian, Dutch, Portugese and Russian.
Another of the major new features for Bolt 2.0 is the Extensions Marketplace. We've used the tried and tested Composer packaging system to make Bolt much more extensible as well as providing developers with a familiar way to create and deploy packages. You can browse the available extensions at http://extensions.bolt.cm, there's already well over 50 available and this will grow with more contributions from the wider community.
If you've used the 1.x releases of Bolt you may well have used some of the bundled extensions. In designing and building the new system all 28 of the extensions bundled with Bolt 1.6 have now been ported to the new platform and are available to install with Bolt version 2.0.
Until recently it was very easy to setup and install Bolt using the traditional distribution download but we recognise that users will want to use Bolt in much more varied applications and will also want more flexibility over deployment. Here's some of the things that are now possible.
To add Bolt to an existing project you can simply run composer require bolt/bolt 2.0. If you'd like to take advantage of a few extra helper scripts that take care of installing your assets into the right place then you can see more detailed instructions here: https://github.com/bolt/bolt-docs/blob/master/source/installation-advanced.md#installing-bolt-as-a-composer-package
We've also provided a new one-command install which will take care of downloading, and configuring a basic Bolt installation. Just run composer create-project bolt/composer-install <MYPROJECT> --prefer-dist from the command line, replacing with the name of your new Bolt project.
A lot of work has been done on the internals of Bolt which allow it now to run as a self-contained HTTPKernelInterface application without interfering with any of the global namespace or constants. So if you use StackPHP (or similar) you can mount Bolt onto a url prefix as simply as this:
$map = [
"/another" => new AnotherApplication(),
"/blog" => new Bolt\Application(['resources'=>new Bolt\Configuration\Composer(__DIR__)])
];
$app = (new Stack\Builder())
->push('Stack\UrlMap', $map)
->resolve($app);
Stack\run($app);
This means that you can, for instance, use Bolt to manage one specific part of a larger application set.
One of the most frequent requests we got on the installation side was that it's not really best practice to install an entire web app inside a public directory. Whilst we wanted Bolt to be simple for users on shared hosting plans to use we can now provide the flexibility for more advanced deployment customisation.
Bolt 2.0 ships with a new configuration module that allows fine-grained control over the layout of a project. For example this is how you bootstrap Bolt where only web assets are stored in public/ and the rest of the code sits a level up:
<?php
// public/index.php
require_once "../vendor/autoload.php";
$configuration = new Bolt\Configuration\Standard(dirname(__DIR__));
$configuration->setPath("web", "public");
$configuration->setPath("files", "public/files");
$configuration->setPath("themebase", "public/theme");
$configuration->verify();
$app = new Bolt\Application(array('resources'=>$configuration));
$app->initialize();
$app->run();
Each configuration strategy takes a root directory in the constructor and then each of the component paths eg web, cache, files, themebase, config etc. can all be overridden and put wherever fits best with your hosting requirements.
There's been a lot of work done across the entire code-base to improve both the quality and most importantly the extensibility of the Bolt core. With the launch of the new Extensions system we are aiming to make it easy for developers to add to Bolt without needing to implement lots of features in the core.
A massive reorganisation of the administration template has been completed in time for version 2.0 the goal was to split the templates into much smaller and modular blocks and take advantage of Twig's template inheritance. This has resulted in the original 41 templates growing to 110 much smaller blocks and this in turn will make it much easier to override small parts of the system.
We're embarrassed to say that despite best intentions the 1.x series of Bolt still had a few global functions and occasional requires/includes sprinkled around the code-base. A concerted effort has meant that the very last few of these have finally been refactored away in time for version 2.0.
We've also taken the opportunity to upgrade Bolt's internals to move from PSR-0 to PSR-4 which has resulted in a simpler layout for the internals code.
We've implemented Codesniffer rules on all build tests and have been working hard at ensuring all code conforms to PSR-2 standards. Also we're working towards zero technical debt on Sensio Insight, here's the latest analysis.
Version 2.0 ships with a redesigned and more flexible translation system that uses simpler keys rather than English messages as the foundation for translation files, this also allows translations to follow a modular design and in turn will allow them to be extended more easily. Here's a sample from the new German translation:
panel:
latest-activity:
button:
more: "mehr Aktivitäten"
by: "von"
headline: "Letzte Aktivitäten"
logged-in: "angemeldet"
logged-out: "abgemeldet"
saved: "Gespeichert"
unknown: "unbekannt"
user-actions:
button:
add: "Benutzer anlegen"
This new system is an important step towards providing language switching on the admin interface on a per user rather than a per-site basis.
Uploading files to an old-fashioned filesystem is great but a modern web app may need many more options. To enable this the new version of Bolt ships with an all-new file management system that provides support for both local filesystems as well as:
- Ftp
- Sftp
- Dropbox
- Amazon S3
- WebDAV
This means with a few config changes you can choose to store all your files on a Dropbox account, or an Amazon S3 bucket instead.
There's also support for multiple upload strategies so you can store files both locally but also make a backup to one of the above filesystems.
Another useful new feature means that you can specify different upload directories for each contenttype via a simple configuration. For example.
feature:
type: image
upload: uploads/features
gallery:
type: imagelist
upload: uploads/gallery
We decided for various reasons that the previous Timthumb library was not a good fit for Bolt, we needed something that could mount onto the existing Silex App and also be much more extensible for developers. So Bolt 2.0 ships with a new thumbnail package bolt/thumbs which is feature compatible with the old system but offers the following improvements.
- Paths can be customised by extending or overwriting
$app['thumbnails.paths']. - There's a well defined
ResizeInterfacethat means extension writers can easily write drop-in replacements if more advanced functionality is required. - Developers can replace the response object by overwriting
$app['thumbnails.response']this allows youto customise various response headers if you need more or less aggressive caching.
This is another improvement that is designed to make life easier for extension developers. Available field types (eg html,text, integer) are now managed via a FieldManager class and all comply with a new FieldInterface. This means that adding a new field to the available options is as simple as creating a class that conforms to the interface and adding it to the manager. For an example of how simple this now is, see the docs at: https://docs.bolt.cm/v20/extensions-customfields
There was quite a few cases where the internals code would throw errors on Windows, mainly due to filesystem path differences. To try and make this more future proof Bolt 2.0 now uses the Pathogen library to generate paths, this means that internals developers should have a simpler API that makes it easier to write cross-platform code.
There were quite a few serious bugs that prevented the 1.x versions of Bolt working smoothly on PostgreSQL systems, Bolt 2.0 includes bug fixes for these occurrences and is tested fully on PostgreSQL.
Sometimes every community has to work through its very own eternal September moment. 1555 was the key turning point for what would become Bolt 2.0 and proved that despite the high risks, the core team won't shirk the responsibility of merging in ground breaking work.