How we build things quickly—part 1: base install

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.