Planet Drupal

Brad Jones, a digital nomad and seasoned Drupal developer, merges his technical expertise and unique experiences as a part-time paramedic. His proposal, "JSON Data and Schemas FTW!", aims to revolutionize Drupal's data management by integrating JSON data types. Recognized at DrupalCon Pittsburgh's Pitch-burgh Innovation Contest, this initiative seeks to enhance flexibility and interoperability within Drupal.

Work in Progress (WIP) is a well-known concept for optimising efficiency in various business processes. It is straightforward to understand and apply. In this article, we will show you how, and give examples how we apply it with a team of around 100 colleagues.

Here's what I've been working on for my Drupal contributions this week. Thanks to Code Enigma for sponsoring the time to work on these.

Takeaway: Provus®Gov emerges as the superior choice for forward-thinking government entities. Powered by Drupal, Provus®Gov as an open-source, plug-and-play platform offers unmatched flexibility, scalability, and advanced features that grow with your needs. Its user-friendly interface empowers non-technical staff, while robust security measures and built-in accessibility compliance ensure your site meets the highest standards.

Background: This blog post is part 2 of musings around legacy code on violinist.io. Violinist.io is an automated dependency updater for PHP/Composer. It's a SaaS built on Drupal 8, now running on Drupal 10, in its eigth year. In this second post I am looking at one way to approach legacy code, and how to use static analysis and test driven development to safely refactor and remove legacy code.

Some months ago I wrote about the combined feeling of shame and respect that surrounds legacy code. In an attempt to get rid of the legacy code in what is called cronner.module, I will start from the top of the .module file, and work my way towards removing it completely. From time to time, that can also result in a good blog post, I thought. Here's a blog post about that.

The first lines of the module file is this:

<?php /** * @file * Cronner module. * * Bad name, but what are you going to do, right? */

The code here sounds a bit resigned when it asks about what are you going to do. But in this blog post, what are we going to do? We will start the process of getting rid of all of it, that's what we will do!

The first few lines of actual code are constant definitions. Here's the first one:

define('CRONNER_STATE_KEY_PREFIX', 'cronner_state.node.');

So far we can speculate, but it seems to be a prefix. And it's used for storing some state about nodes. Defining constants like this might seem strange if you are a bit new to Drupal, but this way of defining constants was canonical in Drupal 7 and below, but also followed a lot of codebases into the Drupal 8 era. Drupal core as well actually. One such example is the constant FILE_EXISTS_RENAME which lived on until Drupal 9 (deprecated in 8.7.0). Anyway I digress.

What we want then, is to remove this one constant. Let's just try that and see what breaks? Here's the output from phpunit:

There were 19 errors: … Error: Undefined constant "CRONNER_STATE_KEY_PREFIX”

The unit tests are failing. 19 of them. Good start, we have decent unit test coverage. Let's see if our integration tests fail?

xxx scenarios (xx passed, 112 failed) xxxx steps (xxxx passed, 49 failed, xxx skipped) xxmxx.xxs (90.59Mb)

112 scenarios failed in our behat test suite. Great indication that we can remove things safely! Lastly let's do some static analysis with PHPStan:

Line web/modules/custom/cronner/cronner.module ------ --------------------------------------------------------------------- xxx Constant CRONNER_STATE_KEY_PREFIX not found.

As expected, PHPStan also informs me about this change being a problem. Thanks PHPStan! It also indicates that among the scanned files, the constant is only used once. It's used like this:

/** * Gets the state key of a node. */ function _cronner_get_state_key(NodeInterface $node) { return CRONNER_STATE_KEY_PREFIX . $node->id(); }

In addition to the comment being very little helpful, this tells me I have just encountered another part of the cronner module to remove. Let's remove this entire function as well since we already know the function must be covered by both unit tests and integration tests. Then let’s go ahead and use a combination of TDD and static analysis (with PHPStan) to make sure our refactoring is successful. I remove the function and re-run PHPStan:

