Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

SilverStripe has always regarded the CMS as a natural extension of its framework, enabling developers to tailor it to the needs of website authors. You can add form fields, customise the behaviour of the WYSIWYG editor, add custom icons for the page tree, as well as create completely new sections via the ModelAdmin class. On the other hand, deeper interface customisations were hard to achieve due to the complexity of the code behind it. The 3.0 release provides us with a rare opportunity to consolidate and simplify here. 

The CMS is built using most of the tools and techniques SilverStripe developers are already familiar with when creating websites with the framework; object-oriented controllers and utility classes like CMSMenu, templates which inherit based on PHP classes, and the Form/FormField APIs. This symmetry is important to us, and the reason we decided against using full-fledged JavaScript frameworks which would define all of this on the client. Instead we’re relying on a base set of common tools such as jQuery and jQuery UI, coupled with the principles of ‘progressive enhancement’.

Behind the scenes, we’ve rewritten pretty much all JavaScript powering the CMS, in a library called jQuery.entwine. This rewrite allows us to structure larger applications like the CMS in a meaningful way, by using an inheritance structure based on CSS selectors, and exposing functionality via methods on the DOM elements. As an example, you could “subclass” the JavaScript responsible for rendering the CMS menu items, and get it to show a badge of unpublished pages automatically. And as we’re increasingly relying on custom JavaScript events, you could keep the badge updated on a form submission event. 

Overall, we’re using fewer external JavaScript libraries and try to select them based on the principles guiding jQuery UI. The new layout engine (jLayout) is a good example of this; panels and their alignments are defined through CSS classes and HTML5 data attributes, rather than explicit JavaScript calls. This makes it easier to add new panels simply by overloading a SilverStripe template. We demonstrate this in a short howto on creating a “bookmarks toolbar” in the CMS, allowing quick access to the CMS views of often edited pages. 

The CMS style-sheets were also written from scratch, with a keen eye on limiting scope and creating isolated styling components and a consistent naming structure. In version 2.4 of the CMS it can be difficult to overload styles in a way that doesn’t have side effects, for example, changing the form label alignment to allow for more editing space. Thanks to the power of CSS3, there are fewer hacks necessary to achieve these effects. In addition to simply having fewer lines of style-sheet declarations, the SCSS language extensions to CSS3 helped us to organise it in a way fitting to the needs of a large web application.

As with the previous discussions about the 3.0 design, we’re also looking for feedback on the way we’ve put the UI together technically. Particularly if you’ve extended the CMS in any way before, either as a module or custom code, we’re interested to hear your thoughts on the new directions and possibilities over on the silverstripe-dev mailing list.