Staging to Live Migration

This document explains how to migrate the ADP Car Market Hub plugin configuration from a staging WordPress site to a production (live) site. It covers which settings must be updated, which transient data must be cleared, how to reconfigure scheduled imports and cron jobs, and how to validate the live site before enabling automated imports.

When to use this document

Use this document if you are:

• Promoting a fully configured and tested staging environment to the production domain for the first time.
• Copying a production database to staging and need to know what to change on staging so it does not interfere with the live site.
• Performing a server migration or domain change on a site that is already running the plugin in production.
• Coordinating the promotion of configuration changes (design, settings, mapping overrides) that were developed on staging.

The audience is a WordPress administrator or agency developer who understands how WordPress databases and file systems are moved between environments. Working knowledge of wp-config.php and either SSH or a hosting control panel is helpful.

Overview

The plugin stores all of its configuration as WordPress options in the database (wp_options table) and stores imported vehicle posts, leads, analytics events, and search alert subscriptions in separate tables and post types. When a database is moved between environments — for example, by copying the staging database to production — all of that data moves with it.

A copied database retains values that are correct for the source environment but wrong or unsafe for the destination environment. The most important examples are:

• API credentials (Base URL, Seller IDs, Client ID, Client Secret). On staging you may be using a sandbox API environment or lower-security test credentials. The live site needs the dealer's actual production credentials.
• The cron token. The token that authenticates the plugin's REST cron endpoint is environment-specific. Using the staging token on the live site, or vice versa, means the server cron job is calling the wrong URL or using the wrong secret.
• Webhook target URLs. Staging webhooks often point at test receivers. Live webhooks must point at the production CRM or notification endpoint.
• The WordPress site URL. WordPress stores its own URL in the siteurl and home options. These must match the live domain before the plugin's REST endpoint URLs and any other absolute URLs resolve correctly.
• Transient cache data. Cached OAuth access tokens, import run-locks, and the image queue contain staging state that is meaningless or harmful on the live site.
• Scheduled cron events. WP-Cron events that were scheduled on staging carry staging-relative timestamps and must be rescheduled on the live site.

Each of these is addressed step by step below.

Prerequisites

Before beginning the migration:

• A current, restorable backup of both the staging database and the production database exists. Never migrate without a backup of the current state of each site.
• The production WordPress installation meets the plugin's requirements. See Technical System Requirements.
• You have access to the production server's wp-config.php file and to the server's cron facility if server cron is used.
• You know the production API credentials (API Base URL, Seller IDs, Client ID, Client Secret) and have received them through a secure channel. See External API Credentials.
• If the production site uses a different domain than staging, the domain change is ready to apply to the WordPress URL options at the same time as the database copy.

Step by step instructions

Work through these steps in order. Steps 1 through 5 are preparation on staging before the database is copied. Steps 6 onwards apply to the production site after the database or plugin is in place.

Step 1 — Disable automated imports on staging before the migration

If the staging site has automated imports enabled, disable them before copying the database. This prevents a situation where both environments share the same scheduling state and both attempt to run imports at the same time.

1. On the staging site, open Car Market Hub → Import & Limits.
2. Disable the Automatic import toggle and save.
3. If a server cron job points at the staging site's REST endpoint, disable or remove that cron job as well.

Step 2 — Take backups

Before making any changes to either site:

1. Take a database backup of the staging site.
2. Take a database backup of the production site.
3. If the production site already has imported vehicle data and uploaded images, take a full file-system backup of wp-content/uploads/ as well.

Step 3 — Copy the database

Copy the staging database to the production server using your preferred method (hosting control panel export/import, WP-CLI db export / db import, SSH + mysqldump, or a plugin such as Duplicator or All-in-One WP Migration). The exact procedure depends on your hosting environment.

If the domains differ between staging and production, run a search-and-replace to update all occurrences of the staging URL to the production URL. Using WP-CLI:

wp search-replace 'https://staging.example.com' 'https://www.example.com' --all-tables

Run this command against the production database, not the staging database. Take a backup before running it.

Step 4 — Copy the plugin files

The plugin files are in wp-content/plugins/adp-car-market-hub/. If the staging and production sites run the same version of the plugin, this step can be skipped. If the versions differ, copy the plugin directory from staging to production (or update to the same version via the WordPress admin on both sites before migrating).

Do not copy wp-config.php from staging to production. The two wp-config.php files contain different database credentials and environment-specific constants, and they must remain independent.