Function _cronner_get_state_key not found. … [ERROR] Found 7 errors

PHPStan is helpfully pointing out all of the 7 places I should start with the refactoring. I look through some of them and see the usages are quite connected to some of the other constants in the beginning of the file:

define('CRONNER_PROJECT_NEW', 'new'); define('CRONNER_PROJECT_QUEUED', 'queued'); define('CRONNER_PROJECT_RUNNING', 'running'); define('CRONNER_PROJECT_PROCESSED', 'processed'); define('CRONNER_PROJECT_ERRORED', 'errored'); define('CRONNER_PROJECT_UNKNOWN', 'unknown');

My mother always used to say. When you are tidying up your room it’s best to keep going while you are somewhat effective in deciding what to get rid of. If you find some of your old toys and start to play with them, it’s an indication that the tidying session is heading towards an unproductive state. And right now I feel effective and decide right away I am removing those constants as well. I guess that also makes the analogy to me tidying my room as a kid kind of weird, since the opposite would mean these constants were my toys, and I end up playing with them? I mean, I do end up playing with old code from time to time, but constants? No fun playing with.

But looking at these old toys, it also becomes obvious what we use these constants for. Node state could mean all kinds of things, right? This is used to store and update the job status of the projects. Like if they are currently queued, if they are currently running and so on.

So it turns out that while removing this, this actually seems like a good opportunity to clean up some of that code and make it a bit more modern. What I usually do when cleaning up custom code like this is to put as much as possible on drupal.org as open source code. This is the case now as well. So I open an issue to create a project run status service, and start to refactor the custom code and logic surrounding the removals of constants and functions in cronner.module. It can be found here: https://www.drupal.org/project/violinist_projects/issues/3453459.

Now I go ahead and start using this service. It quickly becomes obvious that some of the constants are also used in a map to display a human readable status to the user:

/** * Gets a human readable version of a status constant. * * @param string $status * A status constant. * * @return string * Something more sensible. */ function cronner_get_human_status($status) { $map = [ CRONNER_PROJECT_UNKNOWN => t('Unknown'), CRONNER_PROJECT_ERRORED => t('Errored'), CRONNER_PROJECT_PROCESSED => t('Processed'), CRONNER_PROJECT_RUNNING => t('Running'), CRONNER_PROJECT_NEW => t('New'), CRONNER_PROJECT_QUEUED => t('Queued'), ]; return !empty($map[$status]) ? $map[$status] : $status; }

There’s also methods for getting a state from a node, and setting it. Which I am also removing, and finding usages of in static analysis:

xxx Function cronner_set_state not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbols xxx Function _cronner_get_state_key not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbols xxx Function cronner_get_human_status not found. 💡 Learn more at https://phpstan.org/user-guide/discovering-symbols

Or in unit tests like so:

ReplaceTokensTest::testClaimJobAndTokenReplaced Error: Call to undefined function cronner_set_state()

Instead of these calls to getting the state, setting the state, and getting the human readable state, I am now using the newly created service. When I started writing this blog post I was very much looking forward to summarizing the numbers of deleted lines and how great that was, but in practice some of the changes are actually adding lines to the module:

- cronner_set_state($node, CRONNER_PROJECT_PROCESSED); + /** @var \Drupal\violinist_projects\ProjectRunStatus $run_status_service */ + $run_status_service = \Drupal::service('violinist_projects.run_status'); + $run_status_service->setRunStatusForProject($node, ProjectRunStatusValue::STATUS_PROCESSED);

Jokes aside. After some successful deletions and refactorings into using a service I am looking at 99 deletions and 55 additions. A net positive result I would say. Unfortunately there is still quite a way to go before I can go ahead and delete the entire folder called “cronner”. But at least I managed to refactor the codebase and delete the first 7 lines of constants in the file.

To celebrate this tiny step towards getting rid of cronner.module I tried to search for cronner on giphy. No hits, at this point. Oh well, here is an animated gif that supposedly illustrates “cronn”

 

