These snippets are my attempt to save and organize various bits of code, best practices, and resources relating to web development and design. They also function as a to do list of sorts, for things I want to implement in my own code, but haven't yet. The concept is inspired by Jeremy Keith's links and CSS-Tricks, among other things. Enjoy.

How to install a sandbox module using Composer

What do you do if you want to use a sandbox project with Composer? You can’t just add it in your "require" section, as it won’t be available as a package name. Turns out you just have to define the repository in your composer.json like so:

Code language: JavaScript

"repositories": {
  "drupal/image_field_caption": {
    "type": "package",
    "package": {
      "name": "drupal/image_field_caption",
      "type": "drupal-module",
      "version": "1.x-dev",
      "source": {
        "url": "",
        "type": "git",
        "reference": "8.x-1.x"
"require": {
  // ...
  "drupal/image_field_caption": "1.x-dev",
  // ...
// ...

GitHub and GitLab commit patches

Bet you didn’t know that both GitHub and GitLab can provide you with a patch file by appending “.patch” to the end of the commit URL? I sure didn’t. For example, this commit:


This is super useful when you need to use a patch for a Composer package, etc.

Accessible websites are awesome websites

Today is Global Accessibility Awareness Day - a great day to be talking about accessibility.


Accessibility is for everyone, it’s not an edge case.

Accessibility is cumulative not binary, the more you do for accessibility the more accessible your site is.

Use semantic HTML, browsers have a lot of accessibility built in.

Make things keyboard operable by using the keyboard from time to time when you’re developing.

Finally, you don’t have to ask permission to make things accessible.

Drupal 8 install vs. optional config

The difference between a module’s install (i.e. required) config and optional config directories doesn’t seem well documented in Drupal 8, so this answer was quite informative:

  • install: The folder can contain configs, like a view or any other config. All configs will be installed, if any config fails module can’t be installed.
  • optional: The folder can contain configs, like a view or any other config. All configs will be installed if possible. If config has missing dependencies, it won’t be installed.

shame.css, or documenting your hacks

You’d be forgiven for thinking the point of this whole exercise is to shame the developers (you can always pick a name other than shame.css) but it’s really not. I am well aware of (and responsible for) hacks and quick fixes; your product owner doesn’t care if you used an !important, they just want the new feature out of the door. Hacks happen, fact.

shame.css is jokingly titled to make it a little light-hearted whilst also indicating that anything in there is a bit of a shame; a shame to have to have done, a shame to pollute the codebase with and so on…

By isolating all your hacks and bodge-jobs in their own file you can really easily keep tabs on them; isolating them isn’t to shame the developers, not at all, it’s merely to make the team aware of them and make them painfully, unmissably obvious.

The rules

Obviously you need some kind of rules and criteria:

  1. If it’s a hack, it goes in shame.css.
  2. Document all hacks fully:
    1. What part of the codebase does it relate to?
    2. Why was this needed?
    3. How does this fix it?
    4. How might you fix it properly, given more time?
  3. Do not blame the developer; if they explained why they had to do it then their reasons are probably (hopefully) valid.
  4. Try and clean shame.css up when you have some down time.
    1. Even better, get a tech-debt story in which you can dedicate actual sprint time to it.

This certainly seems like a good approach. That said, I personally prefer to have everything related to a component living with the component, but documented as a hack, possibly searchable via some sort of comment tag, like @hack <description>.