Sign up to be notified when Agaric gives a migration training:
Martin Owens is a committed programmer that lives for making great code that helps people. He fully supports the Free Software philosophy and likes to publish online as much of his own code as possible. Martin hopes to work for a company where his talents can be used to make great products for users, where he can be stretched and encouraged to learn new things as well as being able to commit to the wider open source landscape where possible.
Vestibulum iaculis consectetur convallis. Donec sit amet congue massa. Quisque nec eros eu dolor posuere fermentum et vel nulla. Donec mollis leo sit amet egestas vulputate. Etiam eget ante ante. Proin dignissim justo vel nibh tincidunt, a porta dui tincidunt. Ut varius, metus ac luctus molestie, turpis magna ultricies lectus, at ornare tellus diam sit amet risus. In hac habitasse platea dictumst. Vestibulum ante ipsum primis in faucibus orci luctus et ultrices posuere cubilia Curae; Vivamus neque dui, placerat ac massa nec, rutrum rhoncus ex. Sed ut posuere urna.
Overview
This training is for people who want to get a solid foundation in Drupal site building. No Drupal experience is required!
With hands-on, guided exercises from start to finish, attendees will have the opportunity to get comfortable with Drupal's administration interface, and build a simple, fully functional website.
You will learn how different concepts relate to each other: nodes, content types, fields, views, users, blocks, taxonomy terms, and menus. By the end of the training, you will be able to identify the different building blocks of a Drupal site and know where to look when modifications are needed.
Request a Private Training
"Word as Image" by Ji Lee is licensed under CC BY-NC 4.0.
Ben spoke most recently on this topic at DrupalCon Seattle and Drupal Camp Twin Cities, both in 2019, about how Drupal as a Service can save our livelihoods and our lives. Here are some resources related to the talk and topic.
The Earth is not dying, it is being killed, and those who are killing it have names and addresses.
Utah Phillips
As far as i can tell, the Internet hasn't sourced that quotation, but no one challenges that it was Phillips— and i thought i heard him say about the same thing on the radio, in a broadcast where he also slammed NPR, boosting community radio and, if needed, the do-it-yourself be-the-media ethos. Maybe i'm part of a collective delusion, in which case, i'm sure Utah Phillips wouldn't care one way or another so long as we got on with working for the liberation of humanity and preserving life on planet Earth as part of that.
Sources cited
- Usage statistics for the core Drupal project
- Sony Music 2009 sponsorship of major multilingual improvements
- Police killing of Korryn Gaines after Facebook shut off her livestream
- Aftermath of police killing of Korryn Gaines
- How markets co-opted Free Software's most powerful weapon (Benjamin Mako Hill talk at LibrePlanet)
Crowd-sourcing this on Mastodon (itself interestingly compatible with LibreSaaS with instances like social.coop working on governance models, if not yet having the revenue to cover hosting, let alone contribute back to development:
Hello fediverse, what online tools do you know about that are LibreSaaS— you can pay to use them, but the full stack is free/libre open source software so you or others can totally host the entire thing yourself if you want?
I added whichever answers i didn't already have to the LibreSaaS list pad.
We'll keep looking for ways that cooperation can save us all (and technology can help) so sign up to get (extremely occasional, less than once a year) updates.
On Tuesday, July 7, Agaric will host 3 free online webinars about Drupal 9. We invite the community to join us to learn more about the latest version of our favorite CMS. We will leave time at the end of each presentation for questions from the audience. All webinars will be presented online via Zoom. Fill out the form at the end of the post to reserve your seat. We look forward to seeing you.
Getting started Drupal 9
Time: 10:00 AM - 11:00 AM Eastern Time (EDT)
This webinar will cover basic site building concepts. You will learn what is a node and how they differ from content types. We are going to explain why fields are so useful for structuring your site's content and the benefits of doing this. We will cover how to use Views to create listing of content. Layout builder, blocks, taxonomies, and the user permissions system will also be explained.
Introduction to Drupal 9 migrations
Time: 11:30 AM - 12:30 AM Eastern Time (EDT)
This webinar will present an overview of the Drupal migrations system. You will learn about how the Migrate API works and what assumptions it makes. We will explain the syntax to write migrations how different source, process, and destinations plugins work. Recommended migration workflows and debugging tips will also be presented. No previous experience with the Migrate API nor PHP is required to attend.
Drupal 9 upgrades: how and when to move your Drupal 7 sites?
Time: 1:00 PM - 2:00 PM Eastern Time (EDT)
This webinar will present different tools and workflows to upgrade your Drupal 7 site to Drupal 9. We will run through what things to consider when planning an upgrade. This will include how to make site architecture changes, modules that do not have D9 counterparts, what to do when there are no automated upgrade paths.
Below are the slides used during the webinars:
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
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 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.
Original Post
The struggle to take seriously the impact of racism on public health during the covid-19 crisis spotlights the importance of health communities of practice and their need to have high-quality, data-driven discussions.
Environmental racism was forced into the national conversation by Flint, Michigan years ago and COVID-19 has made long-standing problems of racism in healthcare provision impossible to ignore. The rebellion against police repression, which started in Minneapolis, is itself a reaction to the public health issues caused by policing. This reaction was predictable, and Minneapolis resident D.A. Bullock, indeed, predicted it.
So, moving forward...
How do we have data-informed conversations effectively within our communities?
How do we expand them to include more health professionals and community members from outside of what is currently recognized as the healthcare industry?
We need resolute answers to both of these questions.
Thanks to a client giving us a shout out, Agaric has come to acknowledge our experience building for health communities and the role that we are able to take in this conversation. We would love to talk and learn with others more deeply about these issues. We're hosting a "Birds of a Feather" (people interested in the same topic coming together) at DrupalCon Global today at 3:15 Eastern Time to talk about facilitating discussion among healthcare practitioners, researchers, and the public.
Here are some more questions to get you thinking!
What are the next steps for healthcare workers and researchers? What are the next steps for any person who cares about our communities? How do we move important conversations into the public realm sustainably? The stakes for both well-informed and broad-based discussion are clearer than ever. We know pressure, policy, and practice are what make change; what is our role?
Please leave your comments even if you can't join us today!
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.
