---
tags:
  - wordpress
  - migration
  - xml
  - debugging
  - fse
  - database
title: WordPress Data Merging: Manual Reconstruction & ID Management
---

# WordPress Data Merging: Manual Reconstruction & ID Management

Sometimes a full database migration (cloning) isn't possible or desirable. You might be merging two sites, moving to a host with strict timeout limits, or trying to leave behind years of database bloat ("table debris").

This process involves manually moving assets and using WordPress's **Export/Import** tools to reconstruct the site. While cleaner, it introduces specific challenges regarding **Post IDs** and **Media Paths**.

## Phase 1: The Physical Move (FTP/SFTP)

Before importing content, you must manually place the physical assets. This bypasses hosting timeout limits often hit by migration plugins.

1.  **Themes & Plugins:**
    *   Download `wp-content/themes/` and `wp-content/plugins/` from the old site.
    *   Upload them to the new site via SFTP.
    *   **Activate** the theme and necessary plugins on the new site *before* importing content. This ensures Custom Post Types (CPTs) exist to receive the data.

2.  **Media Library (The "Uploads" Folder):**
    *   Download the entire `wp-content/uploads/` folder.
    *   Upload it to the new site.
    *   *Note:* At this stage, the files exist on the server, but the new WordPress database **does not know they exist**.

## Phase 2: Content Import (XML)

Use the native WordPress Exporter/Importer.

1.  **Old Site:** Go to **Tools > Export**. Select "All Content" or specific post types. Download the `.xml` file.
2.  **New Site:** Go to **Tools > Import > WordPress**.
3.  **The Attachment Step:**
    *   The importer will ask to "Download and import file attachments".
    *   **If the old site is live:** Check this. WP will try to fetch images via HTTP.
    *   **If the old site is local/offline:** Uncheck this. We will link the manually uploaded files later.

## Phase 3: The Media Path & Database Reconnection

If the XML import failed to download images (common due to timeouts) or if you unchecked the box, your posts will have broken image links, and your Media Library will be empty despite the files being on the server.

### 1. Registering the Files
You need to scan the `uploads` folder and add entries to the `wp_posts` table.
*   **Tool:** Use a plugin like **Media Sync** or **Add From Server**.
*   **Action:** Scan the directory and import the files into the library.

### 2. Fixing Paths (Date Structure Mismatch)
If the old site used `/2023/01/image.jpg` but your new import registered them in `/2024/03/` (current date), or if you flattened the structure:
*   **Diagnosis:** Inspect a broken image on the frontend. Compare the URL it is trying to load vs. the actual URL in the Media Library.
*   **Fix:** Use **Better Search Replace** to update the paths.
    *   Search: `wp-content/uploads/2023/01/`
    *   Replace: `wp-content/uploads/2024/03/` (or wherever they landed).

## Phase 4: The ID Mismatch Nightmare

**This is the most critical issue in manual merging.**

When you import XML, WordPress assigns **new IDs** to posts, pages, and media if the original IDs are already taken.

### 1. Broken Shortcodes
Many plugins store references by ID, not slug.
*   **Example:** `[contact-form-7 id="54"]` or `[gallery ids="10,12,15"]`.
*   **The Issue:** On the new site, Form 54 might now be Form 102. The shortcode will render nothing.
*   **The Fix:** You must manually map the old IDs to new IDs and run a Search/Replace, or manually update the shortcodes in the content.

### 2. Full Site Editing (FSE) & Block Errors
Modern Block Themes (FSE) store templates and parts in the database. If a template part references a specific menu or image ID that changed, the editor may crash.

**Symptoms:**
*   "This block has encountered an error and cannot be previewed."
*   White screen when loading the Site Editor.

## Phase 5: Debugging Crashes (WP_DEBUG)

If the FSE editor or frontend crashes after a merge, you need to see the specific error to identify which ID or block is responsible.

1.  **Enable Debugging:**
    Open `wp-config.php` and add:
    ```php
    define( 'WP_DEBUG', true );
    define( 'WP_DEBUG_LOG', true );
    define( 'WP_DEBUG_DISPLAY', false );
    ```

2.  **Check the Log:**
    Open `wp-content/debug.log`. Look for errors like:
    *   `Call to a member function get_id() on null` (Implies a post ID referenced in code/theme doesn't exist).
    *   `Undefined array key "123"` (Implies a missing widget or menu ID).

3.  **Fixing Invalid Block Markup:**
    If the Block Editor complains about "Attempt Block Recovery":
    *   Open the Code Editor view (three dots > Code Editor).
    *   Look for JSON blobs inside HTML comments `<!-- wp:plugin/block {"id": 123} -->`.
    *   Update the ID to match the new object ID.

## Phase 6: Final Cleanup Checklist

1.  **Menus:** Go to **Appearance > Menus**. You often need to re-assign the menu locations (Primary, Footer) because the theme's location mapping gets lost during XML import.
2.  **Widgets:** If using Classic Widgets, they often do not import via XML. You may need the "Widget Importer & Exporter" plugin (`.wie` files).
3.  **Permalinks:** Go to **Settings > Permalinks** and click Save to flush rewrite rules.
4.  **Domain Replacement:** Run a final Search & Replace for the old domain if you were merging from a staging URL.

## Related Guides
*   [[wordpress-migration-process|The Ultimate WordPress Migration Guide (Full Clone)]]
*   [[../linux/Ubuntu-WordPress-Migration-Troubleshooting|Troubleshooting WordPress Migrations]]
```