Focus on your mission, not your tech - Another Cup of Coffee (Posts about Drupal)

Drupal 7 End of Life: Why WordPress is the Best Migration Option for Lower Maintenance Sites

Aiden — Tue, 17 Dec 2024 14:25:15 GMT

Drupal 7 will reach end-of-life in January 2025. Learn why migrating to WordPress makes sense for small businesses, agencies, and anyone looking for an affordable, flexible CMS solution.

Drupal 7 is reaching the end-of-life (EOL) on 5th January 2025. This means official support will stop, leaving around 180,000 websites vulnerable to security risks, compatibility issues, and rising maintenance costs. If your site is still running on Drupal 7, it's time to make a decision.

For many, upgrading to the latest version—currently Drupal 11 which was released in July 2024—might seem like the logical next step. However, the move from Drupal 7 isn't a simple update but rather, it will require a complete rebuild. For smaller teams, freelancers, or businesses, this can mean significant time, money, and stress.

Drupal is well-suited for large, complex websites that require advanced functionality. This includes enterprise-level businesses, government portals, higher education institutions, and NGOs. That said, Drupal's steep learning curve and resource-intensive nature make it less suitable for small businesses or individuals who need a simple, low-maintenance website.

This is where WordPress comes in. With its lower costs, ease of use, and massive community support, WordPress has become the go-to CMS for businesses who need a better balance of simplicity and functionality. Whether you're running a small agency, freelancing, or managing your own business site, WordPress offers a practical, future-proof solution.

Final Deadline Announced After Multiple Extensions

The Drupal Association has announced several end-of-life dates for Drupal 7 over the years:

The latest and final EOL date for Drupal 7 is January 5, 2025, was made to give organizations more time to migrate their websites to newer versions of Drupal or other platforms.

What Happens If You Stay on Drupal 7?

It should go without saying that sticking with Drupal 7 after its End of Life isn't a viable long-term option because it will no longer receive official updates, security patches, or technical support.

This leaves site owners and maintainers with a range of headaches:

Security Risks: Without updates or security patches, your site becomes a prime target for hackers.
Compatibility Issues: Over time, browsers, APIs, and third-party tools will evolve, leaving your site unable to keep up. Things will start breaking—slowly at first, then all at once.
Rising Costs: Developers who still work with Drupal 7 are becoming harder to find, and their rates reflect that scarcity. Maintaining an outdated platform will only get more expensive.

If you're still on Drupal 7, the clock is ticking. It's time to start planning your next move.

Why Choose WordPress Over Upgrading Drupal?

WordPress has grown into the most widely used CMS in the world, powering around 43% of websites and 229,000 of the top 1 million sites by traffic. Popularity isn't the only reason to choose WordPress though.

For starters, it's easier to use because WordPress's intuitive interface means you don't need a developer for every little update. Your team can manage content, make changes, and even build pages without technical expertise.

It's also more affordable. While both Drupal and WordPress are open-source, WordPress generally offers a better return on investment with lower build and maintenance costs. Drupal's complexity leads to higher development expenses and more costly, time-intensive updates.

And then there's WordPress' massive global user base, which means there's no shortage of resources, tutorials, and developers. If you need help, it's easy to find.

Is it Worth Upgrading Drupal?

Upgrading to Drupal 11 is an option, but it's not a simple one. Architecturally, the jump from Drupal 7 to 11 is massive. The two versions are so different that you're essentially rebuilding your site from scratch.

For some organisations, that's fine. Nevertheless, if you're running a complex site with custom features that rely on Drupal's architecture, it might even be necessary. In fact, Drupal is often overkill for smaller businesses or agencies.

Futhermore, Drupal has gravitated towards enterprise-level projects over the past few years so if you don't need that complexity, WordPress is a more practical, cost-effective choice.

Real-World Success Stories

During a recent WP Engine webinar, Emily Averill, Digital Marketing Director at Daniels Health, shared their reasons for migrating from Drupal 7 to WordPress:

"The [Drupal] website wasn’t a place that our team could work confidently or with pace or agility. It was a friction point, and so we wanted a platform that could grow with us as an organization...Yes, it was going to be a hard migration. But in order to achieve the outcome, the future state we really wanted, it was going to be worth it...Replatforming for us in reality has been easier than migrating from Drupal 7 to 10."

This is a common theme among businesses that have made the switch. WordPress's user-friendly interface and flexibility make it a better fit for teams that need to move quickly and efficiently.

How We Handle Migrations at Another Cup of Coffee

Migrating a site can feel overwhelming, especially if you've been on the same platform for years. That's where we come in.

Our Process:

Project Discovery: We analyse your requirements and site's content, custom features, user roles, and integrations.
Migration Planning: We determine what needs to be migrated, what can be replaced with WordPress plugins, and what might need to be rebuilt.
Custom Solutions: If WordPress doesn't have an out-of-the-box solution for something, we'll build it.
Optimisation: Once the migration is complete, we optimise your new site for performance, security, and scalability.
Training: We provide training so your team knows how to manage the new site.

By the time we're finished, you'll have a site that's ready for the future.

Why WordPress is the Smarter Choice Today

Continuing to build on outdated Drupal software not only increases complexity but also creates significant technology debt, making future development more costly and inefficient.

As Scott Jones from Illustrate Digital explains in the WP Engine webinar, continuing on Drupal often means that new features and functionality are being developed on old underlying software and frameworks, which can hinder growth and innovation.

In contrast, WordPress offers a modern, intuitive interface that empowers marketing teams to take control of content publishing without relying heavily on developers. Webinar panelist PeterJohn from Useful Group highlights that WordPress is more marketer focused, while also evolving its developer tools to rival or surpass Drupal.

By migrating to WordPress, businesses can reduce costs, streamline workflows, and future-proof their digital presence.

Let's Talk

If you're still running Drupal 7, it's time to make a move. Whether you're ready to migrate or just exploring your options, we're here to help.

Drupal to WordPress migration service

Any Drupal version · All content · Custom content types · SEO · Plugins

Drupal 7 End of Life Frequently Asked Questions

These FAQs are drawn from the real-world experience of the WP Engine webinar panelists.

Why are organizations moving away from Drupal?

Several factors contribute to the shift away from Drupal, particularly Drupal 7, which reaches its end of life in January 2025. These include:

End of life for older versions: This necessitates full rebuilds, leading to significant effort and cost.
Technological debt: Building new features on outdated software creates challenges and limits agility.
Shifting decision-making: Marketing teams, who are most impacted by the CMS choice, now have a greater say, leading to a preference for more user-friendly platforms.
Rise of alternative platforms: Modern platforms like Next.js and WordPress offer attractive features and benefits.

What are the advantages of WordPress for marketing teams?

WordPress offers several benefits that make it particularly appealing to marketers:

Intuitive content management: WordPress's user-friendly interface and familiar structure make it easy to learn and use, even for junior team members.
Ease of content publishing: The block-based editor and intuitive design streamline content creation and editing.
Extensive plugin ecosystem: A vast library of plugins provides seamless integration with marketing tools and services, expanding functionality without custom development.
Flexibility and agility: WordPress allows for quick site deployment and iterative improvements, enabling rapid responses to market changes and opportunities.

How does WordPress benefit technical teams?

Beyond its marketing advantages, WordPress also offers benefits for developers:

Gentle learning curve: The platform is relatively easy to learn, reducing the training burden and enabling faster onboarding of new team members.
Strong community support: A large and active community provides ample resources, documentation, and support for troubleshooting and development.
Wide choice and flexibility: WordPress offers a vast selection of themes, plugins, and development tools, allowing for customized solutions and integrations.
Scalability and adaptability: WordPress can scale to accommodate large and complex websites, and its open-source nature allows for customization to meet specific needs.

What happens to my Drupal 7 website after January 2025?

No more updates: Drupal will cease releasing feature developments and security updates for Drupal 7.
Increased security risks: Without ongoing security patches, your website becomes vulnerable to exploits and attacks.
Limited functionality: You will no longer receive updates for modules and themes, potentially impacting website performance and functionality.

How do I address security concerns about WordPress?

Present data and evidence: Share data on WordPress's adoption rate, security infrastructure, and the expertise of partners like WP Engine and specialised agencies.
Engage IT and security teams: Involve them early in the decision-making process, address their concerns directly, and demonstrate how WordPress meets security standards.
Emphasise hosting and infrastructure: Highlight the role of managed WordPress hosting providers like WP Engine in ensuring security, performance, and reliability.

Is it easier to upgrade to the latest Drupal version or migrate to WordPress?

Upgrading to the latest Drupal version might seem simpler, but it can involve substantial effort due to significant code changes and underlying technology changes.
Migration complexity can be high regardless of whether you upgrade within Drupal or migrate to a different platform, especially with large amounts of content.
WordPress's iterative approach offers more frequent and gradual updates, minimising disruption and making it easier to maintain the site over time.

How is content migrated from Drupal to WordPress?

Content evaluation: Assess the existing content, identify what needs to be migrated, and determine if any cleansing or restructuring is required.
Data export: Export content from Drupal using tools like the Views Export module to create structured data files.
Data import: Utilise WordPress import plugins like WP All Import to bring the content into the new platform, with potential customisation for complex data structures.
Testing and validation: Thoroughly test the migrated content to ensure accuracy, functionality, and proper display on the new WordPress site.