Step 5 — Copy theme overrides if applicable

If the theme on the staging site contains template override files for the plugin (for example single-as24ci_car.php or archive-as24ci_car.php in the theme root), copy those files to the same location in the production theme. See Template Override Guide for details on template overrides.

If no template overrides exist in the theme, skip this step.

Step 6 — Update the production API credentials

After the database copy, the production wp_options table still contains whatever credentials were saved on staging. Replace them with production credentials.

1. On the production site, open Car Market Hub → Settings.
2. In the API Connection & General Settings card, enter the production values for: - API Base URL — the HTTPS URL of the production AutoScout24 environment. - Seller ID — the dealer's production Seller ID(s). Multiple IDs are comma-separated. - Client ID — the production OAuth client identifier. - Client Secret — the production OAuth client secret. The Client Secret field is not pre-filled when the settings page is opened; you must always re-enter the value when changing it.
3. Save the settings.
4. Clear the cached OAuth access token if one exists from the staging session. The token is stored as the WordPress transient as24ci_access_token. You can clear it from Car Market Hub → Tools (look for a Clear token cache action), or by running: `` wp transient delete as24ci_access_token ``
5. Run the Connection Test on Car Market Hub → Tools. Do not proceed until the test passes. See Connection Test.

Step 7 — Update the webhook URLs

If webhooks are configured, the staging configuration may point at a test receiver:

1. Open Car Market Hub → Leads and locate the Webhooks section.
2. Update the New lead webhook URL and the New import webhook URL to the production receiver endpoints, or clear them if webhooks are not used in production.
3. Update the Webhook secret if the production receiver uses a different secret value. See Webhook Integration.

Step 8 — Confirm the managed AI configuration

If the AI assistant is enabled:

1. Confirm with AD Promotion that the managed Google Gemini configuration in AS24CI\Ai_Config is provisioned for the production environment. The customer does not enter an AI provider, model or API key in the WordPress backend, and no AI key is migrated through the database copy.
2. Visit Car Market Hub → AI Assistant and confirm the feature reports as configured.

Step 9 — Clear stale transient data

The migrated database may contain transient values from the staging environment that must not carry over to production:

1. Clear the import run-lock, if set. This prevents the production site from seeing a stale "import already in progress" state from a staging run: `` wp transient delete as24ci_cron_import_running ``
2. Clear the image queue worker lock, if set: `` wp transient delete as24ci_image_queue_running ``
3. Optionally clear the image queue itself if the staging image queue contains staging-environment image jobs. The image queue is stored as a WordPress option (as24ci_image_queue) rather than a transient. You can clear it from Car Market Hub → System & Help → Clear image queue, or from the command line: `` wp option delete as24ci_image_queue wp option delete as24ci_image_queue_last_run ``
4. Remove any other cached AI model lists from previous staging API calls. These are stored as transients with the prefix as24ci_. On WP-CLI you can inspect them with wp transient list --search="as24ci_".

Step 10 — Regenerate the cron token

The cron token from staging must not be used in production. A different token prevents staging cron jobs from accidentally triggering production imports.

1. On the production site, open Car Market Hub → Import & Limits.
2. In the Automation card, click Regenerate Token. The plugin generates a new random 32-character token and saves it.
3. Note the new token; you will need it in step 11.

If you use the REST endpoint with the token in the URL, the new trigger URL is shown on the same card. The old URL will return a 403 error after regeneration.

Step 11 — Reconfigure the production cron setup

After the token regeneration, any server cron job that pointed at the staging URL is invalid. Reconfigure the production cron setup:

1. If using server cron mode, update the server cron job(s) with the new production trigger URL. See Server Cron Setup for the exact command format.
2. If using WP-Cron mode, confirm that the DISABLE_WP_CRON constant in wp-config.php is set appropriately: - If the production site uses server cron, add or confirm define( 'DISABLE_WP_CRON', true ); in wp-config.php. - If the production site relies on WP-Cron, remove or comment out DISABLE_WP_CRON from wp-config.php if it was set for staging.
3. Re-enable automated imports on Car Market Hub → Import & Limits once all credentials and cron setup have been validated.

Step 12 — Check default pages

When the plugin is first activated, it creates two WordPress pages (Cars / vehicle archive and Compare Cars) and stores their post IDs in the options as24ci_page_archive_id and as24ci_page_compare_id. If the production database was previously empty, the migrated page IDs are those created on staging and refer to staging posts. After the database copy, those pages exist on the production site, but their slugs and content should be verified.