Reflecting on DrupalCamp Asheville 2024, the event featured a vibrant mix of workshops, sessions, and social activities. April Sides, the event organizer, highlighted the emphasis on inclusivity and community building in her conversation with The DropTimes. Attendees enjoyed hands-on learning experiences, an interactive Unconference, and a scenic hike in the Blue Ridge Mountains, making it a memorable event for all. The organizers plan to expand outreach to local educational institutions in future events to grow the Drupal community further.

Here's what I've been working on for my LocalGov Drupal contributions this week. Thanks to Big Blue Door for sponsoring the time to work on these.

This step-by-step series has covered a lot of ground on planning and preparing for a Drupal 7 to Drupal 10 migration. Today, we start putting that knowledge into practice by automatically migrating content types. First, we will execute a migration to pull all content types in Drupal 7. Then, we will customize the migration to remove unnecessary content types. Finally, we will learn how a separate node title label migration also affects content type configuration in Drupal 10.

Read more mauricio Thu, 07/25/2024 - 06:32

As Drupal 7's end-of-life (EOL) approaches on 5 January 2025, many users have questions about what this means for their Drupal websites and what steps they need to take. Here, we address the most frequently asked questions to help you navigate this transition.

What does end-of-life mean for Drupal 7?

End-of-life (EOL) means that Drupal 7 will no longer receive security updates, fixes, or official support from the Drupal community after 5 January 2025. This will impact the security, compliance, and functionality of any site that continues to run on Drupal 7.

Why is Drupal 7 being retired?

Drupal 7 will be 14 years old when it reaches the end of life. That's a long time in the software world. Drupal 7 is being retired to allow the Drupal community to focus on newer versions built with a more modern architecture and more advanced capabilitie. This shift ensures that resources are directed towards maintaining and innovating the more modern versions of Drupal, including the Drupal Starshot intiative.

What are the key dates I need to know?

• 23 February 2022: Announcement of Drupal 7 EOL extension.
• 1 August 2023: Commencement of reduced support for moderately critical issues, alongside other support changes.
• 5 January 2025: Official end-of-life date for Drupal 7.

How will security support change?

Once Drupal 7 reaches its EOL, no further security advisories or updates will be provided. If you must remain on Drupal 7, we recommend opting for a commercial vendor who offers extended support. HeroDevs Drupal 7 Never-Ending Support (NES), is the first such offering available. This service is a seamless drop-in replacement for Drupal 7, providing your site with ongoing security updates, compliance support, and compatibility fixes past end-of-life.

What happens to unsupported modules and themes?

Starting 1 August 2023, any unsupported Drupal 7 module or theme will no longer be eligible for new maintenance once it goes unsupported. If a module or theme you rely on becomes unsupported, it’s crucial to proactively adopt or migrate it to a newer version. HeroDevs Drupal 7 NES also provides module support if you choose that route.

What are the PHP version requirements?

From 1 August 2023, Drupal 7 no longer supports PHP versions lower than 5.6. Further increases in the minimum PHP requirement may occur before Drupal 7's EOL.

Are there any specific operating system considerations?

Drupal 7 security fixes for Windows-only issues ceased on 1 August 2023. If your site runs on Windows, migrating to another operating system is recommended.

Will drupal.org continue to package Drupal 7 distributions?

No, as of 1 August  2023, Drupal.org stopped packaging Drupal 7 distributions. Users needing a distribution built must use Drush make locally.

What are my options moving forward?

1. Migrate to Modern Drupal: Upgrading to Drupal 10 or the upcoming Drupal 11 is strongly recommended to ensure continued security, support, and access to new features. Modern Drupal versions adopt the latest PHP standards and offer enhanced performance and security. In addition, Drupal Starshot is coming at the end of 2024, which bundles Drupal core with cutting-edge features and easier maintenance.
2. Extended Security Support: The Drupal Association has partnered with HeroDevs to offer Drupal 7 Never-Ending Support (NES). This service provides ongoing security updates, compliance support, and compatibility fixes for Drupal 7 sites, allowing businesses more time to transition.
3. Stay on Unsupported Drupal 7: Continuing to use Drupal 7 after its EOL is an option but comes with significant risks, including increased vulnerability to security exploits and compliance issues. Over time, support for PHP versions and other dependencies will also wane, making it harder to maintain your site. Other vendors may join the program before end of life.

