31daysofsimplifyingdrupal

Use Docker! Docker lets you create virtual computers, so that you can have miniature versions of your live site.

You don't need to use Docker on its own, and probably shouldn't -- use of the environments that make it easier. Any one of these three will do the trick -- choose whichever one feels right to you.

DDEV (https://ddev.com) seems to have the biggest following within the Drupal world these days; there's even a few folks pushing to adopt it as a standard.

Let's do an easy one today. Modules display on the "Extend" in groups (called "packages") that are displayed in alphabetical order. If your company's name starts with an "A" (or maybe even a "B") then go ahead and name your package that, but if it's not then pre-pend "AA" or even "00" to the group name, like this:

name: Big Corp Custom Module X
type: module
package: 00 Big Corp

Create a custom admin interface.

Drupal makes it really easy to create beautiful and functional interfaces. Site owners put tremendous time and effort into crafting their visitor's experiences, but almost everybody just points their own people at Drupal's default bare-bones content management display and leaves it at that. Why? It's really easy to create a few custom Views for your editors -- so you should.

Use Scrum!

Everybody working on a site should have a working off-line copy of the site. (Or at least, of the portions of the site they are working on.)

Your custom modules should have ridiculously clear and complete names and descriptions.

Custom modules should have a name and description that is so clear and complete that a child could explain what it does and why it's needed. This is one area where you should not follow the example of core or contrib modules! A custom module doesn't "belong" to the programmer(s) who wrote it, it belongs to the site owner. There should be no secrets.

Happy Friday --let's talk about custom modules! The ability to create custom modules is one the most powerful features of Drupal. Most of Drupal's functionality is supplied by modules just like the ones you can make yourself. There's literally nothing that can be done in Drupal that can't be done with a custom modules. So you might be surprised to learn that my advice is:

Don't do it!

Turn off the theme! (On a development copy of your site, of course, not the live one.) When switched to an included theme, or a common contrib theme like Boostrap, everything (or at least, almost everything) on your site should function. If it doesn't, it means you've built functionality into your theme, making it brittle and hard to maintain.

You should have a site builder role that is distinct from the module developers and themers on your project. The site builder is the person in charge of the site, not the coders! A typical professional site has several content creators, several module developers, a themer, and several project managers of various types. Avoid the temptation to mix the roles. Installing, updating, and configuring modules and themes is easy to do if they're properly designed and documented, but they rarely are.

Prioritize content owners over coders. The chief editor, not the chief programmer, should be the most powerful user, with the authority to turn on and off every extension (modules/themes/etc) on the site.