1. In WordPress → Pages, confirm that the vehicle archive page (default slug: cars) and the Compare Cars page exist and are published.
2. Visit both pages on the front end and confirm they render correctly.
3. If the pages are missing or their IDs point to deleted posts, deactivate and reactivate the plugin to re-create them (confirm that Create default pages is enabled in Car Market Hub → Settings before reactivation).

Verify this behaviour in the current plugin version before relying on it, as page creation behaviour may vary.

Step 13 — Flush permalink rules

After any domain change or WordPress URL update, flush the WordPress permalink rules so that the vehicle archive URL and vehicle detail page URLs resolve correctly:

1. In WordPress, open Settings → Permalinks.
2. Without changing anything, click Save Changes. This regenerates the .htaccess rewrite rules.
3. Visit the vehicle archive page and a single vehicle page to confirm they load without 404 errors.

Step 14 — Validate the production site

Run through the following validation checks after the migration:

1. Connection Test. Open Car Market Hub → Tools and run the Connection Test. Confirm it succeeds against the production API. See Connection Test.
2. System & Help tab. Open Car Market Hub → System & Help and review all diagnostic indicators. Resolve any red or amber badges.
3. Manual import. Trigger a manual import from Car Market Hub → Import & Limits → Run now. Confirm the import completes without errors.
4. Vehicle archive page. Visit the vehicle archive URL and confirm imported vehicles appear with correct images, prices, and labels.
5. Single vehicle page. Click through to a vehicle detail page and confirm the full detail layout, gallery, and contact form are functional.
6. First scheduled import. After enabling the automated schedule, wait for the first cron-triggered run and confirm the System & Help tab shows a recent Last import run timestamp.
7. Logs. Open Car Market Hub → Logs and confirm there are no authentication errors, API failures, or other unexpected errors from the first production run.

Configuration reference

The following plugin option groups are relevant when migrating between environments. All are stored as WordPress options.

Operational notes

• One active environment at a time. After promoting staging to live, disable automated imports and any server cron jobs on the staging site. Having both environments connected to the same production API credentials and running imports simultaneously can cause unpredictable results. Use separate API credentials per environment where possible.
• Staging must use its own credentials. After the database is copied to staging, replace the API credentials on staging with sandbox or staging-environment values. Do not leave production credentials on a staging site. See External API Credentials.
• Full Sync caution. The Full Sync option deletes local vehicle posts that are no longer present in the API response. Do not enable Full Sync on the live site until at least one complete import cycle has been observed and confirmed correct. Enabling it before the first clean import can cause premature deletions.
• Analytics and lead data. The migration copies any analytics events and lead posts from staging to production. These are synthetic or test records and may distort reporting. Depending on the dealer's requirements, you may want to remove staging-generated analytics from the production database before enabling real traffic. The analytics data is stored in the {prefix}as24ci_analytics database table. Verify before purging.
• Search alert subscriptions. The plugin's search alert subscriptions (visitor name, email, search criteria) are stored in the {prefix}as24ci_search_agents table. Staging test subscriptions should be removed from the production database. These are personal data records and must not be retained without a legitimate purpose.
• Permalink structure. The vehicle archive URL (default slug cars) and single vehicle URLs (/cars/{slug}/) depend on pretty permalinks being enabled. Confirm after migration that Settings → Permalinks is not set to plain (query-string) mode.
• wp-config.php is not migrated. Keep wp-config.php files independent between environments. The database credentials, DISABLE_WP_CRON, WP_DEBUG, and other environment constants must reflect the target environment's configuration.
• Log directory. The plugin writes import and error logs to wp-content/uploads/as24ci-logs/. Staging log files will be in that directory after a full file-system migration. The log data is not harmful on production but may be confusing. You can rotate or archive staging log files before enabling production imports if a clean starting state is preferred.
• Cache invalidation. After a domain change and database migration, clear all WordPress object caches, page caches, CDN caches, and PHP opcode caches so that the new URLs and fresh plugin options are served consistently.

Troubleshooting

Related documents

• External API Credentials
• AutoScout24 API Setup
• Server Cron Setup
• Webhook Integration
• Template Override Guide
• Connection Test
• Go Live Checklist
• Backup and Restore
• Data Storage Overview
• API Connection Errors