When to run this troubleshooting?

You can run this troubleshooting right after you have migrated a new site. And then you encounter any of the following issues:

  • Images are not showing up after migration.
  • Some critical error/fatal errors have occurred.
  • Styling issues.
  • Any visual/plugin/theme related glitches not found on the original site.

Go to each troubleshooting steps as long as it applies to your case.

Step 1: Does your source site have these problems too?

First thing to check is if these issues were already present before the migration (e.g. in your source site). For example – if you have missing images after migration. Check first if the source site has that image there. If the image is already missing at the source site – then Prime Mover will simply clone that site and the target site does not have that image too 🙂

The same with all the issues you’ve seen (plugin setting issues, errors, visual/styling glitches, etc) – please check first with the source site to make sure they don’t have these issues as well.

If these issues are also found at the source site – please fix the issues there first. Once all fixed, create another export for migration. It is recommended to fully check your source site before you migrate it to make sure all things are OK.

Step 2: Are you using latest Prime Mover plugin version?

Latest Prime Mover version includes latest bug fixes related to migration issues. If you are using outdated version – please upgrade to latest version and use this to create the export and restore. This is to rule-out any possible migration-related issues inside Prime Mover that is already fixed with the latest version.

Step 3: Re-save permalinks at target site

Login as administrator/super-administrator. In the migrated site – go to Settings -> Permalinks. Without changing the settings – just click “Save changes“.

Step 4: If using caching plugin – please purge at target site

Are you using a caching plugin? Please purge all the cache after migration. Please refer to the documentation of your caching plugin on how clear and purge the cache.

If you are in a hosting company with built-in cache – please read your hosting documentation on how to clear the default/built-in cache. This is typically done in the hosting dashboard or panel. When in doubt – consult your hosting support.

Step 5: If using JS/CSS/Font asset management plugin – please clear cache at target site

If you are using any JS/CSS/Font asset management solution (e.g. Autoptimize plugin, etc. ) to manage your resources, custom styling ,etc. please check that they have caching feature. If that is the case – they are rendering outdated resources that needs to be cleared after migration.

Step 6: If using CDN – refresh it at target site

If your site is using CDN solution to render images, JS/ CSS then refresh it to make sure the resources are updated. You can also temporarily disable it for troubleshooting purposes just in case you still don’t see the images. This is to make sure that WordPress renders the images from the uploads directory and not from CDN.

Step 7: If your site uses a page builder plugin – clear it’s cache

Most page builder plugins have their own caching mechanisms. They store their image in their own cache directory which could be outdated if you are migrating the site. Purging this cache helps clear out the resources. The purging process depends on what page builder plugin you are using. Example of page builder plugins with their own cache clearing solutions:

Elementor: Re-generate CSS

Beaver builder: Clear cache

If you are using different page builder plugin – please consult your plugin documentation for details.

Step 8: Check if your asset is stored outside uploads or WordPress directory in source site

Prime Mover can only migrate assets (images, etc) if they are stored in the WordPress uploads directory. It cannot migrate assets if they are stored outside the WordPress directory or any custom paths. If the image is missing because you are storing it in unusual location in the source site – then you need to manually move the folder to your target site for the images to appear.

Please check the complete list of files and resources that is currently migrated by Prime Mover.

Step 9: If you are getting fatal errors from a specific plugin at target site

This is usually caused by migrating incompatible plugins. For example – a multisite-only plugin is included in your migration and you are migrating to WordPress single-site. Or the other way around – you are migrating a plugin that is not compatible to a multisite from a single-site. Leaving these incompatible plugins deactivated in your site is the only solution.

