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.


How we build things quickly—part 1: base install

Want to speed up your web builds? Steve Heyes of Bonito shares his lessons that help you do just that. Here's the first part of his blog trilogy.

Read post

Here at Bonito we love SilverStripe CMS/Framework. It’s powerful and flexible. It enables you to actually build a CMS powered website, rather than hacking something together that kind of does what you want but not quite. We’ve been using it for over five years now and I’m excited to share some of the lessons we’ve learnt along the way that can speed up web builds.

Like most agencies, we are a service business. A client will buy our time and we’ll make great things for them. As part of that, every hour we can shave off gives us the opportunity to provide better value for them and simultaneously grow our business. This allows us to have more time to keep up with our fast moving industry, build and open source modules or simply do more great work. For this reason, we wanted to streamline our production, without damaging the quality of our sites.

We did this by looking at the grunt work (not the task runner but rather the boring everyday tasks that need to be done) and figured out if we could automate some of these steps and alleviate the pressure. We found there are three ways to do this: creating a base install, making modules and generating pages. We found three ways in which to do that: creating a base install, thinking and working in modules and building scaffolding. Today we’ll be talking about the base install.

Base install

Over the years, we have developed a base install of SilverStripe that includes a number of different modules and configurations that we use day in and day out. There has been a lot of talk about base installs in the community, yet there are many different ways of setting them up. These range from a Yeoman generator to a folder you copy and paste every time you want to start a new project. For us, we forked the SilverStripe Composer installer and added what we wanted and needed.

Vagrant + Homestead

One thing we included that has saved us hours of time is adding a base Vagrant machine that is part of the installer. We decided to use a Vagrant machine for each project we’re working on and by including this machine's config within the project repo. This ensures all the developers are singing from the same hymn sheet environment wise. We went one step further from that and decided to add Laravel’s Homestead box as a dev requirement in Composer. Homestead is a great tool for quickly getting started with Laravel projects, something we do from time to time. We repurposed this package to work with SilverStripe and now to get started on a new project we can run a handful of CLI commands. This gives us a base foundation, which is ready to go within minutes rather than hours. So no more messing around with nginx and php-fpm.

Default Config & Extension

As part of this base install, we have a whole bunch of preset config settings. This includes turning off rewrite_hash_links, adding default admin user details and setting the image backend with our preferred quality. We also disable the creation of default pages, as we very rarely use them. Another change we make is hiding fields that, in our experience, have confused the user. For example, login failure count isn’t really needed for most of our users. We could manually change these settings for each project as they only take a couple of minutes to set, but the time all adds up over multiple projects. By adding it to the base install, we can set the config once and know where we stand for each project.

Base Classes

The third and final section I want to touch on is our collection of Base classes, which we use for every project. For example, we have a DataExtension for removing the ability to choose the theme from the Settings section of the CMS. For each of our projects, we only use one theme and don’t allow our users to change it.

We also have a base class for front-end forms. We have a PHPStorm plugin that enables us to create form methods really quickly, which is sufficient. However, after watching a talk by Dan Hensby at the SilverStripe London Meetup about “A Modular Approach To Forms” we thought he was on to something. So we created a Frontend Form class that is the basis of all of our forms within our projects. This, again, makes life easier by removing the grunt work.

How about you?

You may notice that there aren't any code/settings examples of our setup in this blog post. This is by choice. My aim here is to hopefully inspire you with reasons for having a base install. We have tailored our install to our specific needs as an agency. I suggest that if you do the same (and I really suggest you do, it really is super useful!) and first have a think about what you want in yours. To do so, here are a few questions that we use:

  • Does adding this remove grunt work that I find myself doing often? This is the main aim—removing the repetitive tasks that we all do every time we start a project.
  • Do I use this module/setting/class in every project? You don’t want to be removing things that you find in your base install. The aim is to create a foundation to build upon, not the other way around.
  • What are my environment requirements? Is adding a Vagrant config overkill for your needs? Are you on M/WAMP? Or maybe Docker is your thing? What settings need to be in place to use whatever it is you develop with.

I hope you find this blog post useful and it sparks a conversation around base installs. I’d love to know if you’re already doing this. Is there something glaringly obvious that I’ve missed, that you think I should have added? I'd love to hear what’s in your setup as the more we collaborate, the stronger the community gets. Let me know in the comments below.

In my next post, we’ll look at how a shift in the layout of project folder structures and where we position our classes enabled us to create better, reusable modules.


About the author
Steve Heyes

Steve is the Operations Director and Co-founder of Bonito—'a digital creative studio who guarantee understanding' in Birmingham, UK.

He believes that technology can be used to improve all areas of business to save time, money or aggravation, and is a great tool that can disrupted, improve and transform your businesses activities.

Post your comment


  • Hey Steve, is your homestead customisation open source?

    I tried running SS 3.4 on the latest Homestead (0.5.0) but had a bunch of errors - i'm guessing because it's running PHP7 and NGINX.

    Do you have some information on what you did to get both to play nice?

    Posted by Mediabeastnz, 28/06/2016 5:07pm (8 years ago)

  • Hi Leo, thanks for your comment!

    In terms of deployment, we don't use Terraform or anything related with Vagrant. What we do use is "Heydays' Beam"[] for all of our Silverstripe deployments. So we have some base settings for that in a beam.json file that is included in the base install. This include a bunch of excludes, commands and pre set servers.

    I'd like to get to the point where the local environment we use replicates the live environment as much as possible. We have spoken about building our own Vagrant box but nothing more that at the moment. Although, we currently have clients sharing a development server and live server depending on their needs so it's a bit more complicated. We are looking at moving away from that but it will probably be a year or two before we do.

    I hope that helps answer your question?

    Posted by Steve, 14/06/2016 9:53pm (8 years ago)

  • Hi, this is a great post, thanks for all the insights. In our team we naturally face the same issues and we already have a somewhat similar process (albeit not as optimised).

    My question to you would be regarding deploying this site. Do you integrate this base install process in anyway with your deployment server? For example, since you have Vagrant for your dev machines, do you integrate Terraform's (or any other tool really) to your base install that acts at deployment time?

    Cheers, looking forward for the next posts.

    Posted by Leo, 02/06/2016 6:08am (8 years ago)

RSS feed for comments on this page | RSS feed for all comments