On an editorial site, it is often useful to give articles, documents and other content types their own administration listings. Editors can then work with one type of content at a time, with an "Add Article" or "Add Document" button alongside the relevant list.

Maintaining a separate button definition for every listing means keeping the same relationship in two places. Whenever we add a listing or change which content type it shows, we need to remember to update its creation action too. This article shows how to avoid that duplication with a local action deriver.

In the previous post in this series, I described how we rebuilt our page templates with Layout Builder. I ended that post by mentioning that templates are less suitable when the page hierarchy must be derived from the data itself.

To explain that part of the rebuild, it helps to look at a more basic change. In the Drupal 7 site, an imported data object and the page that presented it were the same node, whereas the rebuilt site stores them as separate entities.

In the previous post in this series, I described how we migrated existing page elements from Panels to Layout Builder.

Pages on this site are assembled from configurable page elements implemented as block plugins. These elements display data managed by an external system. Drupal stores their arrangement and configuration, but not the underlying data.

In the previous post in this series, I described how we rebuilt our ctools page elements as block plugins.

That gave us the new implementations, but not the pages that had already been assembled in Drupal 7. Recreating them manually would have taken a long time and risked losing existing configuration along the way.

In the previous post, I described why we chose Layout Builder and how Layout Builder IPE restored the frontend editing workflow we had used with Panels IPE.

With the editing workflow in place, we still had to rebuild the elements that editors placed on their pages.

Back in 2022, we upgraded an existing brochure-style site from Drupal 7. The project has been running in different forms for many years and has accumulated a few architectural ideas that worked well, as well as others that needed reconsideration.

This is the first in a series of posts about things I learned while rebuilding and further developing that site.

Most of the information displayed on the site comes from external data sources. Instead of writing and formatting narrative content, editors select from a library of data-driven widgets. These display maps, charts, lists or key figures and provide a limited set of configuration options.

Sometimes during development, you need to run the same post update hook repeatedly. Instead of resetting Drupals internal registry on already-run updates, we can also use drush to run a specific hook manually.

If you see the error The path is not accessible in Docker when running $ fin up to get a docksal based project to run, it might be worth confirming that you are logged into docker.com by running $ docker login.

I couldn't find information on this easily, so I thought it's worth putting this here.

The equivalent of drupal_var_export() / ctools_var_export() in Drupal 8/9 is Variable::export():

Quick and dirty on linux based systems:

mysql -u$DB_USER -p$DB_PASS -D$DB_NAME -h$DB_HOST -e "show tables" -s   \
  | awk \
    -v DB_USER=$DB_USER \
    -v DB_PASS=$DB_PASS \
    -v DB_NAME=$DB_NAME \
    -v DB_HOST=$DB_HOST \
    '{ print "mysql -u"DB_USER" -p"DB_PASS" -D"DB_NAME" -h"DB_HOST" -e \"DROP TABLE "$1"\""}' \
  | sh