With the launch of WordPress 7.0, the platform has undergone one of its most significant architectural evolutions in years. Instead of treating artificial intelligence as a collection of disjointed features to bolt on, Core now includes a standardized, native infrastructure layer.

At the center of this is the Connectors API, a centralized, native registry in WordPress 7.0 that allows you to manage your external service credentials in one place instead of forcing you to configure them across multiple separate plugins. As Greg Ziółkowski writes in the Make WordPress post linked above, “The initial focus is on AI providers, giving WordPress a standardized way to handle API key management, provider discovery, and admin UI for configuring AI services.”

While this solves a massive headache, it also introduces new questions about where and how you should stash your secrets.

Saving your keys via the dashboard is convenient, but storing scalable, high-cost AI credentials as plain text in a centralized database table has its downsides. An AI API key can essentially serve as a blank check tied to an open-ended billing account. If an attacker extracts it via the database, the financial liability could be massive. In this article, we explore why shifting your credentials to environment variables is a more secure choice.

Centralized Secrets

Before WordPress 7.0, a site using three different AI-powered plugins required pasting API keys into three entirely different settings screens. This method resulted in fragmented credential storage, messy rate-limiting, and unpredictable security risks.

WordPress 7.0 fixes this by decoupling the core infrastructure from the specific service providers.

• Core Infrastructure: WordPress Core now provides the unified registry layer and the native API endpoints.
• Companion Plugins: Individual service connections (like OpenAI, Anthropic, or Google) are managed by official companion plugins that register in the Core ecosystem.

The result is a centralized hub located at Settings → Connectors. While this unification provides seamless configuration, it means that a single point of entry now holds the keys to your entire external application ecosystem.

Understanding the Authentication Hierarchy

Securing this architecture requires looking at how WordPress evaluates credentials. The Connectors API uses a strict, three-step waterfall logic to check for API keys:

1. Environment Variables (Highest priority)
2. PHP Constants (e.g., define( 'OPENAI_API_KEY', 'sk-...' ); inside wp-config.php)
3. Database Options (Values submitted through the Settings → Connectors UI)

[System Request] 
       │
       ▼
 1. Environment Variables ───► Key Found? ───► [Authenticate]
       │ (Bypasses DB)
       ▼ Key Empty
 2. PHP Constants         ───► Key Found? ───► [Authenticate]
       │
       ▼ Key Empty
 3. Database Storage      ───► Pulls Plain Text from wp_options

Defining your secrets at the server level with environment variables automatically short-circuit this evaluation chain. WordPress never triggers the database lookup for the key, reducing query load and keeping your raw credentials completely decoupled from the database layer.

“Masked” Does Not Mean “Secure”

If you input an API key into the WordPress admin interface, the screen will gracefully mask the characters with bullet points or asterisks. However, masked does not mean encrypted.

Under the hood, WordPress stores these credentials as raw, plain-text strings inside the wp_options table. Because of this storage model, your site’s external accounts are exposed to several common vectors:

• SQL Injection (SQLi): If an unpatched plugin introduces an SQLi flaw anywhere on your site, an attacker can read the raw contents of the wp_options table and extract your production API keys.
• Database Export Exposure: Unauthorized database dumps, poorly secured staging environments, or unencrypted backups left in public directories immediately compromise your external billing accounts.

NOTE: The WordPress community recognizes this plain-text limitation. Core ticket #64789 is actively tracking proposals to introduce native database encryption for sensitive stored options in future releases.

Database Cleansing and Syncing with WP Migrate

When transitioning from database storage to server-level environment variables, you must ensure that your deployment tools don’t accidentally leak production keys downward to local environments.

The Connectors API uses a standardized naming schema for options stored in the database:

connectors_{$provider_type}_{$provider_id}_api_key

Because these options use a predictable prefix, configuring your synchronization tools is straightforward.

Preserving Environment Boundaries

When pushing or pulling databases with WP Migrate, you must prevent sensitive credentials from migrating between environments. Use the wpmdb_preserved_options filter to ensure that local or staging variables are never overwritten by a production database pull:

add_filter( 'wpmdb_preserved_options', function( $options ) {
    // The provider type group in WP 7.0 is 'ai'
    $options[] = 'connectors_ai_openai_api_key';
    $options[] = 'connectors_ai_anthropic_api_key';
    return $options;
});

Database Sanitization

Once you have successfully declared your keys as environment variables at the system level, your site immediately switches to them, rendering the database values obsolete. At this point, you can use WP Migrate’s find-and-replace feature to search your wp_options table for the connectors_ string prefix and safely delete those obsolete records.

Wrapping Up

The Connectors API in WordPress 7.0 is a phenomenal structural step forward for the ecosystem, turning the CMS into a highly capable platform for integrated AI capabilities. However, a framework is only as secure as its implementation.

Relying on default database storage exposes your critical external integration credentials to unnecessary vulnerabilities. By embracing the authentication hierarchy and prioritizing server-level environment variables, you harden your infrastructure and protect your operational budgets.

The post Environment Variables vs. Database: Securing the Connectors API appeared first on Delicious Brains.

Modern development workflows have mostly solved the file problem. We use Git to version our themes and plugins, and we use CI/CD pipelines to deploy those files to staging and production. But for many teams, the database remains a manual, high-stakes bottleneck.

Whether you are pulling production data down to a local environment for debugging or pushing a new ACF field structure up to staging, relying on manual SQL exports and imports is a recipe for disaster. It’s slow, it’s prone to human error, and it’s the most common way to break serialized data.

To reach true deployment maturity, you need to automate the database layer. That’s where WP Migrate’s integration with WP-CLI comes in.

Why wp db export Isn’t Enough

Many developers start by using the native wp db export and wp db import commands. While these are great for simple backups, they are dangerous for migrations between environments.