What is a typical timeframe for a Drupal to WordPress migration project?

Content migration: Typically takes around 4 weeks, depending on the volume and complexity of the content.
Full website rebuild: Including design, development, and content migration, can range from 5 to 12 months, depending on the scope and complexity of the project.
Global multi-site projects: As in Emily's case, can take up to 48 weeks, encompassing research and development, design, build, testing, and launch phases.

Footnotes

Featured image photo by Rafael Garcin.

The Benefits of migrating from Drupal to WordPress: Key Insights from WP Engine's Latest Webinar

Aiden — Fri, 22 Nov 2024 15:28:15 GMT

Last August 2023, the Drupal Association announced the date of 5th January 2025 as Drupal 7's offical End of Life. This means that while individual developers can continue to maintain their sites and modules, Drupal 7 core will no longer receive official support, updates, or maintenance. Site owners, developers and agencies have been assessing their options: do they upgrade to Drupal 8 or find an alternative platform? Neither decision is easy.

WP Engine recently hosted a webinar offering insights from a panel of experts, revealing why enterprises are choosing WordPress over Drupal in 2024. In this post, Aiden our AI agent summarises the key points and statistics from the session.

Watch the Webinar

Speakers

Scott Jones, CEO, Illustrate Digital
Chandan Sharma, Web Development Manager, Bluetext
PeterJohn Hunt, CTO at Useful Group
Emily Averill, Digital Marketing Director at Daniels Health

The Current CMS Landscape

Drupal's Declining Position

According to Scott Jones's presentation, Drupal has experienced a notable decline in usage since 2021, particularly among enterprise brands. A critical factor driving immediate decisions is Drupal 7's impending end-of-life in January 2025, after which security patches and updates will cease.

Webinar slide deck: Drupal's overall decline

WordPress's Market Dominance

The webinar highlighted WordPress's commanding presence among the top 1 million sites by traffic. As PeterJohn noted during the session, "WordPress has done well to really stabilize the amount of changes, and how often those changes are going on... in a way that serves enterprise especially."

Webinar slide deck: Illustrate Digital's recommendation

Key Migration Drivers

Ease of Use and Training

Emily Averill's experience at Daniels Health provided a compelling real-world example. She shared that transitioning to WordPress proved more straightforward than upgrading within the Drupal ecosystem, emphasizing improved team productivity post-migration.

Cost Considerations

The panel discussed several financial advantages:

Lower implementation costs compared to Drupal upgrades
Reduced ongoing maintenance expenses
Better marketing team ROI through improved efficiency

Drupal vs WordPress: Total Cost of Ownership

Cost	Drupal	WordPress
License fee	$0 / year £0 / year	$0 £0
Example build cost	$165,000 - $250,000 £120,000 - £180,000	$100,000 - $200,000 £80,000 - £150,000
Example maintenance cost	$15,000 / year £11,000 / year	$11,500 / year £8,400 / year
Example hosting cost	$5,000 - $10,000 / month £3,500 - £7,000 / month	$5,000 - $7,000 / month £3,500 - £5,000 / month
Example ongoing development cost	$1,500 - $2,000+ / month £1,000 - £1,500+ / month	$1,500 - $2,000+ / month £1,000 - £1,500+ / month

Technical Flexibility

Chandan from Bluetext shared a success story of migrating a complex Drupal site to WordPress within tight deadlines, demonstrating the platform's efficiency and adaptability.

Practical Migration Considerations

Pre-Migration Planning

Based on the panelists' recommendations:

Conduct thorough site mapping and content architecture evaluation
Identify critical content for migration
Plan for both automated and manual content transfer

Stakeholder Engagement

The webinar emphasized involving:

Marketing teams for content strategy
IT and cybersecurity teams for security protocols
Development teams for technical implementation
Content editors for training and workflow adaptation

Security and Maintenance

Security Protocols

Key takeaways from the discussion:

Early involvement of cybersecurity teams is crucial
Address legacy security concerns during migration
Implement robust security measures from day one

Ongoing Maintenance

The panel highlighted WordPress's advantages:

More streamlined update processes
Focus on quality over quantity with plugins
Stronger community support for troubleshooting

Real-World Success Story

The webinar featured Daniels Health's migration journey, where Emily Averill noted: "The culmination of all of that is that it's far easier to do that in the WordPress platform... than it is on the Drupal platform, as was our experience back in the day."

Conclusion

Scott Jones's statement perfectly encapsulates the webinar's message: "WordPress is still the best CMS. It's still trending up, and until it gets really credible competition with something else that's got really high usage, he'll continue to recommend it for both small businesses and enterprises alike."

Ready to start your migration journey? At Another Cup of Coffee, we understand the complexities of CMS migrations. Tell us about your project in the quotation request form for a free assessment. For additional insights, check out our Drupal to WordPress Migration Guide.

Appendix: Key Statistics from the Webinar

1. The Current CMS Landscape

Drupal's Market Position

Approximately 180,000 websites still running on Drupal 7
Drupal 10 has only 75,000 installations currently
Drupal 11 (released in August) has approximately 1,300 installations
Showing significant decline since 2013, with accelerated decline since 2021

WordPress's Dominance

Powers 229,000 of the top 1 million sites by traffic
Controls approximately 41% of all content-managed websites
Powers 34 million websites across the entire internet

2. Critical Timeline Considerations

Version Support Deadlines

Drupal 7 end-of-life: January 2025
Drupal 10's end-of-life: Already set for 2026
Versions 8 and 9 still haven't been as popular as Version 7

Migration Timeframes

Average content migration timeline: 4 weeks
Full project timeline example (Daniels Health): 48 weeks including R&D process
Complete website rebuilds with new design: 5-12 months

3. Technical Migration Considerations

Platform Differences

Drupal 7 to Drupal 10 migration requires complete theme rebuild
Significant architectural changes between versions (PHP files to Twig templates)
Custom modules need complete rewriting for newer Drupal versions

WordPress Migration Benefits

More streamlined update processes
Stronger community support for troubleshooting
More intuitive content management interface

4. Security and Maintenance

End-of-Life Impact

Sites won't automatically go down after end-of-life
Security updates and patches will cease
Sites become increasingly vulnerable to security risks

Footnotes

Aiden is an AI agent and just like a human, it can make mistakes. This summary is posted for convenience but you can verify the statistics by watching the video in full.
Thumbnail photo from the WP Engine Drupal to WordPress Webinar, 12th November 2024.
WP Engine's slide deck for the webinar can be found at From Drupal to WordPress: The Benefits of Migrating Your CMS.

How To Set Up Drupal 7 Docker Containers for Migration Projects

Anthony Lopez-Vito — Mon, 09 Sep 2024 13:25:15 GMT

Docker is a valuable tool for Drupal 7 end of life migrations. In this post, I'll give a step-by-step guide to setting up a Drupal 7 container for your migration project. Instructions for the migration itself are out of scope for this article but you will have a running Drupal installation that can be used with a migration tool of your choice.

1. Introduction

After several deadline extensions, the Drupal Association has confirmed that Drupal 7 will officially reach end of life (EOL) on 5 January 2025. For site owners, agencies, and freelancers who've postponed making a decision, the time has come to make a choice. Do you upgrade to a newer version of Drupal, or migrate to an entirely different platform? Neither option is straightforward.

I sympathise with the "if it ain't broken, don't fix it" approach to most things, especially for something like a business-critical website. It's hard to justify disrupting a system that's running without any apparent problems. However, a Drupal 7 site migration is now unavoidable. Drupal Core will no longer be supported after EOL and hiring developers to keep it maintained, while a possibility, will not be feasible in the long term.

2. Upgrade Drupal 7 or Migrate?

It's important to understand that moving from Drupal 7 to a newer version of Drupal isn't a straightforward upgrade. Most Drupal developers already know this but it's worth pointing out early on. Unlike typical software updates, upgrading to Drupal 8 or higher involves a complete rebuild of the site.

In other words, whether you plan to upgrade or migrate to a different content management platform like WordPress, the work involved is fundamentally going to be a migration project. For this reason, throughout this article, I'll use the terms 'migration' and 'upgrade' interchangeably. Both scenarios involve similar planning, testing, and execution requirements, as well as the need for a temporary development environment.

3. Hassles with Setting up the Migration Environment

Unfortunately, site migrations are notoriously intricate, requiring careful planning and execution. Even getting set up for a migration can feel like an uphill battle. In 2012, when we first started specialising in Drupal to WordPress migrations, local web development involved making sure the whole application stack was configured properly for each project. This meant setting up a virtual host on the development machine web server, as well as getting the database and PHP configurations right. Virtualisation tools like VirtualBox existed, but they often performed poorly, freezing frequently and proving unreliable for sustained work.

The release of Docker in 2013 introduced a better way to manage development environments. As an open-source containerisation platform, it solved many of the problems developers faced when setting up for new migration projects. By isolating environments within lightweight containers, Docker streamlined workflows and eliminated many of the common compatibility headaches. By around 2018, it had become a standard tool for development teams worldwide, replacing clunky and expensive solutions like virtual machines.

