Here is how to deal with the surprising-to-impossible-seeming error "Unable to uninstall the MySQL module because: The module 'MySQL' is providing the database driver 'mysql'.."

Like, why is it trying to uninstall anything when you are installing? Well, it is because you are installing with existing configuration— and your configuration is out-of-date. This same problem will happen on configuration import on a Drupal website, too. (See update below for those steps!)

Really this error message is a strong reminder to always run database updates and then commit any resulting configuration changes after updating Drupal core or module code.

And so the solution is to roll back the code to Drupal 9.3, do your installation from configuration, and then run the database updates, export configuration, and commit the result.

For example:

git checkout <commit-hash-of-earlier-composer-lock>
composer install
drush -y site:install drutopia --existing-config
git checkout main
composer install
drush -y updb
drush -y cex
git status # Review what is here; git add -p can also help
git add config/
git commit -m "Apply configuration updates from Drupal 9.4 upgrade"

The system update enable_provider_database_driver is the post-update hook that is doing the work here to "Enable the modules that are providing the listed database drivers." Pretty cool feature and a strong reminder to always, always run database updates and commit any configuration changes immediately after any code updates!

Update: Steps on for resolving the unable to uninstall MySQL module error on configuration import

This is what you probably already did, before the drush -y cim failed (luckily, luckily it failed).

composer update
drush -y updb

All that is great! Now continue, not with a config import, but with a config export:

drush -y cex
git status # Review what is here; git add -p can also help
git add config/
git commit -m "Apply configuration updates from Drupal 9.4 upgrade"

Remember, after every composer update and database update, you need to do a configuration export and commit the results— database updates can change configuration, and if you do not commit those, you will undo these intentional and potentially important changes on a configuration import. If you ran into this problem on a configuration import, it is a sign of breakdown in discipline in following these steps!

Every time you bring in code changes with composer update all this must be part and parcel:

composer update
drush -y updb
drush -y cex
git status # Review what is here; git add -p can also help
git add config/
git commit -m "Apply configuration from database updates"

Photo courtesy of Women of Color in Tech stock images. CC Attribution License

Numquam eos enim voluptatem beatae doloribus. Ea provident dolor repellendus dolores adipisci laborum illo. Quas iusto vel architecto totam voluptas assumenda. Excepturi est inventore et architecto velit ratione.

Eum sed quisquam vel voluptatum enim nisi optio nobis. Deleniti corporis magnam dolore quia. Perferendis voluptatum dignissimos cum atque quasi quis est asperiores.

The entity_generate process plugin receives a value and checks if there is an entity with that name. If the term exists then it uses it and if it does not then creates it (which is precisely what I need).

So, here is a snippet of the article migration YAML file using the entity_generate plugin:

id: blog
migration_group: Drupal
label: Blog
source:
  plugin: d7_node
  node_type: blog
destination:
  plugin: entity:node
process:
  status: status
  created: created
  field_tags:
    plugin: sub_process
    source: field_tags
    process:
      target_id:
      - plugin: entity_generate
        source: name
        value_key: name
        bundle_key: vid
        bundle: tags
        entity_type: taxonomy_term
        ignore_case: true
        …

In our field_tags field we are using the Drupal 7  field_tags Values We are going to read the entities and pass that value into the entity_generate plugin to create the entities. In this example, there is a problem,  the d7_node migrate plugin (included in the migrate module) provides the taxonomy terms IDs and this will make the entity_generate plugin to create some taxonomy terms using the IDs as the term names, and this is not what we want.

So what I need to do is to get from somewhere the terms names, not their ids, to do that I need to add an extra source property.

