Customize Page Disappeared after Site Migration

Customizer functionality broken after FTP migration

[jastra]

I migrated site files from a properly functioning dev site running on a subdomain over to the primary domain on the host. The dev site was under a different theme (Sinatra) than the live site under the primary domain.

I used FTP to migrate the dev site. First I deleted all the public_html files on the host and then FTP'd all the dev site files under public_html. Everything works OK except for the disappearing Customize functionality. I didn't touch the database, except to update the URL.

Now, when I hit Appearance > Customize I only get a blank page but with the usual "You are customizing (Site title)" in the left column.

When I hover over the link Appearance > Customize menu item in my WP Dashboard I see this:
/wp-admin/customize.php?return=/wp-admin/index.php

Customize.php is properly in the public_html/wp-admin folder.

And when I copy and paste https://example.com/wp-admin/customize.php into my browser address box I also get the blank Customize page.


I tried re-installing the Sinatra theme after:
1) activating a different theme,
2) deleting the malfunctioning Sinatra theme,
3) then downloading a new version of Sinatra and activating it.

But that didn't help. Same issue with Customize remains.

How can I fix this?

Thanks,
Jastra

[not2easy]

Can we rule out a failure to import the .sql from the dev site? I don't see that mentioned. The wp-config file would need to fit the settings for 'both' setups and be installed to a matching sql setup. Is your "/wp-admin/index.php" file a blank (empty) .php file?

It sounds like the theme's functions.php might need a look.

[mhansen]

I seem to recall a similar issue like this before and it was related to using an older version of WP on the dev site, and importing to a newer version on the production site. Did you install WP automatically via the host, or use the exact same export for 100% of the import?

FWIW - There is a free plugin called "Duplicator" from SnapCreek. It automates this process for exporting/importing and renaming WordPress sites and is super easy and fast to work with, unless you have a very large site.

[jastra]

@not2easy--
Thanks for the quick reply. /wp-adminindex.php is there, looks OK, although I wouldn't know for sure as I'm no programmer. When you ask about .sql, do you mean the database? Actually, I've kept using the same dev database after importing the files. All I did was change the option name URL from subdomain.example.com to the primary domain URL. Was that wrong?

@mhansen--
Right, I installed WP via Bluehost, and started a totally new website. I realize now I should have used Duplicator. I sat and watched my life pass before my eyes as I babysat the FTP upload LOL, and this isn't a large site at all. I suspect something got corrupted during all that time.

As I may be getting into the tall weeds here on coding I don't understand, I'm almost to the point of taking the loss and starting all over again, re-building the site on the Bluehost staging site and trying again.

[mhansen]

@ Jastra - If the dev site is still accessible, I recommend giving the Duplicator plugin a quick shot. It takes the file system and stores it as one file, then includes an installer file to handle the leg work. You upload both to the public_html (or home directory) of the new webhost, navigate to the installer file and the rest is very much point and click. It takes longer to download/upload the files, than the rest of the process takes. It changes all domain references, etc - and you just need to login to clean up the installation with a couple clicks which are automated as well.

[jastra]

Thanks. But unfortunately, I was so proud of myself when I saw that the migration "looked" good, I pulled the plug on the dev site subdomain. All I have now is the dev site's /public_html on my hard drive. I'm looking over Duplicator's page on Wordpress dot org and don't see any mention of uploading from a hard drive. Unless there's some workaround.

[mhansen]

I don't think they have a way to fix this via a public_html upload through Duplicator, Jastra. It's an all-in-one, plugin based solution for migration and backups.

Have you considered resetting your dev environment, using the same database that still exists, and just reloading the public_html directory to the dev system to see if it works as expected?

To be fair, unless you had a lot of customization done, it might be just as quick to just reboot on the live box and start over.

[not2easy]

The public_html files are the framework for WordPress but the content is stored in the .sql - yes, that is the database. If your dev site's .sql is now stored in the database as described in the wp-config.php file, on the new host it would hold whatever URLs were in use on the dev site. The database name and prefix and username and password should be as seen in your wp-config.php file.

The Admin Options settings for URL and location will apply to any new content on the new location but the old .sql tables hold their original settings until changed. If you did not manually upload and install the .sql databse, it would be "new install" empty and populated only with its new content.

I hope I am misunderstanding the install because if you have deleted the original dev site completely I don't know where you might recover a copy. IF only the public_html files and folders were deleted you might still find your old database on the old dev site.

If you want to learn more about the necessary steps, WordPress offers documentation, tutorials and all the how-to help: [learn.wordpress.org...]

[jastra]

@mhansen and @not2easy--
I've elected to rebuild the site on the Bluehost staging site, then move it over. The site is a relatively small one. I believe I made two mistakes here: not using a plugin like Duplicator to migrate the dev site and then deleting the dev site before I checked, and checked carefully, to make sure everything was screwed on straight. My ISP has been a little squirrely the past few days and I think something may have gotten corrupted in the FTP process. This has been a huge learning experience. Thank you both for your help and solid advice.

[jastra]

It ends up that wp-admin/customize.php was corrupted, probably during the FTP migration. I deleted customize.php then uploaded a known good version and that did it. From this day forward I will always use Duplicator. Thanks again for the help, guys.

[not2easy]

Good to know you found the problem and it was easy to fix. If your host uses CPanel you can probably use their backup tool to create a .tar.gz backup copy of everything to store offline and sftp that to restore it. You should run a backup before making critical updates - just in case. Just be sure to delete the backup file from your server once you have downloaded it. We see probes all the time trying to find backup files.