In this guide, we'll outline how to set up a Docker container tailored for Drupal 7 migrations. We'll also explain how Docker simplifies the migration process while providing the flexibility required for more complex scenarios.

4. An Introduction to Docker

I'll start off with some basics for readers who aren't familiar with Docker. Feel free to skip to the setup steps if you don't need the introduction.

What is Docker?

Here's a quick overview if you're unfamiliar with the technology. Docker is a containerisation platform that lets you bundle applications and their dependencies into isolated units called containers. You can think of a container as a self-contained environment where everything your project needs, such as applications, libraries, and other dependencies, are bundled together. This approach ensures that the software runs consistently, regardless of the underlying system.

Unlike the old virtual machines, which emulate an entire operating system, Docker containers share the host system's kernel. This makes them lightweight, fast, and resource-efficient. Portability is central to Docker's appeal. A container built on a developer's laptop will work the same way on a production server. Combined with tools like Docker Compose, which orchestrates multi-container setups, you can recreate entire environments with just a few commands.

Why Use Docker for Migrations

Setting up a migration project used to require a huge amount of effort, especially for a Drupal 7 to WordPress conversion. It was a nightmare juggling multiple client projects on a single development machine. You would need to set up Apache virtual hosts for the new project sites and sometimes tweak system-wide PHP versions or database settings. If there was a risk of introducing a breaking change for another project, I would have to dig out and set up a spare physical machine.

Docker helps streamline the project setup tasks by offering isolated containers for each client, reducing the time spent building the environment and troubleshooting compatibility issues. For example, a Drupal 7 site may need PHP 5.6, while a new WordPress installation might require PHP 8. With Docker, you can run both versions in separate containers, avoiding annoying conflicts.

Docker volumes ensure data persistence for databases and installation files, even if a container is removed. Starting over from a botched migration simply means rebuilding the container from a pristine state—a process that usually takes minutes.

Key Advantages and Limitations of Docker

Docker is lightweight compared to traditional virtual machines. It shares the system kernel, allowing you to run multiple containers without overloading your system. This makes it particularly useful for testing different configurations or managing multiple projects.

However, it's important to note some limitations. Building Docker images for the first time can be time-consuming, and unused containers or images can quickly consume disk space if not managed regularly. Also, keeping a clean and efficient environment requires periodic maintenance. This can be annoying when you're knee-deep in a complex migration and you find your development machine running out of disk space.

Docker is not a complete solution for all problems, but thankfully, known issues like security concerns, networking challenges, and resource management apply to production sites rather than temporary migration environments.

Essential Docker Concepts

I'll go over some important basics before delving into the steps for setting up Docker Containers for Drupal 7 Migration Projects. You might get a little lost without an understanding of these concepts so be sure to at least skim through them if you're new to Docker. You can find information over on the dockerdocs.

Containers: Containers are lightweight, portable units that package your application and its dependencies. They run isolated from each other and the host system, ensuring consistency across development, staging, and production environments.
Images: A Docker image is a pre-configured snapshot that defines what is inside a container. Images include your application, libraries, runtime, and any dependencies.
Dockerfile: A Dockerfile is a text file with instructions for creating a Docker image. It defines the base image, environment variables, software installations, and configuration commands.
Volumes: Volumes are used to persist data generated by a container. They're essential for making sure changes to the Drupal database or files aren't lost when the container stops or is removed.
Networks: Docker's networking features allow containers to communicate with each other or with external services. For example, you could use the network to send data from Drupal container to a WordPress container, or a container that holds your migration utilities.
Docker Compose: Docker Compose is a tool that allows you to define and run multi-container Docker applications using a docker-compose.yml file. It simplifies the management of environments with multiple interconnected services (e.g., a Drupal site with a PHP container, a database container, and a reverse proxy).
Registry and Docker Hub: Docker Hub is a public registry where developers can find and share Docker images. Knowing how to pull official images from trusted sources and push your custom images to private or public registries is an important skill.
Commands and CLI Basics: Familiarity with Docker CLI commands like docker build, docker ps, and docker compose up -d --build will allow you to manage and troubleshoot containers effectively. See the command-line interfaces documentation for more about the commands.

5. How to Set Up Docker Containers for Drupal 7 Migrations

By now you should have a good understanding of what Docker is, how it can help with a migration project, and some basic concepts. Let's get on with actually setting it up. Here we'll create a container to install Drupal 7.103, released on 4 December 2024, with a full stack including web server, database and Drush.

1. Install Docker

First, ensure Docker is installed on your system. You can follow Docker's official installation guide for your operating system. I find the most convenient method is to install Docker Desktop which includes all the Docker tools and is available for Linux, Mac and Windows.

2. Create Your Project Structure

Create a folder structure for your migration project. At Another Cup of Coffee, we use a variation of following project structure.

project/
├── .env                    # Secrets and environment variables
├── backups                 # Local backups directory
├── docker-compose.yml
├── docker/
│   ├── drupal-[version]/
│   │   └── Dockerfile
│   └── phpmyadmin/
│       └── Dockerfile
├── logs                    # Log files
├── src/                    # Your local Drupal installation files
└── utils/                  # Your migration utilities

File and Database Persistence

File Changes: Drupal core/theme/module changes will persist on host through a mapping to the ./src directory.
Database Changes: the database will be stored in a named volume managed by Docker. The data will persist across container restarts/rebuilds unless the volume is manually deleted.

3. Download the Drupal Installation Files

We will use Drupal 7.103 for our container. (Note: This is the newest version, released on 4 December 2024, as of the last update for this article.) Download it from the Drupal website and extract the files into your ./src directory.

The container will create a bind mount to map the ./src directory on the host machine to /var/www/html inside the container. This means that any changes made to the files in the container at /var/www/html will be reflected in the ./src directory on the host machine, and vice versa.

4. Create Your `.env` File

The .env file is a text file used by Docker Compose to define environment variables. These variables can be referenced in the docker-compose.yml file to make your configurations more flexible and easier to manage. It's a good way of preventing sensitive information like passwords from being included in source control.

It will look something like this:

DRUPAL_DB_HOST=db
DRUPAL_DB_USER=dbuser
DRUPAL_DB_PASSWORD=dbpass
DRUPAL_DB_NAME=drupal_db

MYSQL_ROOT_PASSWORD=root

Ensure you adjust it to use your own variables.

4. Create Your Drupal Dockerfile

The Dockerfile sets out the instructions for creating a Docker image, defining the base image, environment variables, software installations, and configuration commands.

An image for Drupal 7.103 with Apache, Drush and PHP Composer might look like this:

FROM drupal:7.103-apache

