Snippets

What do you do if you want to use a Drupal.org 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:

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:

https://gitlab.com/Ambient.Impact/drupal-modules/commit/6b4b2e808cb842de83c97a722b804e1ca88a2e7f

becomes:

https://gitlab.com/Ambient.Impact/drupal-modules/commit/6b4b2e808cb842de83c97a722b804e1ca88a2e7f.patch

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

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.

The easiest way is to ensure that the config has a dependency on your module.

dependencies:
  enforced:
    module:
      - yourmodule

Then Drupal will automatically remove that configuration and also warn in the UI that it will be removed.

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.

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>.

An opinionated styleguide for writing sane, maintainable and scalable Sass.