The primary culprit is serialized data. WordPress often stores complex data (like widget settings or ACF configurations) as serialized PHP objects. If your search-and-replace changes the length of a string (e.g., changing http://localhost to https://production.com), a standard SQL find-and-replace will break the serialization, and the data will simply vanish from the frontend.

Unlike standard SQL exports that treat the database like a flat text file, WP Migrate’s background logic handles search-and-replace at the PHP level. When the migration runs, the plugin identifies serialized data and temporarily unserializes it to perform the string replacement on the actual data structure. Once the strings are updated, it re-serializes the data and automatically recalculates the internal string-length counts before committing it to the destination database. This process ensures your metadata remains intact even when the new site URL has a completely different character count than the old one.

The Bridge: Migration Profiles

You can start firing off commands in the terminal at this point, but it’s probably better to create a Migration Profile first. Migration Profiles are a specialized feature provided by WP Migrate to manage complex configurations.

Migration Profiles are basically saved presets for your migration. In the WP Migrate UI, you define:

• Which tables to include or exclude.
• Specific find-and-replace pairs.
• Whether to sync the Media Library or theme files.

By defining these in the UI first, you avoid the headache of passing dozens of complex arguments into a terminal command. Once saved, the CLI can trigger the entire logic of that profile using a single ID.

Selective Table Syncing: Protecting Production

The most significant risk in database automation is the push operation, when you move data from a lower environment (like Local or Staging) to the live Production server. If you push a full database that you’ve been working on for several days, you will overwrite the live site with your outdated local data, potentially wiping out every eCommerceorder or user registration that happened while you were developing.

This is where selective syncing becomes a mandatory safety measure. Instead of an “all or nothing” approach, WP Migrate’s integration with WP-CLI allows you to be surgical. In your Migration Profile, you should configure specific exclusions for transactional tables:

• wp_users and wp_usermeta
• wp_comments
• wp_posts and wp_postmeta (specifically if you only want to sync settings/structures, not content)

By excluding these, you can perform a structural push that sends new ACF field groups or plugin configurations to production without the nightmare scenario of deleting customer data.

The Workflow: Push vs. Pull

In a professional pipeline, the direction of your migration depends on your goal.

Direction	Command	Best For…	Risk Level
Pull	wp migrate pull <ID>	Refreshing staging with fresh production data.	Low (Overwrites local/staging)
Push	wp migrate push <ID>	Deploying new ACF structures or settings to staging.	High (Overwrites remote)

Automating with Secret Keys

WP Migrate uses secret keys for authorization. This means you don’t need to manage complex SSH tunnels just to move data. When setting up your CI/CD pipeline (like GitHub Actions), you should store these credentials as environment-scoped secrets within your CI/CD provider (like GitHub Actions or GitLab CI).

By scoping secrets specifically to the Production environment, you can implement protection rules, such as requiring a manual approval before the secrets are injected into a workflow. This ensures that a database push to your live site only happens when a senior team member has signed off on the deployment.

Real-World Implementation: GitHub Actions Snippet

Here’s how you might automate a Pull request to refresh a Staging site with Production data whenever a new release is tagged.

jobs:
  db-refresh:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger WP Migrate Pull via SSH
        uses: appleboy/ssh-action@master
        with:
          host: ${{ secrets.STAGING_HOST }}
          username: ${{ secrets.STAGING_USER }}
          key: ${{ secrets.SSH_PRIVATE_KEY }}
          script: |
            # Navigate to the site root and trigger the saved profile
            cd /var/www/html
            wp migrate pull 5 --path=/var/www/html

In this example, the number 5 represents the specific ID of a Migration Profile created in the WP Migrate UI. Once you’ve identified your ID via the wp migrate profiles list command, the CLI takes it from there, automatically executing the authentication, the PHP-level search-and-replace, and the table exclusions you’ve already defined. This keeps your deployment script clean, as the heavy lifting of the configuration stays within the profile itself.

Conclusion

Manual migrations are basically technical debt. They eat up developer time and introduce unnecessary risk into your deployment cycle. By leveraging WP Migrate’s integration with WP-CLI, you move the database out of the manual task column and into your automated pipeline.

Whether you are syncing data for QA or deploying complex structural changes, using Migration Profiles and WP-CLI ensures that your environments stay in parity and your serialized data stays safe.

The post Automating Database Syncs with WP Migrate and WP-CLI appeared first on Delicious Brains.

Relocating a WordPress website to a new domain is a frequent task for developers, but it often comes with the risk of broken links and lost content. Ensuring a seamless transition where every URL, image, and internal reference correctly points to your new domain is critical for user experience and SEO.

In this article, we outline the steps required to move your WordPress site to a new domain without breaking links. We will primarily utilize WP Migrate Lite for the core migration process, demonstrating precise database and file handling. We’ll also explore how WP Migrate can further streamline and accelerate these domain transfer workflows.

Understanding the Domain Migration Challenge: Why Links Break

Moving a WordPress website to a new domain often results in broken links. This happens because WordPress stores absolute URLs and file paths directly within its database. It doesn’t rely solely on relative paths.

A WordPress site’s primary address is stored in the siteurl and home options within the wp_options table. However, beyond these obvious locations, your old domain’s URL is embedded in countless other places:

• Within the content of your posts and pages in the wp_posts table.
• In custom fields managed by plugins or themes (often in wp_postmeta).
• In widget settings, navigation menus, and various plugin configurations, which are frequently stored as complex, serialized data within the wp_options table or custom tables.
• Direct links to media files, which also contain the domain name.

The challenge with this deep embedding, particularly with serialized data, is that a simple text-based search and replace on a raw SQL file can corrupt these complex data structures. If the length of the string changes during a simple replacement, it can break the serialization, rendering menus, widgets, and many plugin settings nonfunctional. The solution is to use a tool that can intelligently find and replace these URLs and paths while preserving data integrity.

Pre-Migration Checklist: Preparing for a Smooth Transition

A successful WordPress domain migration relies heavily on thorough preparation. Taking the time to complete a few key steps before you begin the transfer process can save you from significant headaches, unexpected downtime, and data loss. This checklist ensures your source site is ready for export and your destination environment is prepared to receive the data.

Full Backup: Your Essential Safety Net

Before making any changes to your live site, the single most critical step is to create a complete and verified backup of your entire WordPress installation. This includes both your database and all your website files (themes, plugins, media uploads, and core WordPress files). This backup serves as your absolute failsafe. If anything goes wrong during the migration, you can revert to the original state of your site without permanent data loss. Store this backup securely in an off-site location, not on the same server.

Update Everything

Outdated WordPress core files, themes, or plugins can introduce compatibility issues or unexpected behavior during a migration. Before you begin the export, ensure that all components of your source WordPress site are updated to their latest stable versions. This minimizes the chances of encountering errors related to old code when the site is transferred to a new environment.

Clean Up Your Site

To reduce the size of your migration package and streamline the transfer process, it’s beneficial to perform a site cleanup. This involves:

• Deleting unused themes and plugins: Remove any themes or plugins that are no longer active or necessary.
• Removing old media: Consider deleting any unused images or media files from your Media Library that are no longer relevant to your site.
• Cleaning your database: Utilize a database optimization plugin or manually clear old post revisions, spam comments, and transient options. A smaller, cleaner database will export and import faster.

Prepare Your New Domain and Hosting Environment

Before initiating any export from your old site, ensure your new destination is ready.

Make sure the new domain name is registered and accessible and have your new hosting account provisioned and ready. It is generally recommended to start with a completely fresh, default WordPress installation on your new domain. This provides a clean slate to import your old site’s data and files into. You’ll replace its database and wp-content folder with your old site’s data.

Step-by-Step: Moving Your Site with WP Migrate Lite

This section looks at the steps required to export your site’s database and files from your old domain and successfully import them onto your new one, ensuring all internal links are correctly updated.

WP Migrate Lite offers a Full Site export option that bundles both your database and files, but in this case we’re going to export the database and files separately. For a domain migration, this approach emphasizes the critical URL replacement within the database, provides greater control over each component for precise execution, simplifies troubleshooting if issues arise, and can make managing larger site transfers more efficient than a single, massive archive.

Install WP Migrate Lite on Your Old Domain’s WordPress Site

First, ensure the WP Migrate Lite plugin is installed and activated on the WordPress installation running on your old domain. You’ll find it by navigating to Tools .> WP Migrate in your WordPress admin sidebar.

Export Your Database with Domain Replacement

This is the most critical part of a domain migration, as it handles the updating of all old URLs to the new ones directly within your database. WP Migrate Lite’s intelligent Find and Replace feature is essential here.

From your old domain’s WordPress admin, access WP Migrate Lite’s main interface, select the Migrate tab, and then click Export

The “Database” checkbox should be checked by default. Next, click Tables, and ensure that the radio button “Export all tables with prefix “wp_”” is selected. This ensures every piece of data stored in the database is included, including site options, post content, and plugin settings.

The next step is to configure a “Standard Find & Replace.” The “Find” field should be automatically pre-filled with your current (i.e., old) domain’s URL. In the “Replace” field, carefully enter the full URL of your new domain, ensuring you include the correct protocol (http or https).

WP Migrate Lite will intelligently handle serialized data within your database during this process, which is crucial for preventing data corruption that a simple text search-and-replace often causes.

You can also set a different path for your new domain. This isn’t necessary in most cases, as WP Migrate Lite will automatically set up the new path for you.

Once configured, click the Export button. WP Migrate Lite will process your database, perform the replacements, and generate a SQL file containing your database.

Export Your WordPress Files

After exporting your database, the next step is to export all the necessary files from your old WordPress installation. This includes your themes, plugins, media uploads, and potentially other custom files or WordPress core itself.

Click on the Migrate tab and then select Export again. The “Database” section will be checked by default. Since you’ve already exported and handled your database in the previous step, the first action here is to uncheck the Database box.

Next, we’ll configure the file exports from the remaining sections.

Media Uploads

This section handles the files within your wp-content/uploads folder. Check the Media Uploads box. A dropdown will then appear offering three options for how to export these files. For a full domain migration where you want all your media to be on the new site, you should select “Export all media uploads”. This option ensures all files from your uploads folder are copied. The other options, “Export new and updated media uploads” and “Export media uploads by date,” are generally more suited for partial content syncs rather than a complete domain transfer.

Themes

This section allows you to export your theme files located in wp-content/themes. Check the Themes box. The accompanying dropdown provides several choices. For a complete domain migration, select Export all themes to ensure every theme from your old site is included. Other options like “Export only active themes” or “Export only selected themes” are available if you have specific needs.

Plugins

Similar to themes, this section manages the export of your plugin files from wp-content/plugins. Check the Plugins box. From the dropdown, select Export all plugins to include all plugins from your old site in the migration package. This section offers the same options as “Themes”, but for plugins.

Other Files

The “Other Files” section is for selecting any additional files or folders found directly within your wp-content directory that are not covered by the “Media Uploads,” “Themes,” or “Plugins” sections. Check the Other Files box. A checklist will then appear, allowing you to manually select individual files or folders you wish to include. These might be custom configurations, uploads outside the standard directory, or other specific assets. None are selected by default, so you must carefully choose any you need.

Each of the “Media Uploads,” “Themes,” “Plugins,” and “Other Files” sections also provides an advanced option to use gitignore patterns to exclude specific files relative to their respective directories. This is useful for highly customized exports where certain files (like cache files or development-specific assets) should not be migrated.

WordPress Core Files

The “WordPress Core Files” section addresses the core WordPress installation itself. Check the “WordPress Core Files” box. Including WordPress core files ensures that the exported archive contains the exact version of WordPress installed on your site, which is particularly helpful when replicating the site precisely in a new environment. This option includes the wp-admin and wp-includes directories, along with various root WordPress files such as index.php, license.txt, readme.html, and crucial configuration files like wp-config.php and wp-config-sample.php.

Once all your desired file sections are configured, click the “Export” button. WP Migrate Lite will package your selected files into a single ZIP archive.

.

Prepare Your New Domain’s WordPress Installation

Before importing your old site’s content, you need a fresh WordPress installation on your new domain to serve as the destination. Ensure your new domain name is pointed to your new hosting environment’s server, and then set up a completely fresh, default WordPress installation on your new domain.

Once the new WordPress site is accessible via your new domain, log in to its admin dashboard and delete any default content (e.g., “Hello world!” post, sample page, sample comment) to provide a cleaner slate for your imported data.

Manually Import the Database to Your New Domain

Now you will replace the fresh WordPress installation’s database on your new domain with the one you exported and modified from your old site.

Access your new domain’s database, typically through a tool like phpMyAdmin via your hosting control panel, or a command-line interface (CLI) if you have SSH access.

If using phpMyAdmin, select the database associated with your new WordPress installation from the left sidebar. Click on the Structure tab. Scroll to the bottom of the list and click the checkbox labeled Check all. From the “With selected:” dropdown menu, choose “Drop”. You will receive a confirmation prompt asking if you truly want to execute the DROP TABLE query. Confirm the action. This step is crucial as it clears out the default WordPress tables to make way for your imported data.

Next, go to the Import tab. Click Choose File and select the SQL file you exported with WP Migrate Lite. Ensure the character set and other options are correct (usually the default is fine). Click Import to begin the import.

If using WP-CLI, SSH into your new hosting environment and navigate to your new WordPress installation’s root directory. Ensure your wp-config.php file has the correct database credentials for the new database. Then, run the command: wp db import /path/to/your/downloaded/database.sql (remember to replace /path/to/your/downloaded/database.sql with the actual path to your SQL file, which you’d need to upload via SFTP first). This command will automatically drop existing tables and import your new data.

Manually Transfer Files to Your New Domain

With the database imported, the final step for WP Migrate Lite is to transfer your themes, plugins, and media files to the new domain.

Extract the contents of the ZIP file you downloaded from WP Migrate Lite. This will give you a “wp-content” folder and potentially other root WordPress files. Using an FTP or SFTP client, connect to your new hosting environment and navigate to the root directory of your new WordPress installation.

Upload the wp-content folder from your extracted ZIP file to your new WordPress installation’s root. When prompted, instruct your FTP/SFTP client to overwrite any existing files and folders within wp-content. This will replace the default themes, plugins, and empty uploads folder with those from your old site.

If your old site had custom .htaccess rules, a robots.txt file, or specific modifications to wp-config.php (beyond database credentials), you may need to transfer these files individually from your extracted ZIP’s root directory to the new site’s root. Exercise extreme caution when transferring or merging wp-config.php, as incorrect details will break your site. It is often safer to manually re-add specific customizations to the new wp-config.php rather than replacing the entire file.

Post-Migration Checks and Final Steps

Even with careful execution, some final checks are essential to ensure your site is fully functional on its new domain.

Log in to the new domain’s WordPress admin and navigate to Settings > Permalinks. Without making any changes to the permalink structure itself, simply scroll to the bottom of the page and click the Save Changes button twice. This action flushes WordPress’s rewrite rules, ensuring all your posts and pages are accessible at their new URLs.

Ensure you clear all caches if you had any caching plugins active on your old site, or if your new hosting uses server-side caching. This prevents the site from serving outdated information or getting stuck in redirect loops.

Finally, thoroughly test your new site. Systematically navigate through it, clicking on various posts, pages, and custom post types, testing all navigation menus, checking all images and media files, submitting forms, and verifying plugin functionalities.

Once you are completely satisfied that your site is working perfectly on the new domain, update your domain’s DNS records to point to your new hosting environment’s server. This is the final step that makes your new domain the primary live address for your website. DNS propagation can take up to 24-48 hours.

If your old domain was previously indexed by search engines and you wish to preserve SEO value, it is highly recommended to set up 301 permanent redirects from every URL on your old domain to its corresponding URL on the new domain. This tells search engines that your content has permanently moved.

Streamlining Domain Migrations with WP Migrate

While WP Migrate Lite provides the necessary tools for a successful manual domain migration, the multi-step process involving file transfers, database imports, and manual configurations can be time-consuming and prone to human error, especially for larger sites or frequent domain changes. WP Migrate directly addresses these challenges, offering a highly streamlined and automated workflow that significantly reduces effort and risk.

One advantage of WP Migrate is its direct push and pull functionality for both databases and files. This feature completely bypasses the need for manual download, upload, and import steps. Instead, you establish a secure, direct connection between your source and destination site. From the source site, you can “push” the entire site directly to the new domain, complete with its database, themes, plugins, and media uploads. WP Migrate handles all the underlying complexities, including intelligently performing the necessary URL and path replacements and correctly dealing with serialized data, all in one coordinated operation. This capability dramatically accelerates the migration process and virtually eliminates the risk of errors associated with manual transfers.

WP Migrate’s WP-CLI integration provides a powerful avenue for automation. This means you can initiate and control domain migrations directly from your command line. For those utilizing version control and continuous integration/continuous delivery (CI/CD) pipelines, this allows domain migration steps to be scripted and integrated into automated deployment processes, enhancing efficiency and reliability across your development ecosystem.

Collectively, these premium features transform a potentially tedious and error-prone domain migration into a fast, reliable, and often automated task. By eliminating manual steps and leveraging intelligent, direct site-to-site communication, WP Migrate significantly reduces both the time commitment and the inherent risks involved in moving your WordPress site to a new domain.

Wrapping Up

Relocating a WordPress website to a new domain doesn’t need to be fraught with broken links or lost content. Ensuring a seamless transition where every URL, image, and internal reference correctly points to your new domain is a matter of using the right processes and tools. A systematic approach allows you to confidently manage your WordPress site’s evolution and ensure it thrives on its new home.

Have you migrated a site to a new domain with WP Migrate or another tool? How was the process? Let us know in the comments!

The post Moving WordPress to a New Domain: A Step-by-Step Guide Without Breaking Links appeared first on Delicious Brains.

Managing WordPress sites across different environments often requires moving data and files. A partial migration involves selectively transferring only specific components of your WordPress installation. Instead of cloning an entire site, you might move just new database entries, an updated theme, or recently added media.

In this article, we look at the intricacies of partial migrations and explore practical scenarios where syncing only what you need can save significant time, prevent workflow disruptions, and streamline deployments.

What Are Partial Migrations?

The traditional approach of moving an entire website, a “full site migration,” involves copying every file and database entry. While necessary for initial deployments or major overhauls, this method can be inefficient and risky for ongoing development.

This is where partial migrations become essential. Instead of an all-encompassing transfer, a partial migration is the selective movement of specific components. This might involve targeting individual database tables, such as the wp_posts table to deploy new articles, or moving only new media uploads, an updated theme, or a single plugin.

The benefits of this granular approach are substantial. First, limiting the scope of the transfer reduces data volume, which translates to faster operations and less server load. Second, partial migrations minimize the risk of inadvertently overwriting critical data or configurations that may have diverged between your environments. This prevents unwanted regressions and simplifies troubleshooting. Finally, it enables truly targeted updates, allowing you to deploy isolated changes confidently, knowing you are only affecting the intended components of your site.

How to Perform Partial Migrations

WP Migrate Lite provides a straightforward interface for executing granular exports. While the subsequent import or file transfer steps are manual, the plugin significantly simplifies the data extraction process. Here, we’ll walk through common partial migration scenarios, detailing how to configure WP Migrate Lite for each.

To begin, ensure WP Migrate Lite is installed and activated on your source WordPress site, and then navigate to Tools > WP Migrate.

Scenario 1: Syncing New Content

This scenario is common when new articles, landing pages, or product entries are developed on a staging site and need to be published to a live production environment without affecting other data.

Navigate to the Export Tab

In your source site’s WordPress admin, access WP Migrate Lite’s interface. From there, select the Migrate tab and then click Export.

Configure the Export

WP Migrate defaults to a database export, without exporting WordPress core, media files, etc. Leave the “Database” checkbox checked, and then click the Tables dropdown.

In the Tables section, click Export only selected tables below, and then carefully select only the tables relevant to your content. At a minimum, this includes wp_posts (assuming wp_ is your table prefix). If your content utilizes custom fields, you should also select wp_postmeta. For new content involving categories or tags, ensure wp_terms, wp_term_relationships, and wp_term_taxonomy are also chosen. It is important to avoid tables like wp_users, wp_options (unless specific modifications are intended), or unrelated plugin tables to prevent unintended overwrites.

Configure Find and Replace

A crucial step for maintaining correct internal links and asset paths is configuring a Standard Find & Replace function. The “Find” fields should already contain the relevant URL and file paths of your source site. In the “Replace” field, input the URL of your destination site. This ensures internal links or embedded media URLs within your exported content are accurately updated for the live environment, with WP Migrate Lite intelligently handling serialized data.

Once all configurations are set, click Export. WP Migrate Lite will then process the selected tables, execute the find and replace operations, and generate a SQL file.

Manual Import

After downloading the generated SQL file, the next step is manual import. You will need to access your destination site’s database using a tool such as phpMyAdmin or through a command-line interface like WP-CLI. Import the SQL file into the destination database. Exercise caution if your new content might have conflicting IDs with existing content on the destination site. This method is generally most suitable for importing entirely new content.

Scenario 2: Synchronizing Media Library Additions

When new images, videos, or documents are uploaded to a development or staging environment and need to be moved to production, you can transfer only the new files and their associated database entries.

In your source site’s WP Migrate Lite interface, navigate to the Migrate tab and click Export.

Select Media Files Only

Select Media Uploads. This instructs the plugin to include only the contents of your wp-content/uploads directory in the export package. Within the “Media Uploads” options, you’ll be presented with choices for which files to copy. For synchronizing additions, you will typically choose Export new and updated media uploads. This option intelligently identifies and includes only those media files that have been added or modified since your last sync.

Alternatively, if you need to transfer media uploaded after a specific point in time, you could select Export media uploads by date and provide the exact date. This instructs the plugin to include only the contents of your wp-content/uploads directory in the export package based on your selection.

Configure Database for Media

In the Database section, choose Export only selected tables below. Media items also have corresponding entries in the database. In the “Post Types” subsection, select Export only post types selected below, and then choose attachment from the list. This ensures that only the database entries specifically related to your media library items (found within wp_posts and wp_postmeta) are exported. You will also want to ensure wp_posts and wp_postmeta tables are selected under the “Tables” section.

Configure Find and Replace

As with content, set up Find and Replace rules to update URLs from your source site to your destination site (e.g., https://staging.example.com to https://www.example.com). This step is vital to ensure media URLs are correctly reflected in the database.

Start the Export

Click Export. This action will generate a ZIP file that contains both the selected media uploads and the accompanying SQL database file.

Manual Transfer and Import

Once the export is complete, download the generated ZIP file. Extract the wp-content/uploads folder from this archive. Using an FTP or SFTP client, manually upload only the new or updated media files and folders to the wp-content/uploads directory on your destination server. Exercise care to avoid inadvertently overwriting existing files unless that is your explicit intention.

Concurrently, import the exported SQL file into your destination database using phpMyAdmin or WP-CLI. This dual action ensures the new media items are both physically present and correctly registered within your WordPress Media Library, making them accessible via the admin interface.

Scenario 3: Deploying a Specific Theme or Plugin Update

Deploying a specific theme or plugin update using a partial migration is particularly useful for custom code or when changes involve database updates, ensuring precise deployment without affecting other site components. When you’ve developed or updated a specific theme or plugin and want to push only those changes, a partial file export is the way to go. This avoids deploying an entire site archive when only one component has changed.

Navigate to the Migrate tab and click Export. In the Files section of the export configuration, select Themes or Plugins, depending on which you want to export,. Then, select only the folder of the theme or plugin you wish to export.

You usually don’t have to include the database as part of this export, unless your theme or plugin update specifically entails database changes that have not been managed separately. If database modifications are necessary, you would combine this file transfer with a corresponding selective database export and import process, as outlined in Scenario 1 or 2.

Finally, click the Export button to generate a ZIP file containing only the selected theme or plugin folder, and any database tables you’ve determined are needed.

Manual Transfer

Download the generated ZIP file, and extract the specific theme or plugin directory from within this archive. Then, utilizing an FTP or SFTP client, manually upload this extracted directory to the corresponding wp-content/themes or wp-content/plugins directory on your destination server. This action will typically overwrite the existing folder. It is always prudent to create a backup of the destination theme/plugin before proceeding.

Elevating Partial Migrations with Greater Capabilities

While WP Migrate Lite provides effective tools for granular exports, its capabilities are confined to the source site. The process of integrating those exports into a destination environment consistently requires manual effort. This reliance on manual download, upload, and import steps—whether for database files via phpMyAdmin or file transfers via FTP—quickly becomes a bottleneck for professional workflows.

This manual overhead significantly reduces efficiency for frequent synchronizations, particularly when dealing with large sites or complex data. It also prevents the automation crucial for modern development pipelines and lacks the direct bidirectional syncing needed to pull fresh data from a live site to a development environment. For occasional, simple exports, WP Migrate Lite is functional, but the limitations of manual processes become apparent when speed, automation, and integrated workflows are required.

When the demands of your workflow exceed the manual capabilities of WP Migrate Lite, WP Migrate offers a comprehensive solution. It transforms partial migrations into a direct, automated process, providing granular control and efficiency.

The core enhancement is its direct push and pull feature, allowing seamless, secure database and file transfers between WordPress sites without manual intermediate steps. This includes precise file synchronization, enabling direct transfer of only new or updated media, themes, or plugins through intelligent comparison of source and destination files. For WordPress Multisite networks, it provides specialized tools that simplify complex tasks like exporting individual subsites or migrating them between networks. Command-line interface integration via WP-CLI allows developers to script partial migrations, integrate them into CI/CD pipelines, and automate routine synchronization tasks.

To further streamline recurring operations, migration profiles can be saved, enabling quick, consistent execution of predefined partial migration settings.

Wrapping Up

A partial migration involves selectively transferring only specific components of your WordPress installation. Instead of cloning an entire site, you can now move just new database entries, an updated theme, or recently added media. This strategic approach to moving data and files is key for managing WordPress sites efficiently across different environments.

While partial migrations have their intricacies, there are scenarios where syncing only what you need can save significant time, prevent workflow disruptions, and streamline deployments. WP Migrate saves even more time by automating the steps you need to do manually when using WP Migrate Lite.

The post The Power of Partial Migrations: Syncing Only What You Need appeared first on Delicious Brains.

WordPress Multisite is a powerful tool, highly useful for things like client sites managed by an agency, school or university departments, or large corporate structures where many related sites are needed. However, moving existing standalone sites into that network can be a real headache, with tricky database merges and file juggling.

In this article, we look at two ways to approach this migration: the manual way with a bit of assistance from WP Migrate Lite, and the practically automatic way with WP Migrate.

What is WordPress Multisite?

Multisite is a WordPress feature that allows you to run multiple independent WordPress websites from a single WordPress installation. It allows you to:

• Manage everything centrally: Handle core updates, themes, and plugins for your entire network from one admin dashboard.
• Share resources: Themes and plugins can be installed once and activated across multiple sites within the network.
• Streamline user management: Users can often have accounts across different sites in the network.

Subdomains vs. Subdirectories

A critical choice you’ll make when setting up your multisite network is how the URLs for your individual subsites will be structured.

• Subdomains: Your subsites will appear as subdomains of your main network domain (e.g., site1.yourdomain.com, site2.yourdomain.com). This often requires your web host to support “wildcard subdomains” and can involve specific DNS configurations.

• Subdirectories: Your subsites will appear as subfolders of your main network domain (e.g., yourdomain.com/site1, yourdomain.com/site2). This typically relies more on .htaccess rules and is often simpler to set up initially on shared hosting.

This decision is made early in the Multisite setup process and is generally very difficult to change later, so choose wisely based on your hosting capabilities and desired URL structure.

Why Converting to Multisite Can Be Complex

Bringing existing single WordPress sites into the multisite fold isn’t a simple drag-and-drop. The biggest challenges are merging database tables, file organizations, and making sure URLs and serialized strings aren’t broken.

• Database Structure: Single sites use a straightforward set of database tables (e.g., wp_posts, wp_options). Multisite, however, uses global tables (like wp_users and wp_usermeta for the entire network) alongside site-specific tables, each with a unique prefix (e.g., wp_2_posts, wp_3_options). Merging these correctly without data corruption is the biggest hurdle.
• File Organization: Media uploads in a single site live in a simple wp-content/uploads/ folder. In a multisite, each subsite gets its own dedicated folder, typically wp-content/uploads/sites/[site_ID]/.
• URLs and Serialized Data: A single site’s database contains its old URL everywhere. When you move it to a multisite subsite, the URL changes. WordPress also stores complex data (like widget settings, theme options) in a serialized format. A simple find-and-replace on these strings can break them, leading to broken functionality.

Setting Up WordPress Multisite

The first thing you need is a functional WordPress Multisite network. We recommend testing everything on a staging site or in local development before rolling it out to production. Creating a [WordPress Multisite in Local(https://localwp.com/help-docs/advanced/wordpress-multisite-with-local/#Creating-a-new-Multisite-in-Local) is one way to get up and running quickly. Local also integrates with WP Migrate, the tool we’re going to use to transfer our database and files.

Next, create complete backups of all your sites, the single sites you plan to migrate and your fresh WordPress install that will become the multisite network. You never know when you’ll need a backup.

Migrating a Single Site to Multisite the Hard Way

This section outlines the process of converting a single WordPress site into a multisite subsite with a heavy reliance on manual effort. While WP Migrate Lite can help with providing a raw database export, the vast majority of the complex, multisite-specific adjustments will fall squarely on your shoulders.

Preparing the Source Site

Before you begin extracting data, it’s always a good practice to prepare your source site. A clean database will make things slightly less chaotic down the line. We recommend first taking the time to clean up your database by deleting unnecessary data like spam comments, old post revisions, expired transients, and any unused themes or plugins. This can be done directly in your database via a tool like phpMyAdmin or by using a dedicated cleanup plugin.

Once your database is tidied up, you’ll need to export its contents. Install and activate WP Migrate Lite on your single WordPress site, navigate to Tools > WP Migrate, and then click on the Migrate tab. Next, click on Export. From there, you have options to export just the database, or perform a “Full-Site Export” which bundles your database, media uploads, themes, plugins, and other wp-content files into a downloadable ZIP archive.

While WP Migrate Lite does offer a “Find & Replace” feature that can safely handle serialized data for general site moves (e.g., changing http://olddomain.com to http://newdomain.com when moving a single site to a new domain), for this specific Multisite scenario, you’ll ultimately need to access the raw .sql file for intricate manual editing. Whether you export just the database or a full site ZIP, you’ll then proceed to the next, most challenging step.

Manual Database Transformation

This is where the real challenge begins, and where even a single misstep can lead to a completely broken site. You’ll be working directly with the raw SQL file that contains your site’s database, so it’s absolutely crucial to have a fresh backup of that file before you start. For this intricate process, you’ll need a powerful text editor, like VS Code, Sublime Text, or Notepad++, that can handle large files and perform advanced find-and-replace operations.

The first major task involves manually adjusting your database table prefixes. Your single site’s database tables likely started with wp_ (for example, wp_posts, wp_options). In a Multisite environment, each subsite needs a unique prefix, typically wp_[subsite_ID]_ (such as wp_2_posts or wp_3_options). You must go into your database’s .sql file and meticulously perform a global find-and-replace for every instance of your old table prefix, replacing it with the new subsite’s prefix.

Now, here’s the huge, critical risk: while WP Migrate Lite’s built-in find-and-replace can handle serialized data safely when you’re just changing URLs within a single site context, it is not designed to automatically adapt serialized data for the complex table prefix changes required when moving a single site into a multisite subsite. WordPress stores complex data, like widget settings, plugin options, and various array data, in a serialized format. If you perform a simple text replacement on a serialized string that changes its length, you will corrupt that data. This often results in broken widgets, non-functional plugins, and missing settings on your new subsite, as standard text editors don’t understand the intricacies of serialized data lengths.

Following the prefix changes, you’ll face a similar challenge with URLs and paths. Your exported database is littered with references to your old single site’s URL. You’ll need to perform another series of global find-and-replace operations to update all these instances to reflect your new subsite’s URL (like http://multisite.com/subsite1 or http://subsite1.multisite.com). Be sure your target URL matches your multisite’s chosen structure, whether it’s http://multisite.com/subsite1 for subdirectories or http://subsite1.multisite.com for subdomains.

Once more, the danger of corrupting serialized data that contains these URLs looms large if you’re not using a specialized tool designed for these complex, length-sensitive replacements across various database structures within a multisite context.

Next comes the particularly thorny issue of user data merging. Multisite utilizes global wp_users and wp_usermeta tables, meaning all users across the entire network share these two tables. Your single site, of course, has its own dedicated wp_users and wp_usermeta tables. You absolutely cannot just import these directly.

Instead, you’ll need to carefully export only the user tables from your single site. Then, you must manually review them. If any user IDs from your single site conflict with existing user IDs on your multisite network, you’ll have to manually reassign new, unique IDs to the single site’s users within their wp_users and wp_usermeta rows. After that, these modified user rows must be meticulously merged into the Multisite’s global wp_users and wp_usermeta tables.

Finally, and this is a step that often requires writing complex custom SQL queries, you’ll need to update the post_author fields in your newly prefixed wp_X_posts table to ensure they correctly reference the new user IDs in the Multisite’s global wp_users table. Beyond these major structural changes, you might also find yourself manually adjusting site_id values in certain option tables to ensure everything correctly points to the new subsite.

Importing the Modified Database

Once you’ve painstakingly edited your SQL file, and double-checked (and triple-checked!) your work, it’s time to import it. It’s important to note that WP Migrate Lite does not provide an in-dashboard import feature for arbitrary SQL files or full-site ZIP archives back into a live WordPress site; its export is designed to be imported using external tools (or specifically into Local). Therefore, you’ll typically use a database management tool like phpMyAdmin. Log in, select the database associated with your multisite installation, and then use the “Import” function to upload your manually edited SQL file. This is often the moment of truth, where you’ll be hoping no errors appear.

Manual File Transfer and Reorganization

With the database n place, your next major task is to sort out the files. Even if you generated a full-site export ZIP with WP Migrate Lite, the manual database edits mean you’ll likely still be managing files externally.

First, connect to your multisite via FTP/SFTP. Navigate to the wp-content/uploads/ directory. You’ll notice a sites/ folder there, and inside sites/, you’ll find folders named after your subsite IDs (e.g., 2/, 3/). You’ll then take all the media files from your single site’s wp-content/uploads/ folder and manually upload them into the correct subsite’s designated directory (e.g., wp-content/uploads/sites/[subsite_ID]/). Even after moving the files, they might not immediately appear in your subsite’s media library. You might need to activate a specific plugin on the subsite to rescan and register these files in its database.

Beyond media, you’ll also need to manually upload any specific themes or plugins that your old single site used, if they aren’t already available network-wide on your multisite. Once uploaded, you’ll then activate the necessary themes and plugins for your new subsite from its dashboard.

Post-Migration Cleanup and Testing

Even if you’ve done everything perfectly, you need to thoroughly check the newly migrated subsite. Begin by clearing any caching plugins on your multisite, as well as any server-side or CDN caches. After that, go to the new subsite’s dashboard, navigate to Settings > Permalinks, and click Save Changes. This can often help re-write the permalink rules for the subsite and resolve potential routing issues.

Now comes the most critical part: extensive testing. Do not assume everything works just because the site loads. You must systematically visit all pages and posts to check that content displays correctly, images load, and all internal links function. Test any forms present on the site, verify that widgets and customizer settings are as expected, and ensure all plugins are functioning without errors. Crucially, test user logins and permissions on the new subsite, and double-check that all media links are correct and images display properly.

As you can see, performing this migration manually is a monumental undertaking. Even with a tool like WP Migrate Lite assisting with the initial database export and its general serialized data handling, the lack of specific multisite integration means you’re left with immensely complex manual tasks. It demands deep technical expertise, meticulous attention to detail, and a significant time investment for each and every site you plan to migrate. The risk of data corruption, especially with serialized data after table prefix and URL changes, and the complexities of merging user tables, remains extremely high. While it’s technically possible, it’s impractical for most, and certainly not scalable if you have more than one or two sites to migrate.

Simplify Your Life: Migrating a Single Site to Multisite with WP Migrate

This method leverages WP Migrate’s powerful premium features, specifically its “Multisite Tools” addon, to automate the most complex and error-prone aspects of migrating a single site into a multisite network. You’ll quickly see a dramatic reduction in the time, effort, and technical expertise required.

Install WP Migrate

The first thing you’ll need is a “Plus” or “Premier” license for WP Migrate, as these licenses include Multisite Tools.

Once you have your license, install and activate the WP Migrate plugin on both your source single WordPress site and your destination Multisite network. This dual installation allows the plugin to establish a secure connection between the two sites, enabling direct data transfer.

Prepare Your Source Site

Compared to the arduous manual method, source site preparation here is significantly simpler. While a general cleanup (like deleting spam comments or old revisions) is always good practice for a leaner migration, WP Migrate’s robust capabilities mean you don’t need to manually export databases or files. The plugin intelligently handles the find-and-replace for URLs and file paths, safely managing all serialized data without corruption.

Prepare the Destination Multisite

The foundational steps of setting up your WordPress Multisite network are still essential. You’ll need to have your multisite environment properly configured and running. Additionally, just as with the manual method, you’ll need to create a new, empty subsite within your multisite network that will serve as the destination for your incoming single site. This provides WP Migrate with the designated slot to pull your site’s data into.

Perform the Automated Pull Migration

This is where WP Migrate truly shines, automating tasks that were previously hours of painstaking manual labor. From your Multisite Network Admin dashboard:

1. Navigate to the WP Migrate plugin interface.
2. Select the “Pull” option. This tells the plugin you want to pull data from a remote site to your current multisite network.
3. You’ll then be prompted to connect to your remote source site (your original single WordPress installation). Once connected, WP Migrate will intelligently detect your multisite setup.
4. The plugin will offer you precise options for the migration. You’ll be able to select the specific single site you want to pull from, choose the newly created subsite on your multisite network as the exact destination for this migration, and select which components you wish to migrate: the database, media files, themes, and plugins.
5. With your selections made, you’ll initiate the migration. WP Migrate then takes over, performing a series of automated, complex tasks. It intelligently handles the find-and-replace for URLs and file paths, safely managing all serialized data without corruption. The plugin also correctly adjusts all database table prefixes from your single site to match the unique prefix of the target subsite (e.g., wp_ becomes wp_2_). It also merges your single site’s user data into the multisite’s global wp_users and wp_usermeta tables, correctly handling user ID assignments and references. Media files directly to the correct subsite-specific wp-content/uploads/sites/[subsite_ID]/ directory, and it even transfers your selected themes and plugins, making them available for activation on your new subsite.
6. You can monitor the progress of the migration directly within the WP Migrate interface, which provides clear feedback as it processes your data.

Post-Migration Testing is Still Important

Even with the automation provided by WP Migrate, thorough testing remains a critical step. While the likelihood of fundamental errors is drastically reduced, it’s always wise to verify everything works as expected.

• Clear Caches: As always, clear any caching plugins on your Multisite, along with server-side and CDN caches.
• Resave Permalinks: Navigate to your new subsite’s dashboard (Settings > Permalinks) and click Save Changes. This helps ensure the permalink structure is correctly refreshed within the multisite environment.
• Comprehensive Testing: Systematically check all aspects of your newly migrated subsite. Visit all pages and posts, verify images and media links, test forms, ensure widgets and customizer settings are correct, and confirm that all plugins are functioning as intended.

Comparing Methods

The contrast between the two methods is stark. The second way, powered by WP Migrate, transforms a labor-intensive, technically precarious process into a few clicks. What could take hours or even days of manual debugging and highly specialized knowledge is condensed into minutes, with a dramatically lower risk of error and data corruption. This powerful automation means less stress, more reliability, and ultimately, a much more efficient use of your time.

Wrapping Up

We’ve explored two distinct paths for migrating a single WordPress site into a multisite network. On one hand, the meticulous manual approach demands deep technical knowledge and carries a high risk of data corruption. On the other, a specialized tool transforms this complex process into an efficient and reliable operation.

The difference in effort and risk is striking. What could be a multi-day debugging nightmare becomes a matter of a few clicks, drastically reducing your time and stress.

This contrast clearly highlights a choice: tackle an incredibly intricate task with painstaking manual effort, or leverage automation designed to handle its complexities safely. For most, the investment in a solution that provides such efficiency, reliability, and peace of mind is invaluable.

The post Merging WordPress Sites: Consolidating Multiple Installs into a Multisite Network appeared first on Delicious Brains.

WordPress multisite networks offer flexibility, but a subsite often needs its own single installation for client needs, scaling, or simplified management. Separating a subsite is complex due to Multisite’s unique database structure, making manual migrations prone to errors, especially with serialized data. In this article, we look at the precise steps to migrate a subsite using WP Migrate Lite, and discuss the advanced automation and time-saving features available with WP Migrate.

The Unique Nature of Multisite Subsite Data

Migrating a subsite isn’t a simple copy-and-paste job because of how WordPress Multisite stores data. Unlike single WordPress installations, a multisite network uses a combination of shared and unique database tables.

• Shared Tables: The main network (site ID 1) uses standard WordPress tables like wp_options, wp_users, wp_usermeta, wp_posts, etc. These tables often contain data relevant to the entire network or default settings.
• Unique Subsite Tables: Each subsite within the network has its own set of dedicated tables. These tables are prefixed with wp_X_, where X represents the unique numerical ID of that specific subsite (e.g., wp_2_posts, wp_3_options). These tables hold all the content, settings, and user data specific to that individual subsite.

The importance of precision here cannot be overstated. A successful split demands the careful extraction of only the subsite’s relevant data. This includes its wp_X_ tables and, often, a subset of the wp_users and wp_usermeta tables if you intend to migrate specific users with the subsite. Furthermore, meticulous URL replacement is critical to prevent broken links and corrupted content after the migration.

Attempting this manually with raw SQL exports and basic find-and-replace operations is highly risky. WordPress stores a lot of data in a serialized format. This means simple text replacements can corrupt the data structure, leading to broken widgets, theme settings, and plugin configurations. This is where tools like WP Migrate become invaluable, as they are specifically designed to handle serialized data safely during migrations.

Pre-Migration Checklist: Essential Preparations

Thorough preparation is paramount for any migration. Skipping these steps can lead to data loss or significant headaches down the line.

1. Create a Full Backup of Your Entire Multisite Network

This is the single most crucial step. Before you touch anything, create a complete backup of your entire multisite network. This includes:

• All Database Tables: Both shared and subsite-specific.
• All Files: Your wp-content directory (themes, plugins, uploads), core WordPress files, and any custom files (e.g., .htaccess, wp-config.php).

For a full site backup, consider your hosting provider’s backup solutions or a dedicated backup plugin. This backup is your safety net, allowing you to revert if anything goes wrong.

2. Choose Your Destination Environment

Determine where your subsite will live as a single installation. This could be a new hosting provider and domain, a new domain on your existing hosting, or a local development environment like Local. It’s worth noting that Local integrates with WP Migrate.

Ensure your chosen destination meets the minimum WordPress requirements (PHP version, MySQL version, etc.).

3. Create a Fresh WordPress Single Site Installation

On your chosen destination, perform a completely fresh installation of WordPress. It’s critical that this is a clean install, without any existing content, themes, or plugins (other than the default ones). This provides a clean slate for your migrated subsite data.

4. Install WP Migrate Lite on Both Sites

To facilitate the migration, you’ll need WP Migrate Lite installed and activated on your source multisite network, and on the single-site destination.

Having WP Migrate Lite on both ends will enable the smooth export from the multisite and prepare the destination for the incoming data.

Step-by-Step Guide: Migrating a Subsite with WP Migrate Lite

Now that your preparation is complete, let’s dive into the core migration process using WP Migrate Lite.

Exporting the Subsite Database from the Multisite

The first critical step is to accurately export only the necessary database tables from your multisite network.

Access WP Migrate Lite

Log in to your multisite network’s WordPress admin area. Navigate to Settings > WP Migrate to go to the WP Migrate Lite dashboard.

Target the Subsite’s Database Tables

This is the most crucial part of a multisite split. You must select only the tables associated with the specific subsite you are migrating.

To identify your subsite’s unique ID, go to Sites > All Sites. Hover over the subsite you intend to migrate, and its ID will appear in the URL preview (for example, site-edit.php?id=X, where X is the ID).

Next, return to the WP Migrate interface. Click on the Migrate tab, and then click Export. Open the “Tables” dropdown, and click Export only selected tables below.

WP Migrate defaults to selecting all of the tables. It’s certainly possible to manually deselect all of the tables you don’t want to migrate, but it’s probably easier to just click Deselect All and then select only those tables that begin with wp_X_ (where X is your subsite’s ID). In other words, if your subsite ID is 2, you would select tables like wp_2_posts, wp_2_options, and wp_2_terms.

Additionally, you will typically need to include the main network’s wp_users and wp_usermeta tables if you intend to migrate the existing users of that subsite, and potentially other users, to the new single installation. If you plan to create new users on the destination and only need the subsite’s content, these tables can be omitted.

Perform Find & Replace for URLs

WP Migrate’s find and replace feature is vital for updating all instances of your old subsite URL to the new single site URL.

In the “Find” field, enter the full URL of your subsite on the Multisite network. This could be a subdirectory (e.g., https://your-main-domain.com/subsite-name/) or a subdomain (e.g., https://subsite.your-main-domain.com/). In the “Replace” field, enter the full URL of your new single site installation, such as https://new-subsite-domain.com/. WP Migrate automatically manages serialized data during this process, ensuring no data corruption occurs.

Configure Export Options

When configuring export options, the plugin will generate an SQL file by default. The “Advanced Options” section provides checkboxes to refine this SQL export. You may choose to Exclude spam comments and Exclude transients to help keep your new database cleaner and reduce its size. The “Compress file with gzip” option will create a smaller .gz archive of your SQL file. The “Replace GUIDs” box is checked by default. GUIDs are typically not changed on live sites, but in the specific case of splitting a subsite from a multisite to a new standalone installation, updating GUIDs is recommended. This ensures the new site’s content correctly references its new domain and maintains its independence from the old multisite structure.

Initiate Export

Finally, initiate the export by clicking Export. WP Migrate Lite will process the selected tables, generate an SQL file, and download it to your local machine. This file contains all the database content for your subsite, pre-processed with the new URLs.

Preparing and Importing into the New Single Site

With your subsite’s database exported, the next step is to prepare your new single WordPress installation and import the data.

Access New Site’s Database

Log into phpMyAdmin or your hosting provider’s equivalent database management tool for the new, fresh single WordPress installation. Ensure you are connected to the correct database associated with your new site.

Clear Existing Tables

This is a critical step. Before importing your subsite’s data, you must clear the existing tables in the new database. Proceed with extreme caution here, as this will permanently delete all data in the selected database. Select all tables in the new single site’s database (which are typically prefixed with wp_) and use the “Drop” or “Delete” function to remove them. This creates a clean slate for the incoming subsite data.

Import and Verify

The exact method you use to do this will depend on the tool you’re using and/or your host.

After the import is complete, briefly browse the tables in your new database. You should now see the subsite’s tables (which WP Migrate automatically re-prefixes to the standard wp_ during export) present, containing your subsite’s content.

Migrating Media Files, Themes, and Plugins

WP Migrate Lite gives you the option of exporting your media files, themes, plugin and WordPress core files from within the dashboard. However, in the specific case of splitting a site off of a multisite install, transferring your media files, themes, and plugins requires manual steps when using the Lite version. This approach ensures precise control over the subsite’s specific assets and avoids potential complexities that can arise when using the full site export functionality for a multisite split.

WP Migrate allows you to use .gitignore patterns to exclude specific files from a migration, however this won’t transform the file paths from a multisite structure to a single site structure during export.

For a multisite subsite, manually transferring ensures you correctly extract only the subsite’s media (from its unique wp-content/uploads/sites/X/ directory) and place it in the standard wp-content/uploads/ directory of the new single site. Similarly, while WP Migrate Lite allows for the selection of individual themes and plugins for export, ensuring their seamless integration and correct pathing after a subsite split is best achieved by installing fresh copies or manually placing them.

Media Files

Your subsite’s media files are stored in a specific location within the multisite’s wp-content/uploads/ directory. To transfer these, connect to your multisite network via FTP or SFTP.

Navigate to the wp-content/uploads/sites/X/ directory, where X represents your subsite’s unique ID. Download the entire contents of this sites/X/ folder to your local machine.

Once downloaded, connect to your new single site via FTP or SFTP. Upload the previously downloaded media files directly into the wp-content/uploads/ directory on the new site. The sites/X/ structure is no longer necessary in a standard single site installation.

Themes

First, identify the theme that was active on your subsite within the multisite network. The most reliable method for transferring this is to install a fresh copy of the same theme directly onto your new single site through the WordPress admin interface. If the theme is custom, you will need to download the theme folder from wp-content/themes/ on your multisite and then upload it to wp-content/themes/ on your new single site. After the theme is successfully transferred to your new site, activate it from the Appearance > Themes section of the WordPress admin.

Plugins

Begin by making a comprehensive list of all plugins that were active on your subsite in the multisite network. Similar to themes, the best practice is to install fresh copies of these plugins directly on your new single site. For any custom or premium plugins, download their respective folders from wp-content/plugins/ on your Multisite and then upload them to wp-content/plugins/ on your new single site. Once installed, activate the necessary plugins from the “Plugins” section of your new WordPress admin.

Post-Migration Steps

After the database and files are in place, a few final steps are necessary to ensure your new single site functions correctly.

Re-Save Permalinks

This is a crucial step to refresh WordPress’s rewrite rules. Log into the new single site’s WordPress admin, go to Settings > Permalinks, and click Save Changes. You don’t need to make any actual changes to the permalink structure, just saving it will regenerate the .htaccess file or the equivalent rules for Nginx.

Thorough Testing

Dedicate time to comprehensively test your newly migrated site. Browse all pages and posts to ensure content displays correctly. Check all internal links, images, and embedded media to confirm they point to the new domain. Test forms, comments, and any custom functionality specific to your subsite, and verify user logins and roles.

Delete Old Subsite

Once you are absolutely confident that your new single site is fully functional and stable, you can safely delete the original subsite from your Multisite network. This step should only be performed after extensive testing and confirmation that the migration was successful.

Streamline and Automate with WP Migrate

WP Migrate Lite gives you a good foundation for splitting a multisite subsite, but WP Migrate makes the entire process practically painless with time-saving features and powerful automation that are invaluable for professional developers and agencies. These premium advantages transform a multi-step manual process into a streamlined, often one-click, operation.

One-Click Subsite Push/Pull

This is arguably the most significant game-changer offered by WP Migrate Pro, specifically through its Multisite Tools. .

Instead of manually exporting a database, clearing tables, importing, and then separately transferring files via FTP, WP Migrate allows you to directly “push” a subsite from your network to a fresh single site installation. Conversely, you can also “pull” a single site into a subsite on your network.

This functionality automates the entire database and file transfer process between the two sites, eliminating the need for tedious manual FTP operations for media, themes, and plugins. It intelligently handles all the underlying complexities, including serialized data, making the migration incredibly efficient and less prone to human error.

Automated File Migration

Beyond the database, WP Migrate seamlessly handles the comprehensive transfer of all associated files. This means your media library, active themes, and installed plugins are migrated directly between your multisite and the new single installation. This automated file handling negates the need for manual downloading from wp-content/uploads/sites/X/ and re-uploading to the new site’s wp-content/uploads/ directory, saving substantial time and ensuring all assets are correctly linked and available on the new standalone site.

WP-CLI Integration for Scripting

For developers who manage numerous migrations or integrate them into their deployment workflows, WP Migrate’s WP-CLI integration is a powerful asset. This allows you to execute and automate the entire migration process from the command line. You can script complex migration routines, making it incredibly efficient for repetitive tasks, continuous integration, or managing large-scale deployments without needing to interact with the WordPress admin interface.

Granular Control and Targeted Migrations

WP Migrate offers even finer control over your migrations. While WP Migrate Lite allows table selection, the premium version provides more advanced options for precisely including or excluding specific database tables and even particular post types. This granular control is especially useful for complex scenarios where you only need to migrate a subset of data, ensuring your new single site is as lean and optimized as possible from the outset.

Wrapping Up

Splitting a subsite from a multisite network is more straightforward with the right tools. WP Migrate Lite provides the essential functionality for database export, intelligent URL replacement, and manual file transfer.

For professional developers and agencies, the premium version, WP Migrate, offers much greater automation and efficiency. Its one-click push/pull capabilities, automated file migration, WP-CLI integration, and granular control over data ensure that even the most challenging multisite splits become seamless operations.

Have you split off part of a multisite into a single-site installation? How did it go, and which tools did you use? Let us know in the comments!

The post Splitting a WordPress Multisite: Migrating a Subsite to its Own Single Installation appeared first on Delicious Brains.

Visual Studio Code is a free, open source code editor that is lightweight like Sublime Text, but offers many of the same features as bigger IDEs like PhpStorm or WebStorm.

In this article, I’ll review some features of VS Code that I love, and show you how to make the most out of it for WordPress dev.

Basic Setup for WordPress Development

Most of the time when coding in WordPress, you’re working on a plugin or a theme. One way to do this might be to open that plugin or theme in your IDE and start coding away. There is a better way though, with the help of VS Code “Workspaces”.

You can think of a Workspace in VS Code as a container for your project – it not only includes your project, but it can include files that your project relies on (your WordPress installation), and any extensions or settings specific to that project.

I like Workspaces because you can create one of them for each project and change any setting or extension in VS Code at the Workspace level. For example, you may not want to use the WordPress Coding Standards on all of your projects, or maybe you work with a team of developers that can’t agree on tabs vs. spaces.

In my case, the vast majority of my time is spent on plugin development. So I’ll have a Projects folder that has all of the plugins I work on, and a Sites folder that contains all of my sites. I’ll then symlink the plugin I’m working on into a fresh WordPress website in the Sites folder.

In Visual Studio Code, I’ll first open the plugin itself, and then I’ll add the WordPress site by selecting File -> Add Folder to Workspace. That sets up a new Workspace where I can edit the plugin and the WordPress installation at the same time.

This is handy for quick edits to the wp-config.php file, and keeping an eye on the debug.log file while I’m developing.

Next, click File -> Save Workspace As to save that Workspace. This creates a *.code-workspace file (JSON-based) that stores path folders and settings. This allows you to open your Workspace again in the future, and also serves as a config file that will come in handy later. If you’re collaborating, you can version-control this file—just ensure paths like /Sites/my-site aren’t machine-specific.

Deeper PHP and WordPress Integration

With that out of the way, let’s take a look at how we can make Visual Studio Code and WordPress play a bit nicer. Out-of-the-box, VS Code doesn’t support WordPress and PHP as well as some other IDEs like PhpStorm (Find out how some of our team uses PhpStorm for WordPress Development). Luckily, that’s easy to change by installing some extensions.

Since WordPress is still mostly PHP, I use the PHP Intelephense extension, which adds PHP auto-completions, symbol navigation support, and a much better way to find references in your workspace.

While that will add auto-completions for PHP core functions and anything that you have defined in your project, it won’t pick up on much from WordPress core. For that, there is the Hooks IntelliSense for WordPress extension. It autocompletes WordPress hooks (actions/filters) and their priority parameters. There’s also PHP Tools for Visual Studio Code, which provides advanced IntelliSense for WordPress core functions, classes, and constants. It even resolves argument orders for functions like get_posts(), so you spend less time checking the Codex.

To enforce WordPress best practices, use the WordPress Coding Standards with the PHP Sniffer extension. This combination highlights issues like missing sanitization or incorrect file naming in real time. Just install phpcs globally and configure the extension to use the WordPress standard in your workspace settings.

These tools make it much easier to work with WordPress plugins and themes, and PHP development in general.

Debugging PHP

Xdebug is an invaluable tool to have for debugging PHP, but it can be tricky to set up. Luckily, VS Code makes it easy to configure Xdebug, and in my case it just works.

You only need to install the PHP Debug extension and reload the editor. You can then go to the “Run” tab and click “create a launch.json file” to create a new PHP debug configuration.

You should then see a pop-up towards the top of your editor asking you to select a Workspace folder to create the configuration in:

Select “workspace” to insert the new configuration into your *.code-workspace file, and then “PHP” to add a PHP configuration. This will add some debug config to that file, including the new “Listen for XDebug” option. You can edit the name of the configuration or change the XDebug port here. Here’s how to adjust the config based on a common MAMP setup:

{
    "name": "Listen for XDebug",
    "type": "php",
    "request": "launch",
    "port": 9003, // Xdebug v3+ uses 9003!
    "pathMappings": {
        // Docker example:
        "/var/www/html": "${workspaceFolder}/wp",
        // Local example (MAMP/XAMPP):
        "/Applications/MAMP/htdocs/mysite": "${workspaceFolder}"
    },
    "log": true // Enable logging for troubleshooting
}

In my case, it also added a “Launch currently open script” config as well. With WordPress, we rarely need to load a PHP file directly, so I just deleted that config.

That’s it! You should be able to start debugging PHP from here. Head over to a PHP file in your WordPress plugin or theme, and click to the left to a line number to add a breakpoint to that line.

When you head back over to the “Run” tab, select “Listen for XDebug” from the dropdown and click the play icon to start listening for requests. For breakpoints to work, append ?XDEBUG_SESSION=VSCODE to your site’s URL, or add a browser extension. When your code hits that breakpoint, the runtime should pause and you can see all variables, the call stack, and more. Who knew debugging WordPress in Visual Studio Code could be so easy?

XDebug Ghosting You? Enable Logs

When your breakpoints mysteriously don’t trigger—even though everything seems right—you can add these lines to your php.ini to enable logs:

[xdebug]  
xdebug.log = /tmp/xdebug.log  # Simple path that’s always writable  
xdebug.log_level = 1  # 1=errors, 3=trace (verbose)  

When to Check the Logs:

• Breakpoints ignored (even with ?XDEBUG_SESSION=VSCODE).
• VS Code’s debugger says “Connected” but never pauses.
• You’re muttering “Why isn’t this working?!” at your screen.

What to Look For:

• “Could not connect to client”: Firewall blocking port 9003? Try changing the port that xDebug listens on or check your local firewall settings..
• “File is not mapped”: Fix pathMappings in launch.json (e.g., /var/www/html → ${workspaceFolder}).
• “Invalid session”: Do you have the Xdebug browser extension enabled or are you forgetting to add ?XDEBUG_SESSION=VSCODE to your URL?

Debugging JavaScript

Debugging PHP is only half the problem – we also need to be able todebug JavaScript. Thankfully, modern VS Code has robust tools for this built right in. VS Code’s JavaScript Debugger is bundled with VS Code by default and supports Chrome, Edge, Node.js, and more. No extensions needed!

Next, you’ll need to edit the *.code-workspace file to add a JS debug config. :

{
    "name": "Listen for JS",
    "type": "chrome",
    "request": "launch",
    "url": "http://yoursite.test",
    "webRoot": "/path/to/your/site/root",
}

The type here refers to VS Code’s built-in JavaScript Debugger, which supports Chromium-based browsers. If you prefer Firefox, you can use Mozilla’s Firefox Debugger extension and update the type to "firefox".

Once that’s been added, you should see the Listen for JS option in the debug drop down:

For reference, here’s my entire mdb.code-workspace file so far:

{
"folders": [
    {
    "path": "wp-migrate-db-pro"
    },
    {
    "path": "/Users/mattshaw/Sites/mdb/app/public"
    }
],
"launch": {
    "version": "0.2.0",
    "configurations": [
    {
        "type": "chrome",
        "request": "launch",
        "name": "Listen for JS",
        "url": "http://mdb.test",
        "webRoot": "/Users/mattshaw/Sites/mdb/app/public"
    },
    {
        "name": "Listen for XDebug",
        "type": "php",
        "request": "launch",
        "port": 9003
        "pathMappings": {
          "/var/www/html": "${workspaceFolder}/wp"  
        }       
      }
    ]
  }
}

The pathMappings are essential if you’re using Docker or developing remotely. If you’re working locally, you only need them if your server’s file paths differ from your local workspace.

Gotchas

If you’re using something like Webpack to bundle your JS files together, you may notice that your breakpoints aren’t working. Modern tools generate source maps automatically, but if yours aren’t lining up, you should double-check your webpack.config.js for devtool: 'source-map'. Also, in VS Code’s debug config, ensure webRoot matches your server’s document root.

With that in place, it’s now easy to debug JS from within VS Code, using the same UI that is used for Xdebug:

Other Tips

I’ve come across some other important extensions that have been helpful in day-to-day development. The GitLens extension adds simple git blame annotations to the line that you’re currently working on. And now it even integrates with GitHub for pull request insights!

The PHP DocBlocker extension is super helpful for, well, docblocking. Simply type /** above a function, method, or class and it will autocomplete the docblock based on the function/method parameters.

The Prettier extension is great for cleaning up your CSS, JS, and HTML code on editor save.

VS Code’s built-in Markdown preview (no extension needed!) works great for writing docs or blog posts. And if you’re using modern JavaScript, the native syntax highlighting covers ES6+—no plugin required.

Closing Thoughts

After using it for years, I still love VS Code. It’s like it took my favorite features of PhpStorm and Sublime Text, and combined them to create the perfect IDE. I also really like the way that you can install extensions directly from within VS Code, and view the docs for that extension without leaving the editor.

Have you tried out VS Code? What did you think? Let us know in the comments.

The post Set Up Visual Studio Code and xDebug as the Ultimate Editor for WordPress Development appeared first on Delicious Brains.