How can I find migration assistance?

The Drupal Association is certifying migration partners to help Drupal 7 site owners transition. Certified Migration Partners will be promoted on Drupal.org and can provide resources to assist in the migration process.

What should I do if I need help?

For assistance, consider engaging with the Drupal community or Certified Migration Partners. Donating to the Drupal Security Team or sponsoring core maintainers and contributors can also help ensure the continuity and security of Drupal projects.

Conclusion

Organizations must make informed decisions as Drupal 7's EOL approaches to maintain security, compliance, and functionality. Upgrading to Drupal 10, Drupal 11, or leveraging extended support options will position your site for long-term success.

Drupal Cafe Lutsk #25, held on June 27, 2024, featured sessions on Drupal's Domain module, digital opportunities for cities, and IT project optimization. Supported by Anyforsoft, YozmaTech, and DevBranch, the event highlighted valuable industry insights and community collaboration.

Drupal 11 is early! But don’t panic, the new Drupal 10 support model means you are not under pressure to upgrade. Drupal 10 will continue to be supported until mid-late 2026. But as we know, it’s best to be prepared and understand the upgrade process when that time comes for your organization.

Similar to the upgrade from Drupal 9 to Drupal 10, the latest version of Drupal 10 - Drupal 10.3.1 - defined all the deprecated code for Drupal 11. Also like previous modern Drupal major version upgrades there is a recommended set of areas to focus in order to get your applications upgraded as cleanly as possible.

Welcome, Drupal 11! At a previous DrupalCon Portland Drupal’s creator Dries Buytaert introduced the goal of making Drupal the preferred tool for ambitious site builders on the open web. Recently, Dries shared an updated plan for Drupal 11 which has 3 major focus areas:

Join us as Andrei Mateescu demonstrates the Workspaces module's powerful capabilities for enterprise-level Drupal sites. Discover how the module allows preview and management of extensive content changes and integrates with core functionalities like translations and Layout Builder. Although currently labeled experimental, Workspaces is already in use in production environments and will become a stable part of Drupal Core.

Read more michaelemeyers Wed, 07/24/2024 - 07:02

In web security, maintaining a secure Drupal site involves more than just core updates—it's about managing a complex web of dependencies. In this article, Grzegorz Pietrzak explores the critical steps every Drupal site maintainer should take to safeguard their sites against potential vulnerabilities. From keeping Composer and dependencies up-to-date to leveraging automated tools, discover practical strategies to fortify your Drupal site against modern threats. Stay ahead of security risks with these essential tips and insights.

The prime objective of any business is to work efficiently with high speed and agility in application development. This helps a company work effectively and allows them to explore an application's extensive features. Low-code works the same way, this platform is becoming more popular due to its greater speed and flexibility in application development. In this information piece, we are going to talk about the best low-code platforms that are making significant changes in the app development world.

Shanice Ortiz

Director of Projects

Alongside her project management duties, Shanice is passionate about expanding Four Kitchens’ DEI efforts and fostering a culture of advocates and allies.

January 1, 1970

Platform upgrade.

For any IT manager, especially those at large organizations, these two words are enough to cause stress. Even if you just completed a move to Drupal 10, the release of Drupal 11 is around the corner with the latest version available in late July 2024.

What does that mean for your organization? Primarily, your greatest takeaway is that you shouldn’t feel the anxiety of another looming deadline. You still have two years to complete the upgrade. Plus, engineering plans are just starting to come together about how to tackle the upgrade multiple different ways. Time is still on your side.

