How to Lose Your Site in 10 Ways

At Pantheon, we do our best to make building, launching and maintaining a Drupal or WordPress site as easy as possible. All sites on our platform get the same PHP and MySQL configurations tuned for their applications. Every site has Varnish sitting out front to provide speed and protection against surging traffic. Our Dev/Test/Live workflow helps ensure only quality code makes it to production. Multidev allows teams to work on new features in isolation. And database backups are very easy to move around between environments.

Pantheon wants teams to develop and deploy with confidence. We see thousands of sites launch successfully each month. If things go bad at launch or over the long term, there is a good chance that one of these factors is involved:

1. Reckless Merging

Pantheon’s site architecture relies on Git. We expect code to go through the master branch to get to the development environment. Tags from that branch control the code on test and live. Our Multidev feature gives a place for feature branches to be worked on in isolation. We suggest that teams merge carefully after reviewing the work done. In practice, reviewing a branch could mean anything from a simple thumbs up across the cubicles to an in-depth pull request review to no communication at all. We don’t dictate how and when you merge into master, but your site will be more successful with an intentional process.

2. Lax Configuration Management

In Drupal and WordPress, it is a general best practice to think “code moves ‘up’ to the live environment and the database moves ‘down’ from the live environment. Configuration has been a grey area. For teams that want to treat configuration as code there are options. Drupal 6 and 7 have a Features module. Drupal 8 has CMI. WordPress has CFM.

However, none of these options force you to only move configuration up. Anyone who has seen “overridden” next to a Drupal Feature knows the uncertainty caused by a lax strategy for where configuration changes are made.

3. Moving Databases up the Chain

Some developers deal with configuration difficulty in a blunt way. On Pantheon, we suggest that once a site is live that the database in the live environment remains canonical. We can’t stop you though if you want to make configuration changes on Test and then copy the test database to Live. Please don’t do that. Sure, you might be able to run across a highway once or twice without getting run over. But don’t make a habit of it.

4. Ignoring HTTP Headers and Cookies

Pantheon puts Varnish in front of all sites, often resulting in a big performance boost. It is not magic though. Sites can still set cookies and other headers that bust Varnish and force all traffic to hit Drupal or WordPress. Before launching a site, take a moment to open up your browser’s developer tools and look at the headers. You can also use our dedicated Varnish checking tool.

5. No Frontend Performance Consideration

When it comes to the server-side/client-side dichotomy of web performance, Pantheon’s main value is on the server-side. We can’t stop you from loading 100 JavaScript files on a webpage.

6. Mystery Modules and Plugins

Pantheon’s Git logs can keep track of who added which modules and when. We can’t do much alone when it comes to answering, “why was this module installed?” Developers should write helpful commit messages that explain or link to the reasoning behind the addition of a module. Teams get bogged down when they are not certain why a plugin was added and whether it can be removed.

7. Ignore PHP Warnings and Notices

Every PHP warning and notice will slow down a site incrementally. These errors are easy to see in Pantheon’s development environments. They are hidden from the public on the live site. This difference should not be taken as an excuse to ignore the warnings.

8. Share the Admin Username and Never Change the Password

It is common in the Drupal community for all developers on the project to sign in as the admin user. Think about that for a second. Is it a good idea for everyone accessing a server to sign in as root? With drush access, you can at least avoid distributing the password and sign in through “drush uli.” Regardless, it is still worthwhile to consider signing into dedicated usernames rather than the super admin user to ensure you are working within the right levels of permissions.

9. Fear of CSS

After working on a site full-time for months, it can be easy to spot design regressions. The intended look and feel is ingrained in the team’s heads. Things get riskier a few months later when a change request comes in and the original team has moved on. Style guides and visual regression tools like Wraith can be a lifesaver here. Even just an explicit organization system like SMACSS or BEM can allow a support developer to edit with confidence. On the other end of the spectrum is one giant CSS file where each edit is just an addition of overly-specific selectors because everyone is afraid to edit what is above.

10. Lose the Ability to Set up a Development Copy of the Site

Even now, working for Pantheon I still have sites I built years ago that are not on Pantheon (yet). When I get a request to work on them, I first have to remember how to get a development copy of the site running. Download a copy of the database from … somewhere. Make sure code hasn’t been changed on the production environment. It is a hassle. And it makes it harder for me to respond quickly.

It’s important to remember that these problems tend to snowball on each other. Overridden features may make you less confident in your development copy of a site, which can make your merges more reckless. Then, suddenly, there are many more PHP warnings on a site. If you see any one of these symptoms on a site, look closer for the root cause.