First, we need to create a new custom module and in there create a source plugin which extends the Node process plugin, something like this (let's say that our custom module’s name is my_migration):

Create the file:

my_migration/src/Plugin/migrate/source/MyNode.php

And the file should contain this code:

namespace Drupal\my_migration\Plugin\migrate\source;

use Drupal\migrate\Row;
use Drupal\node\Plugin\migrate\source\d7\Node;

/**
 * Adds a source property with the taxonomy term names.
 *
 * @MigrateSource(
 *   id = “my_node",
 *   source_module = "node"
 * )
 */
class MyNode extends Node {

  public function prepareRow(Row $row) {
    $nid = $row->getSourceProperty('nid');
    // Get the taxonomy tags names.
    $tags = $this->getFieldValues('node', 'field_tags', $nid);
    $names = [];
    foreach ($tags as $tag) {
      $tids[] = $tag['tid'];
    }
    if (!$tids) {
      $names = [];
    }
    else {
      $query = $this->select('taxonomy_term_data', 't');
      $query->condition('tid', $tids, 'IN');
      $query->addField('t', 'name');
      $result = $query->execute()->fetchCol();
      $names[] = ['name' => $result['name']];
      foreach ($result as $term_name) {
        $names[] = ['name' => $term_name];
      }
    }
    $row->setSourceProperty('field_tags_names', $names);
    return parent::prepareRow($row);
  }
}

It does the following things:

• It reads the nid of the article
• Gets all the terms IDs of the field_tags field
• For each ID, it gets the name of the term and put it in the `names` array
• Finally, it sets this value inside the $row using the `setsourceProperty` method.

Now our rows will have a property called fields_tags_names with the terms names, and we can pass this data to the entity_generate plugin.

We need to make a few adjustments in our initial migration file,  first and most important update the  source plugin to use our new source plugin:

source:
  plugin: my_node
  …

And update the source in the field_tags field to use the new  field_tags_names source property.

  …
  field_tags:
    plugin: sub_process
    source: field_tags_names
  ….

The final migration file looks like this:

id: blog
migration_group: Drupal
label: Blog
source:
  plugin: my_node
  node_type: blog
destination:
  plugin: entity:node
process:
  status: status
  created: created
  field_tags:
    plugin: sub_process
    source: field_tags_names
    process:
      target_id:
      - plugin: entity_generate
        source: name
        value_key: name
        bundle_key: vid
        bundle: tags
        entity_type: taxonomy_term
        ignore_case: true
        …

And that’s it; if we run the migration, it will create on the fly the terms if they do not exist and use them if they do exist.

CKEditor is well-known software with a big community behind it and it already has a ton of useful plugins ready to be used. It is the WYSIWYG text editor which ships with Drupal 8 core.

Unfortunately, the many plugins provided by the CKEditor community can't be used directly in the CKEditor that comes with Drupal 8. It is necessary to let Drupal know that we are going to add a new button to the CKEditor.

Why Drupal needs to know about our plugins

Drupal allows us to create different text formats, where depending on the role of the user (and so what text formats they have available) they can use different HTML tags in the content. Also, we can decide if the text format will use the CKEditor at all and, if it does, which buttons will be available for that text format.

That is why Drupal needs to know about any new button, so it can build the correct configuration per text format.

Adding a new button to CKEditor

We are going to add the Media Embed plugin, which adds a button to our editor that opens a dialog where you can paste an embed code from YouTube, Vimeo, and other providers of online video hosting.

First of all, let's create a new module which will contain the code of this new button, so inside the /modules/contrib/ folder let's create a folder called wysiwyg_mediaembed. (If you're not intending to share your module, you should put it in /modules/custom/— but please share your modules, especially ones making CKEditor plugins available to Drupal!)

cd modules/contrib/
mkdir wysiwyg_mediaembed

And inside let's create the info file: wysiwyg_mediaembed.info.yml

name: CKEditor Media Embed Button (wysiwyg_mediaembed)
type: module
description: "Adds the Media Embed Button plugin to CKEditor."
package: CKEditor
core: '8.x'
dependencies:
  - ckeditor

Adding this file will Drupal allows us to install the module, if you want to read more about how to create a custom module, you can read about it here.

Once we have our info file we just need to create a Drupal plugin which will give info to the CKEditor about this new plugin, we do that creating the following class:

touch src/Plugin/CkEditorPlugin/MediaEmbedButton.php

With this content:

namespace Drupal\wysiwyg_mediaembed\Plugin\CKEditorPlugin;

use Drupal\ckeditor\CKEditorPluginBase;
use Drupal\editor\Entity\Editor;

/**
 * Defines the "wysiwyg_mediaembed" plugin.
 *
 * @CKEditorPlugin(
 *   id = "mediaembed",
 *   label = @Translation("CKEditor Media Embed Button")
 * )
 */
class MediaEmbedButton extends CKEditorPluginBase {

  /**
   * Get path to library folder.
   * The path where the library is, usually all the libraries are
   * inside the '/libraries/' folder in the Drupal root.
   */
  public function getLibraryPath() {
    $path = '/libraries/mediaembed';
    return $path;
  }

  /**
   * {@inheritdoc}
   * Which other plugins require our plugin, in our case none.
   */
  public function getDependencies(Editor $editor) {
    return [];
  }

  /**
   * {@inheritdoc}
   * The path where CKEditor will look for our plugin.
   */
  public function getFile() {
    return $this->getLibraryPath() . '/plugin.js';
  }

  /**
   * {@inheritdoc}
   *
   *  We can provide extra configuration if our plugin requires
   *  it, in our case we no need it.
   */
  public function getConfig(Editor $editor) {
    return [];
  }

  /**
   * {@inheritdoc}
   * Where Drupal will look for the image of the button.
   */
  public function getButtons() {
    $path = $this->getLibraryPath();
    return [
      'MediaEmbed' => [
        'label' => $this->t('Media Embed'),
        'image' => $path . '/icons/mediaembed.png',
      ],
    ];
  }
}

The class's code is pretty straightforward: it is just a matter of letting Drupal know where the library is and where the button image is and that's it.

The rest is just download the library and put it in the correct place and activate the module. If all went ok we will see our new button in the Drupal Text Format Page (usually at: /admin/config/content/formats).

This module was ported because we needed it in a project, so if you want to know how this code looks all together, you can download the module from here.

Now that you know how to port a CKEditor plugin to Drupal 8 the next time you can save time using Drupal Console with the following command:

drupal generate:plugin:ckeditorbutton

What CKEditor plugin are you going to port?

Presentations and Workshops:

2020

• Boston College online interview on AI and Free Software
• WMBR - Online interview on Free Software solutions for communications
• Platform Cooperative Ideathon
• MayFirst Need to Know Series

2019

• Boston College Stokes Hall on AI and Free Software
• Micky and Ben present at DrupalCon Seattle on Scaling Community Decision Making
• Keynote - LibrePlanet 2019
• Micky's Resource Links from LibrePlanet Keynote
  • How can we prevent the Orwellian 1984 digital world? - March 2019 - M.I.T. Boston, MA USA
• Keynote - NERDsummit 3/24/2019 - UMASS Amherst
• UjimaBoston
  • Series of four workshops on Free Software and Platform Cooperativism in January 2019

2018

• 3rd Regional Workers Encuentro
  • "Communications & the Workers' Economy" (workshop) Mexico City CDMX
• Center for Global Justice Assembly
  • "Securing your devices and using free software" (workshop) San Miguel de Allende, Mexico
• LibrePlanet 2018
  • Connecting communities with schools and free tools (workshop) M.I.T. Boston, MA USA, Facilitators: Micky Metts, Chris Thompson
• New Economy Coalition's CommonBound - St. Louis, MO USA
  • Technology for the New Economy

2017

• Open.coop 2017 - London University, London, UK
  • Panel: Empowering digital collaboration: Introducing the open app ecosystem
  • Workshop: Designing interoperable apps for the open app ecosystem

Sign up to be notified when Agaric gives a migration training:

Updated 2025-11-14: NEDcamp2025 slides markdown source

You've built sites with Drupal and know that with a few dozen modules (and a ton of configuring), you can do nearly everything in modern Drupal.

But what do you do when there's not a module for that? When the modules that exist don't meet your needs, and cannot be made to by contributing changes?

You make your own.

This blog post accompanies the New England Drupal Camp session and helps you take that step. All you need to do is write two text files. The first file tells Drupal about the module; it is not code so much as information about your code. The second file can have as little as three lines of code in it. Making a module is something that anyone can do. Every person developing a module is still learning.

Slides source code: https://gitlab.com/agaric/presentations/when-not-a-module-for-that

(Site with slides coming.)

This is about the simplest module you can make, and—unlike the popular implications of its name—is not growing by adding bits and pieces of other modules as we build a monstrosity (that is what we will do later, as exhuming and incorporating adaptations of other modules' code is our main technique for making new modules).

Frankenstein (example) | Drupal.org

Sharing your module out into the world

Put your module on Drupal.org: drupal.org/node/add/project-module

(I honestly do not know where they hide that link, but remember on any Drupal site you can go to /node/add and see what content you have access to create, and that includes creating projects on Drupal.org!)

It will start its life as a "sandbox" module by default.

Tip: Do not try to choose a part of core under "Ecosystem", and always check that the node ID it references is really one you want— there are a lot of projects with similar or even the same name.

Do not get overwhelmed; you can come back and edit this page later.

Press Save.

Then press the Version control tab to go to a page with Git instructions tailored to your module.

If you have already started your module and made commits in a repository dedicated to only your module, make certain your commits are on a branch named 1.0.x (the instruction included there git checkout -b 1.0.x will be enough to do that) and then follow only the git remote add and git push steps.

Double-checked to make certain the "Frankenstein" example module would not be better an example of when already "There's a module for that" and discovered the sad backstory— it exists in Drupal 7, people wanted it ported to modern Drupal, someone did port it to modern Drupal, but in a private GitHub repository and module maintainers did not take action and now that repo is gone.

Contributing to an existing module

(To do: Make into its own post.)

I apologize, on behalf of all of Drupal, that this is harder than it ought to be.

First, create an issue (if there is not one already) stating the needed feature or bug fix.

Before you start modifying the module's code, go into your project's composer.json and edit the version of the module you are using and want to contribute to and make it the dev version.

If you have gotten the module as ^3.0@RC for example, change that to ^3.0.x-dev@dev.

Run composer update.

Now, so long as you do not have a restriction in your composer.json, composer will get the git repository of that module for you and put it in the usual place for contributed modules, such as web/modules/contrib.

From the command line (terminal), change directory to the module you are modifying and have filed an issue against (for instance, cd web/modules/contrib/example).

Back on your issue, press the light green "Create issue fork" button and follow the instructions it adds to the issue to issue under the "Show commands" link, to the right of the issue fork.

The lines you want to copy paste are under the first "Add & fetch this issue fork’s repository" and the "Check out this branch" copy code sections in that expanded "Show commands" section.

Make your code changes and git add them. You can copy the entire line to git commit from the bottom of the issue. And finally, git push.

Now you need to make a merge request.

In the issue, press the link to your issue fork. If you do not see a blue button "Create merge request" at the top of this page, you need to log in. Pressing "Sign in" is likely to log you in automatically because you are already logged in to Drupal.org, but you have to press it.

Press the blue "Create merge request" button at the bottom of the form pressing the first blue "Create merge request" button took you to.

To keep using the improvements you contributed to the module while waiting for them to be reviewed and, with lots of luck, eventually merged in, make a couple more modifications to your project composer.json file. The information you need is the same as you put into the module's git configuration with the issue fork repository and branch checkout commands you copy and pasted above. We can get that information again most easily by opening up the .git/config file in the module (or theme) you have been contributing to, and use the URL under "origin" in your "repositories" section of your composer.json and the branch name at the bottom of the .git/config in the "require" section, like this:

    "repositories": {
        "drupal/example": {
            "type": "git",
            "url": "https://git.drupalcode.org/issue/example-123456.git"
        }
    },
    "require": {
        "drupal/example": "dev-123456-issue-fork-branch-name",
    },

Very, very helpful to go along with that, add this to a ~/.gitconfig file (or the equivalent on your OS).

# Git push helper via https://www.jvt.me/posts/2019/03/20/git-rewrite-url-https-ssh/
[url "ssh://git@github.com/"]
	pushInsteadOf = https://github.com/
[url "ssh://git@gitlab.com/"]
	pushInsteadOf = https://gitlab.com/
[url "ssh://git@git.drupal.org/"]

Resources

• How to become project owner, maintainer, or co-maintainer | Offering to become a project owner, maintainer, or co-maintainer | Drupal Wiki guide on Drupal.org

Drupal Slack channels

First, join Drupal Slack if you need to; more info on that at drupal.org/slack.

• #support
• #general
• #contribute
• #maintainers

Drupal Hooks

Old-style hooks take the hook name ("hook_something_cool") and replace hook with the module machine name ("example") and so having a function example_something_cool— this was the old way of doing namespaces with a sort of honor system. You do not have to worry about that anymore except insofar as you can recognize this style of hook in existing code to use as examples when you are writing new, cool hooks that use actual PHP namespaces.

The Drupal API's listing of all hooks (at api.drupal.org/api/drupal/core!core.api.php/group/hooks) opens with examples of implementing and changing the order of hooks.

The main thing it leaves out is where you actually put the hook implementations: In your module's folder inside a src/Hook subdirectory. Each set of hooks that will be called at the same time or that . At the top of this file goes a namespace declaration:

namespace Drupal\example\Hook;

Not changing example (or whatever it is in the example you copy) to match your module's machine name, or forgetting or making a typo in this line, is the first thing to check for if your hook does not seem to be having any effect.

The listing of hooks to see ways you can, well, hook into Drupal is a bit lower down on that page.

It is often enough throughout the journey of building websites that you will desire to create very specific lists of content. In my current endeavor, I am working in Drupal 9 with 2 content types: Office location and Event . Each Event occurs at an Office location, which is indicated by an Office location entity reference field on the Event. Note that any info in this blog will also be relevant to Drupal 8, Drupal 10, and beyond.

Here is the user story that we will be working through:

As a site visitor, when I view an Office location node, I should see a list of Events that are occurring at the location represented by the current node, so that I have an easy way to learn about events at locations relevant to me.

To keep this short and sweet, I am going to assume that you have already created a view. However, all views are not created equal, so if you are not seeing the options that you are looking for while editing your view, maybe try creating a new one. We will be working with a block display—other options are possible, but this is the standard "Drupal approach".

Once you are editing a block display for your view, open the Advanced dropdown on the right side. Here is what you will see:

The movements and networks that Micky is a part of

Here are all the links from the slide Micky told you not to try to write everything down from.

Agarics are members of a few networks and movements both local and global:

• Free Software Foundation - fsf.org
• United States Federation of Worker Cooperatives - usworker.coop
• Solidarity Economy Network - ussen.org
• May First People Link - MayFirst.org
  • Technology and Revolution - techandrev.org
• Industrial Workers of the World - iww.org
• Platform Cooperativism - platform.coop
• The Center for Global Justice - globaljusticecenter.org
• The TechWorkerCoop - techworker.coop
• Mass MeshNet - MassMesh.org
• Radical Connections Network - RadicalConnections.net

Additional groups and movements

And some that didn't make the slides, that other Agarics are a part of:

• LibreSaaS
• Incarcerated Workers Organizing Committee
• Visions Unite (People Who Give a Damn)
• Cooperation Jackson
• IndieWeb

Learning objectives

• When it makes sense to make a module (the hierarchy of code usage).
• Options for extending and overriding functionality provided by Drupal core and other modules.
• How to write a module that plays well with Drupal core and other modules.
• How to build a contrib-worthy module.
• Working with version control and Drupal's GitLab instance.
• The steps to opting in to Drupal security coverage and collaborating with the security team.
• Ways to contribute to or even maintain an existing module (avoiding making one!).
• And how to continue learning on your own.
• After this training you will be able to make Drupal modules, and contribute and maintain them on Drupal.org!

Prerequisites

The only prerequsite is having done some site building with Drupal, and so having familiarity with Drupal configuration and its limits. Information gained will be equally relevant to any version of modern Drupal, including 10, 11 and the coming Drupal 12.

This training is targeted to beginners, but as it is chock full of tips we expect people at intermediate and even advanced levels with Drupal to get significant benefit.

Making a module is something that anyone can do.  A useful one may be only two files with a few lines each.  There are many (mostly simple) rules to follow and tons of tools to use—and lots of exploration to do. Every person developing a module is still learning!

Setup instructions

A working Drupal 11 installation using DDEV will be provided.

This training will be provided over Zoom. You can ask questions via text chat or audio. Sharing your screen is optional, but you might want to do it to get assistance on a specific issue. Sharing your camera is optional.

What to expect

Prior to the training

Attendees will receive detailed instructions on how to setup their development environment. In addition, they will be able to join a support video call days before the training event to make the the local development environment is ready. This prevents losing time fixing problems with environment set up during the training.

On the days of the training

• The training totals 7 hours of instruction, which we usually split into 2 sessions
• A team of developers available to answer questions and help with training-related issues

After the training

• Attendees will receive a copy of the training recording.
• Attendees will receive a certificate of completion.

LibrePlanet is an annual conference hosted by the Free Software Foundation for free software enthusiasts and anyone who cares about the intersection of technology and social justice. We've attended and spoken at LibrePlanet many times over the year. This year's theme is "Trailblazing Free Software" and in that spirit Micky is speaking on the Orwellian future that has arrived and what tech justice movements we should be supporting and joining to fight for a freedom-loving, solidarity-based future.

LibrePlanet Keynote: How can we prevent the Orwellian 1984 digital world?

Sunday, March 24th

5:15pm-6:00pm

Stata Center, Massachusetts Institute of Technology Room 32-123

Cambridge, MA

We are living in a society where -- as mere individuals -- it seems out of our control and in the hands of those who have the power to publish and distribute information swiftly and widely, or who can refuse to publish or distribute information. Algorithms now sort us into Global databases like PRISM or ECHELON, and there are devices such as StingRay cell phone trackers used to categorize our every movement. We may build our own profiles online, but we do not have access to the meta-profile built by the corporate entities that our queries traverse as we navigate online, purchasing goods and services as well as logging into sites where we have accounts. The level of intrusion into our most private thoughts should be alarming, yet most fail to heed the call as they feel small, alone, and unable to defy the scrutiny of disapproval from the powers that govern societal norms and their peers. Together, we can change this.

Micky will engage your mind on a journey to open an ongoing discussion to rediscover and reawaken your own creative thought processes. Together, we build a conversation that should never end as it will join us together transparently maintaining our freedoms, with free software as the foundation. Where do we find our personal power, and how do we use it as developers? Do we have a collective goal? Have you checked your social credit rating lately? Others have.