However, just because a move to Drupal 11 isn’t cause for immediate alarm doesn’t mean you shouldn’t start planning an upgrade. You and your organization will see considerable benefits by addressing this change sooner rather than later.

What the move to Drupal 11 means for your website

In terms of adding new tools or website features, moving to Drupal 11 doesn’t mean much for your organization. Drupal rolls out upgrades differently than conventional software platforms. Version 11 will seem a lot like Drupal 10.3 in terms of new functionality.

Instead, Drupal will be deprecating features to eliminate ‌unnecessary or outdated code from the core platform. For example, in moving from Drupal 9.5 to 10, the CKEditor 4 module was removed to make room for CKEditor 5. For Drupal 11, the Book module will be deprecated.

If your organization doesn’t use this feature, its subtraction amounts to a positive by eliminating unneeded weight to the platform. If you do, then Book will still function in a more nimble way as a contrib module.

Ultimately, your organization won’t see any new features from Drupal 11 until the release of the next version, Drupal 11.1. Does that mean you should wait until then to start planning a website upgrade? You guessed it — absolutely not.

Why get ahead of Drupal 11?

The biggest benefit of planning your upgrade to Drupal 11 early is to avoid the scramble of a last-minute migration. This creates headaches for your team, and you also run into crowded schedules if you rely on a development partner. You don’t just run the risk of incurring unnecessary charges for trying to plan an upgrade at the last minute. You also risk limited availability as development agencies support other clients who also waited until the last minute.

Plus, planning to migrate to Drupal 11 now enables you to sidestep the complications of upgrading after 11.1 is released. Version 11.1 will include new features, and migrating across two versions will be more difficult, especially if you manage multiple websites.

Making the Drupal 11 move now gives you a leaner version of the platform while leaving you better positioned for 11.1. In all, your journey to Drupal 11.1 will be significantly faster and easier if you’ve already completed the migration to Drupal 11.

What stakeholders need to know about Drupal 11

As you plan an upgrade to Drupal 11, you need to keep your stakeholders informed about what to expect. Rather than getting bogged down with deprecations or other elements, you should frame the upgrade as a maintenance release.

In other words, the migration is primarily a way to improve your organization’s position going forward. Along with creating an easier path toward accessing the new features coming for 11.1, this update also will improve the performance and scalability of the platform for your websites.

How to plan a Drupal 11 migration

Drupal 11 will be released in late July. Consequently, your organization has a long runway toward completing an upgrade. In fact, you have two years until version 10 reaches its end of life in mid- to late 2026.

While that sounds like an eternity from now, your organization has more options at its disposal for planning an upgrade the sooner you begin. With enough lead time, you could include much of the work of preparing for Drupal 11 as part of a Continuous Care program with Four Kitchens.

Depending on your subscription tier, you can allocate your hours differently to support the upgrade. Alternatively, you can plan to allocate additional hours to your tier to complete the upgrade. Or, you can upgrade to Drupal 11 as part of a standalone project separate from your Continuous Care engagement.

The point, ultimately, is to underscore that you have options. At Four Kitchens, we’re already working on our upgrade plan to guide our clients through a seamless transition to Drupal 11. By considering the right approach for your organization sooner rather than later, you can ensure you still have options for navigating this upgrade in a timely, efficient way.

If you’re ready to start planning, we should talk.

The post Why time is of the essence for a Drupal 11 migration appeared first on Four Kitchens.

As of July 1, Acquia Personalization is no longer available for new customers. The platform is being replaced by Acquia Convert, powered by VWO.

Get exclusive insights from the organizers about DrupalCamp Colorado 2024. Learn about keynote speakers, session highlights, venue details, networking opportunities, and the vital role of sponsors and volunteers.

Migrating content into Drupal is an extremely useful skill for most Drupal developers. Often, the most difficult step in learning to do migrations is the first one - that of getting everything set up and running your first migration to ensure that everything is working as expected.