# Install required PHP extensions and tools
RUN apt-get update && apt-get install -y \
    vim \
    git \
    unzip \
    libicu-dev \
    libzip-dev \
    libxml2-dev \
    libonig-dev \
    zlib1g-dev \
    default-mysql-client \
    && docker-php-ext-install pdo pdo_mysql zip intl \
    && rm -rf /var/lib/apt/lists/*

# Configure PHP
RUN echo "memory_limit = 256M" > /usr/local/etc/php/conf.d/memory-limit.ini \
    && echo "upload_max_filesize = 64M" > /usr/local/etc/php/conf.d/upload-limit.ini \
    && echo "post_max_size = 64M" >> /usr/local/etc/php/conf.d/upload-limit.ini

# Install PHP extensions needed by Drupal
RUN docker-php-ext-install pdo pdo_mysql zip intl

# Enable Apache mods commonly needed by Drupal
RUN a2enmod rewrite

# Install Composer (from the Composer official image)
COPY --from=composer:2 /usr/bin/composer /usr/local/bin/composer

# Install Drush globally via Composer
RUN composer global require drush/drush:8.*

# Ensure Drush is on PATH
ENV PATH="/root/.composer/vendor/bin:${PATH}"

# Set the container working directory
WORKDIR /var/www/html

# Ensure the Apache user (www-data) owns the web root
RUN chown -R www-data:www-data /var/www/html

This grabs the offical Docker Hub repository image for Drupal 7.103 with the Apache web server. You'll notice the Drupal image doesn't include any specifications for a database. This will be handled by the docker-compose.yml file later.

If you followed my project structure above, place this Dockerfile in a drupal-7.103 folder inside the docker subdirectory.

Adjust the Dockerfile for your own needs but here are some notes to avoid headaches:

default-mysql-client: If you're familiar with installing MySQL on a Linux system, you might be tempted to run apt-get for mysql-client. Don't do this. The Docker repository for drupal:7.103-apache is based on Debian Bookworm (Debian 12). Debian has stopped packaging mysql-client as of Debian 10 so you will encounter errors. Make sure you use the default-mysql-client metapackage instead. This will install the MySQL compatible mariadb-client.
composer:2: Although Drupal 7 does not have native Composer support, we are using it to install Drush.
drush:8: Install Drush 8, which is the latest compatible version Drupal 7 websites. A later version will install but you will encounter errors running some Drush commands.

5. Create a phpMyAdmin Dockerfile (optional)

This step is optional but it's useful to install phpMyAdmin so that you can do some basic database tasks. A phpMyAdmin Dockerfile that pulls the latest version of phpMyAdmin from the official Docker Hub repository would look like this:

FROM phpmyadmin:latest

# Add ServerName configuration
RUN echo "ServerName localhost" >> /etc/apache2/apache2.conf

Place this Dockerfile in a phpmyadmin folder inside the docker subdirectory.

6. Create Your `docker-compose.yml` File

Docker Compose will let you define and run all the necessary applications using a docker-compose.yml file. The example below defines services for Drupal, MySQL and phpMyAdmin, and should be saved in the root of your project folder. Please read the Compose file reference for a detailed explanation of each section in order to customise it for your needs.

services:
    drupal:
        build:
            context: .
            dockerfile: ./docker/drupal-7.103/Dockerfile
        ports:
            - "8088:80"
        volumes:
            # Ensure you copy your Drupal site here to avoid permission issues
            # If you are starting with a fresh Drupal installation, download
            # the correct Drupal version and extract it here.
            # https://www.drupal.org/project/drupal/releases/7.103
            - ./src:/var/www/html:cached
        depends_on:
            db:
                condition: service_healthy
        env_file:
            .env
        environment:
            DRUPAL_DB_HOST: ${DRUPAL_DB_HOST}
            DRUPAL_DB_USER: ${DRUPAL_DB_USER}
            DRUPAL_DB_PASSWORD: ${DRUPAL_DB_PASSWORD}
            DRUPAL_DB_NAME: ${DRUPAL_DB_NAME}
            PHP_FPM_USER: www-data
            PHP_FPM_GROUP: www-data

    db:
        image: mysql:5.7
        env_file:
            .env
        environment:
            MYSQL_DATABASE: ${DRUPAL_DB_NAME}
            MYSQL_USER: ${DRUPAL_DB_USER}
            MYSQL_PASSWORD: ${DRUPAL_DB_PASSWORD}
            MYSQL_ROOT_PASSWORD: ${MYSQL_ROOT_PASSWORD}
        volumes:
            - db_data:/var/lib/mysql
        ports:
            - "3307:3306"
        healthcheck:
            test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "drupal", "-pdrupal_pass"]
            interval: 10s
            timeout: 5s
            retries: 5

    phpmyadmin:
        build:
            context: .
            dockerfile: ./docker/phpmyadmin/Dockerfile
        ports:
            - "8081:80"
        env_file:
            .env
        environment:
            PMA_HOST: ${DRUPAL_DB_HOST}
            PMA_USER: ${DRUPAL_DB_USER}
            PMA_PASSWORD: ${DRUPAL_DB_PASSWORD}
            PMA_ABSOLUTE_URI: http://localhost:8081/
        depends_on:
            - db

volumes:
    db_data:

The MySQL Image

You will see that I used MySQL 5.7 in this configuration to simulate an outdated environment. MySQL 5.7 reached its end of life in October 2023 but as of late-2024, we have clients who, for one reason or another, are still running MySQL 5.7. They are not alone. A September 2024 article from Percona, a database software and support company, has a FAQ section titled, "Should I upgrade from MySQL 5.7 to 8.0?" Clearly, a large percentage of sites are still running legacy databases on their web stack.

If you are using MySQL versions 8.x, visit Docker Hub's MySQL repository to see the relevant image tags. You will need to update this section:

    db:
        image: mysql:5.7

Also, most development machines will already have a MySQL server running on the local port 3306. To avoid conflicts, this docker-compose.yml maps the container's MySQL port to the local port 3307. Adjust this to suit your own setup.

        ports:
            - "3307:3306"

7. Build and Start the Environment

Now you're ready to build and start your environment. Open up a terminal and run the following command:

docker compose up -d --build

This will use Docker Compose to build the containers and run them in detached mode. It may take a few minutes to complete if you're running this command for the first time. Docker will need to download all the images from the Docker repository before building.

8. Access Your Local Drupal Setup

If all goes well you should have your environment ready to install Drupal 7. Visit http://localhost:8080 in your browser to access the Drupal 7 instance running in the Docker container.

Follow the installation wizard and Use these database settings in your .env file.

6. Testing and Workflow

You can use these commands to test your installation. Check the documentation in the Additional Resources section below for more commands.

Basic Testing

Container Status:

# Check if all containers are running
docker compose ps

Expected output: db, drupal and phpMyAdmin services should show "Up" status

Drupal Installation:

Access the Drupal site at http://localhost:8088
You should see the Drupal installation page or site
Check error logs if needed:

docker compose logs drupal

Drush Functionality:

# Test Drush status
docker compose exec drupal drush status

# Test Drush version
docker compose exec drupal drush --version

# Test site-specific Drush commands
docker compose exec drupal drush core-status

Composer Functionality:

# Test Composer version
docker compose exec drupal composer --version

# Test Composer diagnostics
docker compose exec drupal composer diagnose

Database Connection:

# Test database connection via Drush
docker compose exec drupal drush sql-connect

# Test phpMyAdmin access
# Visit http://localhost:8081

Testing Your Migration Utilities With Sample Content

You can use Drush to generate sample content. This can be useful for testing your migration utilities.

1. Log Into the Container's Terminal

docker compose exec drupal bash

2. Install Helper Modules

Install the devel, devel_generate, and taxonomy_manager modules:

drush en devel -y
drush en devel_generate -y
drush en taxonomy_manager -y

Devel Module: The Devel module is a comprehensive toolkit for Drupal developers that offers several submodules and features to aid in development and debugging.
Devel Generate Module: The Devel Generate module is a submodule of the Devel module, specifically designed for generating dummy content.
Taxonomy Manager Module: Use the Taxonomy Manager module to mass insert taxonomy terms.

3. Generate Sample Content

Now generate some sample content:

# Generate nodes with randon content
drush generate-content 500

# Generate users
drush generate-users 25

# Generate taxonomy terms
drush generate-terms tags 20

# Generate nodes for a specific content type
drush generate-content 20 --types=article

# Generate comments on random nodes:
drush generate-comments 250

Development Workflow

Here are some basic commands to support your development and migration workflow.

Starting/Stopping Environment:

# Start containers
docker compose up -d

# Stop containers
docker compose down

# View logs
docker compose logs -f

Using Drush:

# Access Drush
docker compose exec drupal drush

# Clear cache
docker compose exec drupal drush cc all

# Update database
docker compose exec drupal drush updb

Working with Composer:

# Install dependencies
docker compose exec drupal composer install

# Add new package
docker compose exec drupal composer require [package-name]

Service Access:

Drupal: http://localhost:8088
- Username and password as set during the installation process.
phpMyAdmin: http://localhost:8081
- Username: (from .env)
- Password: (from .env)
MySQL: localhost:3307
- Username: (from .env)
- Password: (from .env)

Database Operations:

# Export database
docker compose exec db mysqldump -u [user] -p[root-password] drupal > backup.sql

# Import database
docker compose exec -T db mysql -u [user] -p[root-password] drupal < backup.sql

7. Preparing for Your Drupal 7 Migration

If you made it this far, you will have a fully working and tested Docker container with Drupal 7, access to the database, and some basic tools to support migration or upgrade tasks. This environment isolates your development work, ensuring that your live site remains unaffected throughout the process.

Importing Your Live Drupal Installation into the Container

To get started with your migration project, you'll need to transfer your existing live Drupal installation into the container. The Drupal 7 documentation for migrating a site between environments will give you an outline of the steps.

As a summary, you begin by exporting the database and files from your live site. Once you have these, you can load the database into the container's MySQL instance and place the site's files in the ./src directory on your host filesystem. (Remember, we created a bind mount to map the ./src directory to the container's web directory at /var/www/html.) This gives you a working copy of your live site, but in a safe, sandboxed environment.

Important note: In this article we used Drupal 7.103 for our container. To avoid problems with version conflicts, you should update your live Drupal site to the same version before exporting.

Creating a Pristine Snapshot

Before diving into migration tasks, it's a good idea to create a snapshot of the container in its pristine state. This serves as a clean starting point you can revert to if anything goes wrong during the migration process. A snapshot ensures you won't need to repeat the setup steps from scratch if you need to restart or experiment with different migration approaches.

You create a snapshot by committing the current state of your container to a new Docker image. I'll cover this in a separate article but at this stage you will now be ready to use whatever tools you need to upgrade or migrate your Drupal 7 installation.

Migration Options

Instructions for the migration itself will need to be covered elsewhere as it's a very detailed process. However, you can check these resources for your migration options:

Upgrading to a newer version of Drupal: You can use your container to trial-run the upgrade steps in the Drupal documentation, "Upgrading from Drupal 6 or Drupal 7."
Migrating to another platform: If you plan to migrate to another platform such as WordPress, please see our Drupal to WordPress Migration Guide.

8. Conclusion

Docker provides a very practical and reliable way to set up migration environments. While it requires an initial investment in learning, the long-term benefits include consistent workflows, reliable environments, and over-all, fewer frustrations when getting started with a migration project. Docker won't solve every migration challenge, but in my experience, it definitely simplifies many of the technical hurdles involved.

If you're facing challenges with Drupal 7 migrations or need expert assistance, reach out to us at Another Cup of Coffee. We can help make your next project smooth, efficient, and future-proof.

Additional Resources

How to set up a MySQL database server on Ubuntu for Drupal to WordPress migrations

Anthony Lopez-Vito — Fri, 11 Jun 2021 15:44:52 GMT

Content Management System (CMS) migration projects involve moving data between databases with different schemas. Table names, field types and constraints often don’t match up, leading to a number of frustrating errors. This is especially the case with highly complex Drupal to WordPress migrations that use custom scripts to extract, transform and load the data. These projects can seem like you’re constantly hitting roadblocks throughout. I’ve found from experience that running the migration in an appropriate development environment can reduce a great deal of effort. In this guide, I will describe how to set up a MySQL database server on Ubuntu for Drupal to WordPress migrations.

Why MySQL and Ubuntu?

The first thing to address is why MySQL and Ubuntu? How about MariaDB? How about Arch Linux, Mac OS or Windows? Yes! Any platform that runs Drupal and WordPress will work for your migration environment so you can use whatever you prefer. Personally, I have a fondness for OpenBSD but it’s not a practical platform for a CMS migration. OpenBSD’s niche user-base means you’ll spend much longer installing necessary tools and troubleshooting errors.

There are all sorts of tutorials covering MySQL on Ubuntu. This means you’re more likely to quickly find a solution from a web search when you hit a problem. Furthermore, if you need a software utility or program to help you get the job done, it will probably be available through apt, dpkg, snap or tasksel. Use whatever you like but for now, MySQL on Ubuntu is my recommended platform for Drupal to WordPress migrations. I expect this will be the case for some time to come. These projects are complex and time-consuming enough without making the job more difficult.

Installing MySQL on Ubuntu for CMS migrations

There are many detailed tutorials for installing MySQL on Ubuntu. DigitalOcean’s How To Install MySQL on Ubuntu 20.04 is a good one and writing another won’t add much value. My guide will therefore only give a brief overview of the MySQL server installation steps. Instead, I will focus on the configuration areas specifically related avoiding problems on a CMS migration project.

You may wonder why the migration environment should be much different from a live server. Migration projects require you to do things that aren’t supported by the CMS platform. You’re therefore likely to encounter weird errors that aren’t normally found when running standard Drupal or WordPress.

Set up your Ubuntu LAMP migration platform

The main source of unusual errors is almost certainly because you’re migrating on a setup suited to a live website. Live server configurations are more restrictive than you need for a migration project. You can therefore save yourself a huge headache by rolling your own local migration environment. It might take a little longer to get started but you’ll save time by avoiding lots of unnecessary troubleshooting.

I must highlight that this will be a local migration environment and should not be accessible from the public internet. The normal security considerations with running a live content management system don’t apply when you’re working locally. By all means follow basic security measures mentioned the various tutorials for setting up Ubuntu and MySQL. Nevertheless, a highly secure setup is counterproductive for these projects and you can avoid trouble by being a little more permissive.

Go ahead and install Ubuntu Desktop. Since this will be a development environment, you’ll want the Desktop environment rather than the more lightweight server version. Of course, you’ll still need to install a web and database server. Follow these instructions for installing LAMP stack but skip the step of installing MariaDB. As mentioned above, we’ll be using MySQL.

WARNING: Installing MariaDB over MySQL or vice versa on Ubuntu 20.04 may lead to all sorts of problems starting up the database server with errors like the following:

Failed to start mysqld.service: Unit mysqld.service not found.

The last time I did this, none of solutions mentioned online for purging the installation worked. I spent most of a day trying to fix the problem. In the end, I realised it was quicker to start again and rebuild the machine from scratch. This is a big reason why I decided to stick with MySQL as standard for my projects.

Install MySQL

You can read a more detailed tutorial on installing MySQL on Ubuntu but here’s an overview.

Update the package index on your server: sudo apt update
Install MySQL server: sudo apt install mysql-server
Secure MySQL: sudo /usr/bin/mysql_secure_installation

The mysql_secure_installation script doesn’t cause problems for migrations so it’s worth running.

Create an admin user:

CREATE USER ‘user’@'localhost’ IDENTIFIED BY ‘userpassword’;
GRANT ALL PRIVILEGES ON *.* to ‘user’@'localhost’ WITH GRANT OPTION;
FLUSH PRIVILEGES;
quit;

Now create a user and database for your migration project:

CREATE USER ‘projectuser’@'localhost’ IDENTIFIED BY ‘password’;

CREATE DATABASE project_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_520_ci;
GRANT ALL ON project_db.* TO ‘projectuser’@'localhost’;

You can give this user more restrictive permissions but GRANT ALL avoids errors when running scripts and SQL queries on the database. Only the migration team should have access and you won’t need it after the migration so why not make your life easier?

Setting the MySQL server SQL mode

It’s possible that you won’t be familiar with SQL modes unless you’ve done some database administration work. For our purposes, SQL modes do two things:

change the types of queries you can run on your MySQL server;
change the validation checks when altering the data.

I’ve found that specific SQL modes need to be set for Drupal to WordPress projects. You may find that all sorts of strange errors appear if the correct modes aren’t set. The following sections show you two ways to set your MySQL server’s SQL mode.

Option 1: Setting the global sql_mode in the database

Login in to database as an admin user.
View the current sql-modes using SELECT @@GLOBAL.sql_mode; and make a copy if necessary.
Copy the current modes (add or delete modes as needed) and paste in next step.
Add ALLOW_INVALID_DATES and removes both NO_ZERO_DATE, NO_ZERO_IN_DATE by setting the sql-modes with
SET GLOBAL sql_mode = ‘STRICT_TRANS_TABLES,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION’; (WARNING: check the modes correspond with your setup.)
Restart server:
sudo systemctl start mysql

Option 2: setting the sql_mode in the MySQL configuration file

Locating the MySQL configuration file

The my.cnf configuration file isn’t always found in the same place. It’s specific to the Linux distribution and server configuration but can normally found in one of the following locations:

/etc/my.cnf
/etc/mysql/my.cnf
echo/my.cnf
[datadir]/my.cnf
~/.my.cnf

If you can’t find your MySQL configuration file, you can try running locate my.cnf or mysqladmin –help. The latter will show something like the following in the output:

Default options are read from the following files in the given order:
/etc/my.cnf /etc/mysql/my.cnf ~/.my.cnf

Also keep in mind that it’s possible to use !include directives to include other option files and !includedir to search specific directories for option files. Under Ubuntu, there may be a file /etc/mysql/my.cnf with !includedir directives to search /etc/mysql/conf.d/ and /etc/mysql/mysql.conf.d/

Editing the MySQL configuration file

If the MySQL server finds more than one configuration file, it will load each one in turn. The values override each other and it can be difficult to know which takes priority. Furthermore, the –defaults-file parameter can also override all configurations. Keep things simple and have only one file and place it the directory that makes sense to you.

Before editing the my.cnf, first log in to MySQL with an administrator user and run the SELECT @@GLOBAL.sql_mode query to see the values used in your setup.

Running the SELECT @@GLOBAL.sql_mode query on MySQL Workbench

Next, open the configuration file, look for the section [mysqld] and edit the line starting with:
sql_mode = …

Add the line if it’s not there. Adjust the exact modes to match your project’s needs so take a look at the list of SQL modes to see which may apply. I’ve found the following works well:
sql_mode = “STRICT_TRANS_TABLES,ALLOW_INVALID_DATES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION”

Finally, restart the MySQL server. On Ubuntu this will probably be with

sudo systemctl start mysql

If you are logged in to the MySQL server, you may also need to disconnect your client and reconnect for the changes to take effect for your session.

Potential errors

Here are some potential errors that you may come across during a CMS migration project. I usually find them when running a Drupal to WordPress migration on a freshly built development environment.

mysqldump access denied when trying to dump tablespaces

Migrations involve dumping and importing databases and this process is straightforward on a mature development environment. However you may receive an ‘Access denied’ error out of the blue when dumping your MySQL database:

mysqldump: Error: ‘Access denied; you need (at least one of) the PROCESS privilege(s) for this operation’ when trying to dump tablespaces

If you see this, perhaps you were working on an environment that was a little too ‘mature’ (in other words, obsolete!) and you have recently upgraded your installation. The updates for MySQL 5.7.31 and MySQL 8.0.21 in July 2020 introduced an incompatible change that produces this error.

Read my separate article, How to fix the mysqldump access denied process privilege error, for more information and instructions on how you can try solving this.

ERROR 1067 (42000) Invalid default value

Drupal nodes store the date as a Unix timestamp in an int (e.g. 1623427200) field whereas WordPress stores dates as datetime (e.g. 2021-06-11 16:00:00). There may be a conversion error in your migration script or the source date could simply be zero for some reason. Normally your MySQL server mode will be set to NO_ZERO_DATE, NO_ZERO_IN_DATE so trying to insert a zero date will give you the error:

ERROR 1067 (42000) Invalid default value

You can fix this by replacing NO_ZERO_DATE, NO_ZERO_IN_DATE with set to ALLOW_INVALID_DATES in your global SQL mode.

Expression #1 of SELECT list is not in GROUP BY clause

You run an SQL query and get the rather cryptic error:

Expression #1 of SELECT list is not in GROUP BY clause and contains
nonaggregated column ‘database.table.pid’ which is not functionally dependent
on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by

What’s wrong? MySQL has a only_full_group_by mode which, when enabled, strictly applies ANSI SQL rules when using GROUP BY. Fix this by reworking your script or removing the ONLY_FULL_GROUP_BY SQL mode.

Error Code: 2013. Lost connection to MySQL server

This often happens when it an SQL query takes too long to return data. The connection between your MySQL client and database server times out so the connection gets dropped. For ideas on how to try solving this, read my separate article, How to fix Error Code 2013 Lost connection to MySQL server.

Conclusion

Setting up a MySQL database server for Drupal or WordPress is a familiar task for web developers and site administrators. However, CMS migrations have quirks that can cause obscure and baffling errors. In this guide I’ve shown you some little tricks that may save time and annoyance. While there’s no way to provide an exhaustive list of solutions to all the MySQL problems you’ll encounter, I hope to have pointed you in the right direction.

If you have a site migration project and would like to hire me, please ask for a quote for my consulting service.

CMS migration consulting

All content · Custom content types · SEO · Plugins

Migrating content from a site and need a specialist? Please contact me for a quotation. Whether you’re a media agency who needs a database expert or a site owner looking for advice, I’ll save you time and ensure accurate content exports.

Cover photo by Rubaitul Azad on Unsplash

Ubercart to WooCommerce migration notes

Anthony Lopez-Vito — Fri, 24 Jan 2020 12:14:07 GMT

I've now had several Ubercart to WooCommerce migration projects so it's time to start documenting the process. As with all my documentation, I'll start off this post as rough notes and improve it over time. If this topic interests you, be sure to check back every so often to see the updates. Please keep in mind that I'm writing this from the standpoint of Drupal to WordPress migrations. In other words, the main objective for the projects were to migrate a Drupal site to WordPress but there was also an Ubercart to WooCommerce component.

Key differences between Ubercart and WooCommerce

There's one key difference between Ubercart and WooCommerce from an architectural point-of-view. Ubercart stores products as nodes and orders are stored in a separate table uc_orders. Orders have an order_id and there's no direct relationship in uc_orders to a product's node ID. Instead, the uc_order_products table stores the relationship between orders and products purchased with the order.

WooCommerce stores both products and order transactions as posts in the wp_posts table. The post ID is used as the order's transaction ID. Products purchased with the order are stored in wp_woocommerce_order_items, with additional product metadata being strored in wp_woocommerce_order_itemmeta.

Obviously there are many more differences but this information architecture is the key thing to keep in mind when migrating the data.

Database tables

Here are the main database tables that you'll need to migrate Ubercart content to WooCommerce.

Ubercart

Table: Drupal Ubercart tables
Table	Description
node	Products are stored in the Drupal `node` table.
uc_orders	Stores the individual Ubercart transactions.
uc_order_products	Stores the products purchased during the transaction.
uc_order_line_items	Line items for an order. This includes tax and shipping fees applied to an order.
uc_order_comments	Customer or administrator notes associated with each order.
uc_order_log	Comments about the order status by the shop administrator.
uc_zone	Country zone codes for customer billing and delivery.
uc_countries	Countries and zone codes in ISO 3166-1 Alpha-2 and Alpha-3 code format for customer billing and delivery.

WooCommerce

Table: WordPress WooCommerce tables
Table	Description
wp_posts	Stores products and transactions.
wp_postmeta	Transaction meta data.
wp_woocommerce_order_items	Stores the line items for a transaction in the `wp_posts` table.
wp_woocommerce_order_itemmeta	Stores the meta data for line items, such as quantity, price and tax information.
wp_comments	Order notes.

Order transactions and products are saved as WordPress posts. One or many order item meta entries can be linked to an order.

WooCommerce shop orders

A WooCommerce transaction is saved as a shop order in the wp_posts table.

post_status = wc_completed
post_type = shop_order

WooCommerce subscriptions

WooCommerce subscriptions are saved in wp_posts. A subscription is made up of two entries:

The transaction order for a subscription.
The subscription itself.

Subscription transaction order

post_status = wc_completed
post_parent = 0
post_type = shop_order

The subscription

post_status = wc_active
post_parent = [post ID to the transaction shop order]
post_type = shop_subscription

Products

Purchased products are saved as line items in the wp_woocommerce_order_items and wp_woocommerce_order_itemmeta tables.

A WooCommerce product can be of any post type. The product post is linked to a shop order transaction by setting the product's post ID in the wp_woocommerce_order_itemmeta table:

meta_key = _product_id
meta_value = [post ID to the product]

Notes

My apologies if you've come here looking for more complete documentation. I've been planning to write this post for more than two years but have been putting it off due to my work schedule. I figure the best way to finally get it done is to just make a start and update it as time allows.

The most-viewed articles here started off as notes for my own use and evolved over time. This one is no different. Hopefully it will still be of use to some people in its draft state.

In the meantime, you might want to take a look at these other articles and plugins.

How to fix Error Code 2013 Lost connection to MySQL server

Anthony Lopez-Vito — Sat, 15 Jul 2017 19:08:23 GMT

If you spend time running lots of MySQL queries, you might come across the Error Code: 2013. Lost connection to MySQL server during query. This article offers some suggestions on how to avoid or fix the problem.

Why this happens

This error appears when the connection between your MySQL client and database server times out. Essentially, it took too long for the query to return data so the connection gets dropped.

Most of my work involves content migrations. These projects usually involve running complex MySQL queries that take a long time to complete. I’ve found the WordPress wp_postmeta table especially troublesome because a site with tens of thousands of posts can easily have several hundred thousand postmeta entries. Joins of large datasets from these types of tables can be especially intensive.

Avoid the problem by refining your queries

In many cases, you can avoid the problem entirely by refining your SQL queries. For example, instead of joining all the contents of two very large tables, try filtering out the records you don’t need. Where possible, try reducing the number of joins in a single query. This should have the added benefit of making your query easier to read. For my purposes, I’ve found that denormalizing content into working tables can improve the read performance. This avoids time-outs.

Re-writing the queries isn’t always option so you can try the following server-side and client-side workarounds.

Server-side solution

If you’re an administrator for your MySQL server, try changing some values. The MySQL documentation suggests increasing the net_read_timeout or connect_timeout values on the server.

Client-side solution

You can increase your MySQL client’s timeout values if you don’t have administrator access to the MySQL server.

MySQL Workbench

You can edit the SQL Editor preferences in MySQL Workbench:

In the application menu, select Edit > Preferences > SQL Editor.
Look for the MySQL Session section and increase the DBMS connection read time out value.
Save the settings, quite MySQL Workbench and reopen the connection.

Navicat

How to edit Navicat preferences:

Control-click on a connection item and select Connection Properties > Edit Connection.
Select the Advanced tab and increase the Socket Timeout value.

Command line

On the command line, use the connect_timeout variable.

Python script

If you’re running a query from a Python script, use the connection argument:
con.query(‘SET GLOBAL connect_timeout=6000′)

Post-migration troubleshooting: Gateway timeout when enabling plugins

Anthony Lopez-Vito — Mon, 05 Jun 2017 09:35:07 GMT

Here's one that caught me out on a recent Drupal to WordPress migration. As is common with my projects, there were three parties involved: the client, an external development team and myself. The WordPress site was first built on the development team's server, after which it was migrated to my local environment. When everything was ready for beta testing, we moved the site over to the client's staging server on a newly activated account over at Kinsta. Eventually, we'd move it over to a live server, also hosted on Kinsta.

After some initial tests on staging, I found that deactivating and reactivating plugins would cause the site to hang and show a '504 Gateway Time-out' error. This happened when re-enabling some but not all plugins.

I initially suspected some misconfiguration at the hosting end because there were some hitches with the newly create account. At the outset, the account's server had an issue which Kinsta support needed to fix. For convenience, we'd also made use of Kinsta's free site migration service. This is where they'll migrate an existing WordPress site into their environment. Though it would have been easy enough for me to do, we thought to give it a try. In hindsight, this was a bit of a mistake. The site migration service itself was fine but it did end up causing some confusion. First, a miscommunication in the migration request caused them to create a temporary domain we didn't want. They helpfully solved this by giving us a second temporary domain. However, they'd also upgraded everything to PHP 7 in the process. All of these issues were possible suspects for the time-out error but turned out to be red-herrings.

It took some time to pinpoint the cause behind the Gateway Time-out error. I do have to say that Kinsta support were very responsive throughout the troubleshooting process. They eventually put a senior engineer on the case who found the problem. It turned out the problem wasn't to do with Kinsta at all. There was a leftover setting from the original development team's server. It was a valid format so didn't cause an issue on either my local server or my staging server. However, it apparently can cause issues with plugins and did on the Kinsta environment.

What was the setting? The WordPress upload path directory was set to the development team's server path e.g. /home/dev/public_html/sitename. Throughout the migration, I'd been doing a database search-and-replace looking for their development domain. Somehow, as the site moved from different servers, that server path string remained in the database, only to cause a problem when the site landed in the destination server on Kinsta.

I'm not sure if there would have been any way to have caught this problem earlier. It's one of those obscure errors that are easy to overlook and take time to resolve. There's also no practical way to do a database search-and-replace for every imaginable string. I'll have to rack this one up to experience.

How to change the WordPress table prefix prior to a migration

Anthony Lopez-Vito — Thu, 16 Mar 2017 13:12:02 GMT

When working on a Drupal to WordPress migration project, I like to migrate into a set of intermediary WordPress tables that live in the Drupal database. These are working tables where I can run various scripts to process and clean up the content before exporting to a working WordPress installation. It’s not necessary to do this but I find it convenient to run scripts on the same database rather than deal with two separate database connections.

Note that some people suggest renaming the table prefixes to improve security. My use of the table prefixes is simply to create temporary containers for the migration. While non-standard prefixes might help prevent ‘script kiddie’ attacks, I find it isn’t worth the disadvantages that come with this sort of security through obscurity (or more precisely, security through minority) approach. Here are two articles give a deeper explanation of topic:

wordfence.com: WordPress Table Prefix: Changing It Does Nothing to Improve Security
wpkrauts.com: The database table prefix is not a security feature

SQL queries to change the WordPress table prefixes

You can start with a freshly installed WordPress database. Dumping this and importing to your Drupal migration database will give you all the tables with the correct WordPress schema. I use the acc_ prefix but you can use whatever you want.

Rename the tables with these queries:

RENAME table `wp_commentmeta` TO `acc_commentmeta`;
RENAME table `wp_comments` TO `acc_comments`;
RENAME table `wp_links` TO `acc_links`;
RENAME table `wp_options` TO `acc_options`;
RENAME table `wp_postmeta` TO `acc_postmeta`;
RENAME table `wp_posts` TO `acc_posts`;
RENAME table `wp_terms` TO `acc_terms`;
RENAME table `wp_termmeta` TO `acc_termmeta`;
RENAME table `wp_term_relationships` TO `acc_term_relationships`;
RENAME table `wp_term_taxonomy` TO `acc_term_taxonomy`;
RENAME table `wp_usermeta` TO `acc_usermeta`;
RENAME table `wp_users` TO `acc_users`;

Testing the migration results

If you need to point a WordPress installation to these tables for testing, you’ll need to do two things:

Update the $table_prefix setting in the wp-options.php file
Update the options and usermeta tables

Updating the $table_prefix setting in the wp-options.php file is straightforward. Open the file and edit the line:

$table_prefix  = ‘acc_’;

In WordPress, prefixes are saved as entries in the options and usermeta table. Check for entries containing the prefix:

SELECT * FROM `acc_options` WHERE `option_name` LIKE ‘%wp_%’;
SELECT * FROM `acc_usermeta` WHERE `meta_key` LIKE ‘%wp_%’;

When you have all the entries, update them with the new prefix. The query will probably look something like this:

UPDATE `acc_options` SET `option_name` = ‘acc_user_roles’ WHERE `option_name` = ‘wp_user_roles’;
UPDATE `acc_usermeta` SET `meta_key` = ‘acc_capabilities’ WHERE `meta_key` = ‘wp_capabilities’;
UPDATE `acc_usermeta` SET `meta_key` = ‘acc_user_level’ WHERE `meta_key` = ‘wp_user_level’;
UPDATE `acc_usermeta` SET `meta_key` = ‘acc_user-settings-time’ WHERE `meta_key` = ‘wp_user-settings-time’;
UPDATE `acc_usermeta` SET `meta_key` = ‘acc_user-settings’ WHERE `meta_key` = ‘wp_user-settings’;
UPDATE `acc_usermeta` SET `meta_key` = ‘acc_dashboard_quick_press_last_post_id’ WHERE `meta_key` = ‘wp_dashboard_quick_press_last_post_id’;

A word of warning: it’s easy to forget to change the prefixes back to match the final WordPress installation. If you do, the WordPress user accounts will have problems, such as the Dashboard controls not being visible after logging in. Because of this, I tend to have a separate testing installation that gets an import of the working tables.

Cover photo by Gavin Allanwood on Unsplash

How to prepare for your Drupal to WordPress migration project

Anthony Lopez-Vito — Mon, 02 May 2016 09:05:11 GMT

Any successful project requires careful planning and a Drupal to WordPress migration is no exception. If you haven’t already read my Drupal to WordPress Migration Guide, I recommend you first head over there to get an idea of what’s involved. It can be tempting to get straight to setting up WordPress, trying out new themes and experimenting with plugins. Nevertheless, some basic preparation beforehand will save you lots of work.

Website owners and administrators know their content is important but it’s often treated as an afterthought in the excitement to play with the new content management system. After all, you can use the Drupal site as the template and simply export over all the content over, right? For some site owners that’s all there is to it. However, you should be aware that site migrations can have hidden pitfalls that turn an apparently simple project into one fraught with complications.

Avoid problems by planning your Drupal to WordPress migration before you even touch your server. Whether you migrate the site yourself or hire me to help you, this guide will give you a head start with your planning. Keep in mind that general project planning principles apply but there are already many resources on this topic. I will focus on the areas important specifically for a migration from Drupal to WordPress.

Step 1: Consider why you are migrating to WordPress

There are many content management systems available and I’m going to assume you have already thought carefully about why you’ve chosen WordPress. For the sake of completeness, I’ll include this step because your reasons will determine whether or not the migration project will be a success.

In case you need a reminder about the merits of either CMS, here are a few Drupal vs WordPress posts:

Comparison chart of WordPress, Drupal and Joomla (makeawebsitehub.com)
WordPress vs. Drupal: Choosing Between Two Platforms (Elegant Themes Blog)
WordPress vs Joomla vs Drupal – Which One is Better? (WP Beginner)
Drupal vs WordPress (Big Tuna Interactive)

If you haven’t already put together a migration requirements document, go ahead and create one now. I go through this migration requirements checklist with my own clients and it might help you too.

Step 2: Decide on your approach to building the WordPress theme

Just as in Drupal, the WordPress theme handles how your site looks. A migration to a new CMS often goes hand-in-hand with redesigning the site. I’ve put this step early on because a site redesign could be an entirely separate project. You might want to run in parallel with the migration or it could be something you’d want to start before kicking off the content migration.

You have three options:

Redesign the WordPress site entirely.
Create a custom theme based on your existing Drupal design.
Use one of the many pre-made free or premium WordPress themes.

If you have a successful site, any change, whether it’s a redesign, restructure or move to another content management system should be carefully considered. This article at Search Engine Journal gives an excellent overview of the things you should keep in mind: How To Avoid SEO Disaster During a Website Redesign – Top Marketer Concerns

Step 3: Be aware of any SEO impact when migrating to WordPress

WordPress has an excellent reputation for being SEO-friendly but beware of taking this for granted. The Search Engine Journal post linked in step two should have given you a sobering outlook on how making changes to your site will affect your SEO.

In my experience, preserving SEO takes a large part of the time and budget of many migration projects. Sometimes the cost will outweigh any benefit of trying to preserve the SEO customisations on your Drupal installation. This is often a commercial rather than technical decision. If you run a site that relies on search traffic, I recommend that you hire an SEO consultant to advise you. In fact, I will often work with and take direction from a client’s SEO consultant during a typical Drupal to WordPress migration project.

When looking for an SEO specialist, keep in mind that the techniques for migrations aren’t that much different from SEO considerations during a site redesign. At a minimum, you should be looking for someone who has good grounding in:

Technical SEO auditing: This is to give you a baseline of how the current Drupal installation looks from an SEO standpoint. These audits will help figure out how to recover if you see a drop in traffic after the migration to WordPress.
User experience (UX) optimisation: User experience is a big factor in SEO. A change in the site structure will almost certainly affect user experience.

For more information about the kind of work involved, see Preserving SEO during a Drupal to WordPress migration. This SEO checklist will help get you thinking about any SEO impact the migration will have to your site.

Step 4: Gather as much information as you can about your Drupal installation

Knowing as much as possible about your Drupal installation will help me come up with a more precise estimate for your migration project. If you’re doing the migration in-house, it will help you plan how much time to set aside and which team-members need to be involved.

Site owners who built and manage the site will likely have records of some information but not necessarily all the details of how Drupal is configured. Site owners also come to me with a site built by a third-party. They have working knowledge on how to manage it and add content but not anything else. I can help you discover the information needed for the migration if you are in this position but you can save budget by doing some investigation yourself. Use my Drupal to WordPress migration worksheet as a guide.

The formal name for this is a site audit but essentially you need to find out about two areas:

How to access your server
What kind of content you have

Server audit

You’ll need your FTP server details to access your Drupal installation, media files and to upload the WordPress package. When running a migration, I like to download a full working version of the Drupal site on my local development server. This isn’t necessary but can be useful for figuring out formatting problems that crop after content migration. For example, you may find missing bits of text on WordPress and some investigation on the Drupal installation will show the text will be from a custom field or block.

The database server is necessary for exporting your Drupal database and setting up WordPress when the migration is complete. Some hosting providers offer access through a cPanel interface, a separate phpMyAdmin link or by command line. Gather all these details ahead of time will help get your project started quickly.

Content audit

The content audit helps you discover what type of Drupal content do you have. Drupal, like most other content management systems, keeps content in two places:

The database
On the server filesystem

Types of content include:

Nodes
Views
Blocks
Panes
Taxonomies
Static HTML files
Embedded media like videos, images and audio
File attachments
User profile information
Content metadata

You may be surprised where the different bits of content that make up your site ends up being stored. A content audit will avoid unnecessary complications with trying to hunt down bits of data mid-migration. My Drupal content audit checklist should get you started.

Step 5: Write a Drupal to WordPress migration mapping document

The migration mapping document will help both with quoting for project as well as keeping track of everything that needs to be done during the migration. It gives everyone involved a framework to work on.

I know, this sounds like a mouthful and so very tedious. Truth be told, few people find writing specification documents fun but it is a necessary step if you want to avoid unexpected costs and delays. The more detailed you are, the fewer surprises there will be for everyone during the actual migration. Your investigations during step 4 will lay the groundwork for the migration specification.

I will write another post on how to write migration mapping document but the document doesn’t have to very formal. All it needs to do is clearly convey the state of your Drupal site and what you’d like migrated to WordPress.

Ready for your migration project

Running through these steps will put you in a good position for your migration from Drupal to WordPress. Admittedly, there have been projects where I or the site owner didn’t bother to do any detailed planning and we were able to get by. Usually, this was because of limited budget or a rush to launch the new WordPress site. However, the projects where we took some time out to plan ahead were always closer to the estimated budget and posed fewer surprises.

A little plug to keep the lights running. If you think all of this work is too much trouble, please consider hiring me for your Drupal to WordPress migration project.

Drupal to WordPress migration service

Drupal 6 and Drupal 7 · All content · Custom content types · SEO · Plugins

If you’re not sure how to make the appropriate changes or would simply like someone else to do the work, please contact me and ask about my Drupal to WordPress migration service.

Get a quote

Drupal to WordPress migration worksheet

Anthony Lopez-Vito — Mon, 25 Apr 2016 00:00:14 GMT

If you are using my Drupal to WordPress Migration Tool or have hired me for Drupal to WordPress migration service, it’s important that you gather as much information as you can about your Drupal installation. The more detailed you are in your investigation, the fewer surprises there will be during the actual migration. You may have hired a web development company or freelancer to build your site and they’ll sometimes be able to provide you with the necessary information. However, gathering this information can involve some work so they may be reluctant to provide help without an extra fee.

You can use the questions below to help structure your investigation process. I can help you with this if you’re not able to run the investigation yourself. Please ask for details.

Drupal Installation Questions

What are the FTP login details of your hosting provider?You will need these details to make a backup of your Drupal site. When the migration is complete, you’ll need them to install WordPress on your server.

FTP Credentials
Host
Port
Protocol
Username
Password	Send through secure channel e.g. password manager

What are the database login details of your hosting provider?You’ll need these to export your Drupal database to perform the migration.

Database Credentials
Host
Port
Database name
Username
Password	Send through secure channel e.g. password manager

Do you know how to export your database to a dumpfile?If you’re unsure how to export your database to a ‘dumpfile’, please contact your hosting provider. They will likely have tools such as phpMyAdmin and help articles to guide you through the process.

	Yes/No
I know how to export my database to a dump file
I need help exporting my database to a dump file

What version of Drupal are you running?The database column names differ slightly between Drupal versions. This means that a different set MySQL queries will be needed to perform the migration. You can sometimes find this information using your installation’s CHANGELOG file at http://[YOURDOMAIN.COM]/CHANGELOG.txt. Some developers remove this file as part of their security hardening process so it may not exist in your installation.

Drupal version

List your Drupal modules and site functionalityCan the functionality can be handled with existing WordPress plugins? Will you need to develop custom plugins?

Drupal modules and functionality

How many custom content types do you have set up?Additional migration MySQL queries will be needed for each Drupal custom content type. WordPress supports page and post content types as standard. Additional development work will be needed to support other content types.

Drupal custom content types

How many custom fields do you have set up?As with custom content types, custom fields in your Drupal installation will need additional work to support them under WordPress.

Drupal custom fields

Do you have blocks, views and panes with important content?Many Drupal sites display content in blocks, views and panes. These will also need additional work to support under WordPress.

Drupal blocks, views and panes

How many nodes do you have?The number of Drupal nodes you have does not usually play a big factor in the complexity of the migration. However, it will still be useful to get an idea of the number since many nodes can have an impact on how long it takes to troubleshoot migration problems.

Approximate number of Drupal nodes

Do you expect to have multiple aliases referencing the same post?Drupal supports multiple URL aliases for nodes. These will need to be resolved when migrating to WordPress. For more information, please see my article Preserving SEO during a Drupal to WordPress migration.

Brief description of what to do with multiple aliases
It’s OK if you don’t know. We can discuss your options.

Do you expect to have duplicate terms?Duplicate Drupal terms can cause problems during a migration. For more information, please see my article Handling Drupal terms during a Drupal to WordPress migration

Brief description of what to do with duplicate terms
It’s OK if you don’t know. We can discuss your options.

Will your terms exceed the WordPress’ 200 character length?WordPress has a 200 character limit for terms. Any Drupal terms longer than 200 characters will need to be truncated.

Brief description of what to do with problem terms
It’s OK if you don’t know. We can discuss your options.

How many users do you have?The number of users doesn’t play a big factor during a migration but it may be useful to know.

Approximate number of users

How many user roles do you have?Your Drupal user roles may need to be converted into WordPress roles.

List and brief description of user roles
It’s OK if you don’t know. We can discuss your options.

WordPress Installation Questions

Will preserving SEO be an important part of the project?For more information, please see my article Preserving SEO during a Drupal to WordPress migration.

	Yes/No
Preserving SEO is important for this project

Aside from migrating to WordPress, do you also plan to redesign the site?Redesigning the site will obviously involve more work as it will require a custom WordPress theme. Some site owners are happy to use a free or premium off-the-shelf theme template.

Ideas for the WordPress theme
e.g. list the names, URLs and prices of any pre-made template candidates

Are there existing WordPress plugins that match your Drupal functionality?If you’re happy to be flexible, you may find WordPress plugins that closely match any Drupal modules you have installed on your existing site. Set aside some time to search the WordPress Plugin Directory. If you don’t find anything suitable, you may have to consider setting aside some budget for custom plugin development.

List some possible WordPress plugins you may have found

Focus on your mission, not your tech - Another Cup of Coffee (Posts about Drupal)

Drupal 7 End of Life: Why WordPress is the Best Migration Option for Lower Maintenance Sites

Final Deadline Announced After Multiple Extensions

What Happens If You Stay on Drupal 7?

Why Choose WordPress Over Upgrading Drupal?

Is it Worth Upgrading Drupal?

Real-World Success Stories

How We Handle Migrations at Another Cup of Coffee

Our Process:

Why WordPress is the Smarter Choice Today

Let's Talk

Drupal 7 End of Life Frequently Asked Questions

Footnotes

You may also like

The Benefits of migrating from Drupal to WordPress: Key Insights from WP Engine's Latest Webinar

Table of Contents

Watch the Webinar

Speakers

The Current CMS Landscape

Drupal's Declining Position

WordPress's Market Dominance

Key Migration Drivers

Ease of Use and Training

Cost Considerations

Drupal vs WordPress: Total Cost of Ownership

Technical Flexibility

Practical Migration Considerations

Pre-Migration Planning

Stakeholder Engagement

Security and Maintenance

Security Protocols

Ongoing Maintenance

Real-World Success Story

Conclusion

Appendix: Key Statistics from the Webinar

1. The Current CMS Landscape

Drupal's Market Position

WordPress's Dominance

2. Critical Timeline Considerations

Version Support Deadlines

Migration Timeframes

3. Technical Migration Considerations

Platform Differences

WordPress Migration Benefits

4. Security and Maintenance

End-of-Life Impact

Footnotes

You may also like

How To Set Up Drupal 7 Docker Containers for Migration Projects

Table of Contents

1. Introduction

2. Upgrade Drupal 7 or Migrate?

3. Hassles with Setting up the Migration Environment

4. An Introduction to Docker

What is Docker?

Why Use Docker for Migrations

Key Advantages and Limitations of Docker

Essential Docker Concepts

5. How to Set Up Docker Containers for Drupal 7 Migrations

1. Install Docker

2. Create Your Project Structure

File and Database Persistence

3. Download the Drupal Installation Files

4. Create Your .env File

4. Create Your Drupal Dockerfile

5. Create a phpMyAdmin Dockerfile (optional)

6. Create Your docker-compose.yml File

The MySQL Image

7. Build and Start the Environment

8. Access Your Local Drupal Setup

6. Testing and Workflow

Basic Testing

Testing Your Migration Utilities With Sample Content

1. Log Into the Container's Terminal

2. Install Helper Modules

3. Generate Sample Content

Development Workflow

7. Preparing for Your Drupal 7 Migration

Importing Your Live Drupal Installation into the Container

Creating a Pristine Snapshot

4. Create Your `.env` File

6. Create Your `docker-compose.yml` File