Other several reasons of getting fatal errors from the plugin after migration includes:

  • Migrating a plugin to incompatible server. For example your plugin is not compatible with Microsoft IIS server. Make sure your plugin only runs in a compatible server. Ideally source and target site server should be the same or compatible to ensure your plugin compatibility before and after migration.
  • Migrating a plugin that is not allowed in your target hosts (e.g. plugins that is too resource-intensive that is blocked by your shared host)
  • Migrating a plugin that is resource intensive – requiring a lot of memory (in this case try increasing memory limit to see if it helps. This is usually happens if you migrate to a low-spec host with limited RAM/resources.
  • Incompatible PHP versions. For example – If your source site is PHP 5.6 and you are migrating to PHP 8.0. The plugin is not tested to work with PHP 8.0 resulting to fatal errors. You can downgrade PHP version in this case or contact the plugin author to report this issue.
  • Incompatible database versions – your plugins might require specific MySQL versions. So if its designed to work only with older MySQL versions but you migrate to new server with MySQL 8.0 – you will get errors.

To rule out all possible plugin glitches is to try the following:

  • Deactivate problematic plugins. If you cannot access your WordPress admin – deactivate it via FTP.
  • Re-activate the plugin and move to next step.

Step 10: Re-save your plugin settings at target site

Login to your migrated WordPress site and go to each plugin settings. Re-check if the settings are correct and re-save it. Re-saving settings help things clear up and reflect to it’s latest state.

Take note that if you are using plugins with authorization keys, licenses, etc. – you will need to re-save and re-register them after migration to make sure these plugins fully work like in the source site. As some plugins might disable these features because they require licenses,etc. And they disable these paid features after detecting a change of URL/domain (usually during a migration).

Step 11: Re-save your theme settings at target site

If your site is using a theme with custom theme options – try re-saving it to clear out any styling issues. This is usually the case when your theme has custom cache folder that is rendering outdated resources.

Step 12: Does your site depends on some custom wp-config.php constants?

Check your source site wp-config.php and see if there are some custom constants there (added by your plugins/themes) that is needed by your target site. Manually migrate these constants as Prime Mover does not migrate the source site wp-config.php (because they are site-specific).

Step 13: Is your target site server wrongly configured?

Please also check that your site server is correctly configured. Otherwise it can also cause your assets / JS/ CSS and images to stop displaying properly. For example if you are in a multisite instance using Nginx – try refreshing the Nginx site settings.

Quickest way to tell if your server has some issues in a multisite environment:

  • Temporarily deactivate Prime Mover plugin.
  • If you are in a multisite – try creating a new blank subsite (Network -> Add New Site).
  • Once the site is created – please check the site front end and back end.
  • If the newly created sub-site front end are still not displaying properly even with the default theme then the multisite has some wrong / incorrect configuration. You should review settings or refresh your server settings to make sure it’s working properly. You might need to contact your web hosting technical support in this case.

Quickest way to tell if your server has some issues in single-site environment:

  • Try installing a new – fresh WordPress single-site instance in a subdirectory / folder of your WordPress single site.
  • For example if your target site (where you have installed and restored package) is www.mytest.local then you need to create a new test site at www.mytest.local/my-temp-testsite
  • Once you have done installing the WordPress at the temporary subdirectory location – open it up in the browser.
  • The test site: www.mytest.local/my-temp-testsite , should display correctly in it’s default state and no missing images, etc.
  • If you see any image / CSS / JS glitch even with fresh install – then your server has some issues. Please double check with your web hosting support to fix this.

Step 14 – Do administrator on the multisite subsite not being able to access admin dashboard?

This only applies to multisite and if you have “Ultimate Member” plugin activated.

  • Login as network administrator.
  • Go to Network -> Plugins.
  • Network Deactivate “Ultimate Member” temporarily.
  • Refresh plugin page.
  • Network Activate “Ultimate Member” again.
  • Refresh plugin page.
  • Go to Network -> Sites.
  • Find the sites having issues and go to Admin dashboard by clicking “Dashboard” link.
  • Now you are in the subsite administrator dashboard, go to Users.
  • Find the user having administrator login issue and click “Edit”.
  • Once the “Edit User” page is loaded, don’t change anything -> Simply click “Update User”.
  • That’s it. The user should now be able to login as administrator and should now be able to access the admin dashboard pages.
  • Repeat the above steps for any affected users until all are refreshed.

How to debug missing images or assets (fonts, css, js ,etc) at source site ?

  • Visit the old site (source site) and check if the image, css, js is rendered there.
  • If the image is there – get the image URL so you will know how it’s being rendered, e.g. https://dummy.tld/wp-content/uploads/2022/02/test.jpg

Knowing your source image URL is important so we will know how it’s being rendered. This information can be used to troubleshoot easily at target site.

  • Clear your browser cache and load your migrated/target site.
  • At the target site, go to the page with missing images.
  • Using browser console – analyze and get the 404 URL (you should be able to get to the image URL if its 404 since console will report it).
  • Now you have this URL – check that asset is physically present in your target server. For example – check if the image is really present in your WordPress uploads directory or CDN.
  • If the image is not physically present but present in the source site – manually copy the image to your target site to see if it’s rendered.
  • If the image URL is pointing to the cache directory at target site but image is in uploads directory – try clearing your site cache (you should already done this in previous troubleshooting steps). You can temporarily disable the caching plugin to see if its really rendered.
  • If the image URL is pointing to a CDN resource – invalidate the CDN resource to see if the image is rendered. Temporarily disable CDN to see if the image is rendered.
  • If the image is still pointing to your old site – it is possible they are cached by either a page builder plugin. Try clearing them. If its only very few – it’s probably missed by default search/replace feature due to some data glitches. You can manually do search and replace again to point to correct URL.

Why my images/resources still missing after all the troubleshooting?

There are some page builders that store image URL’s or any assets in base64 encoded data. For example instead of this background image code (where URL is clearly visible, searchable and replaceable):

{"all":{"background-image":"url(\"https://test.tld/wp-content/uploads/2022/01/test.jpg\")","display":""}}

There are page builders that stored this in base64 encoded data inside your database such as this:

eyJhbGwiOnsiYmFja2dyb3VuZC1pbWFnZSI6InVybChcImh0dHBzOi8vdGVzdC50bGQvd3AtY29udGVudC91cGxvYWRzLzIwMjIvMDEvdGVzdC5qcGdcIikiLCJkaXNwbGF5IjoiIn19

Obviously, when the HTML code (that includes image URL) is converted to base64 format, Prime Mover plugin cannot search and replace these URLs during migration. And even if you do manual search and replace after import – it will not work also. Simply because – the URL is not visible, it is base64 encoded.

If you are migrating sites and affected with this issue – please contact your page builder plugin author to make the adjustment.

Contact us for further troubleshooting

If you still need technical assistance after going through all the troubleshooting steps and the issue still remains. Please contact us here. And then please provide us the following:

  • Detailed description of the issue. E.g. screenshots of the normal (working state) and screenshots of the non-working state/problem. Also please provide the URL or where to find this issue in your site.
  • Link to download your WPRIME package which you have used to migrate. You can store this in Google Drive, DropBox, etc. Please share this link only to our support via the contact form. Tech support will use this package to reproduce your reported issue.
  • Provide us as much debug data as possible. These includes screenshots, logs, etc.

Was this article helpful?
YesNo