Most Drupal migration-related blog posts and documentation that I've seen either completely ignore the setup process or gloss over it before diving into the details of writing migrations. I like to ensure, both here, and when working with participants in our Professional Module Development course, that we ensure a solid understanding of this process to build not only skills, but confidence.

This blog post will explain how to set up and run your first (very simple) Drupal migration. The process I will outline is actually the same steps I do when beginning to write a custom migration - just to make sure I have everything "hooked up" properly before I start getting into the more complex aspects of the project.

I generally write migrations on my local machine, using DDEV as the local development environment. 

Configuration migrations vs. Plugin migrations

When creating a custom migration, one of the initial decisions to be made is whether you'll write the migrations as plugins or configuration entities. I've always used configuration entities, but there are pros and cons to both approaches. Here, we will focus on configuration entity migrations.

There are some minor differences in the workflow presented below when using plugin migrations. For more information on the differences, I recommend Mauricio Dinarte's article. 

Core and contrib modules used

If you're planning on following along with this article, the following modules should be installed and enabled:

Drupal core: 

• Migrate
• Migrate Drupal

Contrib: 

• Migrate tools (for Drush commands) https://www.drupal.org/project/migrate_tools
• Migrate plus (migrations as configuration, additional process plugins, and more) https://www.drupal.org/project/migrate_plus

Source database

This blog post will demonstrate importing a small portion of user data from a Drupal 7 site into a Drupal 10 site. Normally, the first step is setting up the source data: in this case a Drupal 7 database. I normally create a new d7 database on the same MariaDB server as the Drupal 10 site (using DDEV, this is quite easy) and then import the Drupal 7 database into it.

Next, we have to tell the Drupal 10 site about the d7 source database. This can be done by adding the following database connection array to the bottom of your settings.local.php file (which I know you're using!):

$databases['migrate']['default'] = array(  'driver' => 'mysql',  'database' => 'd7',  'username' => 'db',  'password' => 'db',  'host' => 'db',  'port' => 3306,  'prefix' => '', );

Note the database key is migrate and the database name is d7. Everything else is identical to the regular Drupal 10 database credentials in DDEV. If you're using Lando or another local development environment, then your database connection array may be different. 

Custom migration module

Next, we need a custom module to house our migration. The easiest way to create one is via Drush's generate command:

$ drush generate module Welcome to module generator! –––––––––––––––––––––––––––––– Module name: ➤ My d7 migration Module machine name [my_d7_migration]: ➤ Module description: ➤ Migrations from Drupal 7 site. Package [Custom]: ➤           Dependencies (comma separated): ➤ migrate, migrate_drupal, migrate_plus Would you like to create module file? [No]: ➤ Would you like to create install file? [No]: ➤ Would you like to create README.md file? [No]: ➤ The following directories and files have been created or updated: ––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––– • /var/www/html/web/modules/custom/my_d7_migration/my_d7_migration.info.yml

Once created, go ahead and enable the module as well:

$ drush en my_d7_migrationMigration group configuration

As this blog post will be writing migrations as configuration entities, create a new config/install directory in your new module. 

We'll define a migration group to which all of our migrations will belong - this is what connects each migration to the source d7 database. Create a new migrate_plus.migration_group.my_group.yml file in the new config/install directory with the following contents:

id: my_d7_migration label: My Drupal 7 migration. description: Content from Drupal 7 site. source_type: Source Drupal 7 site shared_configuration:  source:    key: migrate  migration_tags:    - Drupal 7    - my_d7_migration

The most important bit of this configuration is the source key of migrate; this links up this migration group with the d7 database, with the migrate key we previously configured. Then, any migration created that is in this group automatically has access to the source d7 database.

Simple sample migration configuration

Next, let's look at a super simple example migration for user entities. This will not be a complete user migration, but rather just enough to migrate something. Many migration blog posts, documentation pages and other sources provide guidance and examples for writing migration configuration files (remember, this blog post is focused on all of the configuration and mechanics that normally aren't covered in other places.) 

