Welcome to gbyte!

Occasionally I find myself needing plugin-like functionality, where users/downstream can throw a class into a folder and expect it to work. My script is supposed to find and instantiate these plugins during runtime without keeping track of their existence.

In a regular Drupal module, one would usually use the plugin architecture, but that comes with its overhead of boilerplate code and may not be the solution for the simplest of use cases.

Why would anyone use a single passphrase for several datasets?

I generally do not endorse reusing passwords, but when setting up a ZFS filesystem for home use, it is not unheard of to use a single (secure) passphrase across several of those. That's because the reason behind splitting up pools into multiple datasets is the granular control over their properties and not the resulting fun of having to type in multiple passphrases.

Want to skip this post and go straight to the repository? Bye.

No filesystem for cavemen

The features of a ZFS filesystem including pooled storage, copy-on-write, snapshots, data integrity tools, compression and encryption truly elevate your backup solution of choice. Especially after years of using EXT4/NTFS/APFS like a caveman.

abgeordnetenwatch.de is not your generic community platform - it's a tool that actively creates and enforces communication channels between the people and their political representatives thereby strengthening the democratic process while also being a comprehensive source of information of the political system in Germany.

The answer is... generally run updates first. Whether to import or export the configuration afterwards depends on who updated the contrib code base.

You are updating the contrib code base

If you are updating the contrib code base, run the database updates and then export the configuration, as updates tend to alter the configuration storage data which needs to be commited into the version control system:

When migrating content with the Drupal 8 migrate module, the creation and updating of new entities may fire lots of custom module hooks. This may or may not be desired; if you have found yourself here, it probably interferes with the source data in a problematic way, or unnecessarily slows down the migration process.

The cleanest way I found to stop specific hooks for specific migrations, is to add a dummy/meta field to the migration and check for its value in the hook.