Drupal Planet

Ok, this one is going to be controversial, but hear me out. There's a lot of complicated programming contained within any Drupal site, but unless you've done something wrong it all plugs into Drupal's administrative interface, which can be operated by any reasonably tech-literate person. There is no reason the people who operate the administrative interface need to be experts in the arcane details of Drupal programming. While you need programmers to write the modules and themes, you don't need them to install the components for you -- you can, and should, take care of that yourself.

Everyone knows what a wireframe is -- the name practically describes it, it's a sketch that looks like it's made out of wires. Or, more likely, drawn with a pen on a napkin. You probably think it's done with simple boxes and lines because that's easier, right? So when you have a meeting to look at wireframes, and you see some beautiful comps made in photoshop that look just like web pages, with colors and textures and photos and everything, you should be happy -- that's better! Right? Isn't it?

It's not. Send it back, and demand the sketches.

At its surface, Drupal seems to be a lot of CSS and Javascript being pushed around by lots and lots of PHP code -- these days with healthy chunks of Composer, Twig, and some other things.  Inside, though, at its core, is a SQL database.  (Usually -- but if your Drupal site isn't running SQL, you're probably not actually interested in simplifying Drupal.)

From its earliest days, major version upgrades of Drupal were difficult. New versions were incompatible with previous versions, requiring lots of work to upgrade from one version to the next. But the magnitude of the change from Drupal 7 to Drupal 8 was much larger than any changes before or since. 

It's commonly agreed that one should refrain from making changes on a "live" website, and instead use various techniques to make changes in some offline location and then push them to production. I do this for most of my own sites, and it's often required at large organizations. But it's not the only approach. I was recently surprised to discover that a number of web developers that I respect and admire maintain sites without an automated push technique. They'll figure out how to do something offline, then recreate it by hand on the live site.

It's tempting to create a role for each job title that is going to access the site. Don't do it! "Role" might sound like a synonym for "job," but don't be fooled -- it's just a friendly term for a collection of privileges. Roles are convenient in small quantities, but they get to be a hassle when you get more than a handful. Here's a tip: if there are too many columns to fit on the "Permissions" screen without scrolling, you probably have too many roles. 

Choose your roles carefully, and try to limit their number.

The job-listing sites are filled with ads looking for Drupal developers who have years of experience building Drupal sites, and are experts in object-oriented PHP programming, and are skilled with React and headless development, and are experts in SASS and Gulp and the rest of the front-end toolchain, and can create documentation for executives, and can design information architectures and user interfaces, and train the editorial staff, and optimize the SEO and e-commerce conversions, and...you get the idea.

Ok, this one might raise some eyebrows. I don't work for Pantheon, and they don't pay me. I've had many clients with sites on Pantheon, but also on Acquia Cloud Host, Platform.sh, AWS, Digital Ocean, and countless general-purpose hosting providers. Each of them have something (often quite a bit) to offer, but this series isn't about making Drupal better or cheaper or fancier -- it's about making Drupal simpler. And in that respect Pantheon stands head and shoulders above all the other options I've seen.

We understand: Drupal is made out of code, so it makes sense to put the master of code in charge of the site, managing all the other lesser coders. Don't do it! For one, it dumps a whole lot of non-coding responsibility on them, and you get a lot of value having them do what they do best. But perhaps more importantly, it puts responsibility for making sure the site works for everybody on the shoulders of somebody who doesn't really think like the rest of the people in the company.