Here's the user migration configuration we'll use. Create a new /config/install/migrate_plus.migration.user.yml file in your custom module with the following contents:

id: user label: Migrate D7 users. migration_group: my_d7_migration source:  plugin: d7_user process:  name: name  pass: pass  mail: mail  created: created  access: access  login: login  status: status  timezone: timezone destination:  plugin: entity:user

Reputable Drupal migration articles and documentation will explain that migrations need a source (extraction,) some processing (transform,) and a destination (where to load the data.) Often these three concepts will be called ETL. Each of these concepts are easy to spot in our sample configuration file:

• The data is coming from the d7_user plugin (provided by Drupal core with the data source being that of the my_d7_migration group which we configured in a previous step.) 
• The processing of the data in this simple migration is just field mapping (to: from.) Many migration configurations have transformations as part of this section, often provided by Drupal process plugins. 
• The destination is Drupal user entities. 

Running the migration

Again, these instructions are specific to Drupal migration configurations when created as configuration entities. Instructions for migration configuration written as plugins are slightly different (and not covered in this article.) 

As we are dealing with configuration entities, they must be imported into the active configuration store - which, by default, is the Drupal database. This is easily accomplished with the drush cim --partial command. This must be run each and every time a migration configuration file is modified. This is one of the (few, in my opinion) downsides of writing migrations as configurations. 

Next, I often check the status of migration via the drush migrate:status command. When using the Migrate Drupal module, it is recommended to always use the --group option otherwise the output of migrate:status can get a bit messy (due to all the default migrations that will be displayed.) 

The drush migrate:import and migrate:rollback commands should be self-explanatory. Each can be used with either the --group option or with a migration name (as shown below.) I almost always use the --update option on migrate:import for updating previously imported data. 

Finally, keep the drush migrate:reset command in your back pocket when writing custom migrations. If the migration crashes, you'll need to use this to reset its status from processing to idle in order to run it again. 

Here's a full set of the command specific to the sample user migration, migration group, and custom module created in this article:

$ drush cim --partial --source=modules/custom/my_d7_migration/config/install $ drush migrate:status --group=whatever $ drush migrate:import user --update $ drush migrate:reset user $ drush migrate:rollback userWhat's next?

What I've presented in this article is 90% of what I regularly use when running migrations. Sure, there are a few edge cases where oddities occur, but I believe this is a solid base of knowledge to start with. 

Once all this makes sense, I encourage you to utilize other blog posts and documentation to extend the user migration we started, or write new ones based on other resources. Once you're comfortable writing additional migrations, learning how to create your own process plugins is the natural next step. As process plugins are written as PHP classes, some knowledge of module development is necessary. 

Interested in learning more about Drupal module development? Check out DrupalEasy's 15-week Professional Module Development course! 

Additional resources

• UnderstandDrupal.com - loads of resources about Drupal migrations from Mauricio Dinarte. 
• Tag1's recent series about migrations (also written by Mauricio Dinarte!): 
• Migration related modules (definitely not an exhaustive list, but a solid start):
  • Migrate plus 
  • Migrate tools 
  • Migrate devel 
  • Migrate process extra - process plugins for migrations.
  • Migrate conditions - additional process plugins for migrations.
  • Migrate source CSV - allows migrations from .csv files.
  • Migration tools - even more process plugins and additional helper classes and methods for migration. 
  • Migrate upgrade - Drush support for the Drupal core migrations from Drupal 6 and 7.

Lead image generated by OpenAI.

Best SEO Practices for Drupal Websites in 2024 Editor Tue, 07/23/2024 - 10:10

If you are enthusiastic about Best SEO Practices for Drupal Websites in 2024 and want to grow your website traffic, you are just in the right place! Drupal is like a wise friend on the web who helps you complete tasks quickly without understanding many programming details. Also, it has some cool tricks that make your website both Google-friendly and user-friendly. And here we go, deeper into optimizing your SEO for Drupal!

Drupal SEO Checklist in 2024

All right, let's make a rough Drupal SEO checklist.