Installed WAMP and WordPress - don't see the real site

No, I don't want to add a plugin to the QA site if this is what's needed. I'm afraid I might mess up that site. We're not WordPress devs.

The code I copied from QA has the entire code.

I think I need to update those tables. I saw the sake thing on 2 articles.

No other way to debug this besides plug-ins?

I installed it on my test WordPress site as a test. Made a backup of my test site and it worked.

Still not comfortable doing it on our QA site. I'll google what I've done so far for a solution and think about installing this plugin on QA. I want to avoid it if I can figure out why I can't see the actual site with the setup I've done. 

1) Keep in mind, trying to edit the database as you have means you've now destroyed your database.

2) WordPress uses serialized data (read up on this anytime you can't sleep, as it's a sure cure for insomnia).

This means if you use SQL UPDATE statements, you just destroyed your database as SQL has no concept of PHP serialized data.

You must use PHP serialized data aware code, which means... as @Scott mentioned... all WordPress backup/restore/migration plugins... well.. most of them... see next item...

3) Now that Elementor has completely broken PHP serialized data, you have to go an extra step...

I only do hand migrations, where I restore the database on the command line, then run wp-cli commands to rename both the normal serialized data + Elementor's... opium induced miasma wafting idea of non-standard serialized data...

If you're using Elementor wp-cli now has a special replace_urls verb/command built in to correctly handle this nonsense.

4) Trying to migrate a live site to a local dev environment... you'll end up spinning your wheels in all sorts of time draining ways.

Better to spin up a dev site so if foo.com is your site, then dev.foo.com is your dev site for work.

This way you place the site on a public IP, wrap it in a real TLS cert, work on site exactly like a real site.

You'll also save yourself all manner of pain if you use a LAMP Stack, rather than a WAMP Stack.

5) To rename foo.com -> dev.foo.com on the command line (really the only way right now to guarantee a correct site rename)...

These are the steps I use with every migration... which likely best to have your Tech Savant do for you...

# All steps expect Ubuntu + latest MariaDB from MariaDB, not Ubuntu packaging.
# Other conjurations required for other Distros + various versions of MySQL + older versions of MariaDB.

# Create database
mysql -e "CREATE DATABASE IF NOT EXISTS foo_dev CHARACTER SET utf8 COLLATE utf8_general_ci"
mysql -e "CREATE USER IF NOT EXISTS foo_dev@localhost IDENTIFIED BY 'random-16-byte-hash'"
mysql -e "GRANT ALL PRIVILEGES ON foo_dev.* TO 'foo_dev'@'localhost'"

# Restore database
pv database.sql | mysql  --default-character-set=utf8 foo_dev

# Dryrun echo STDERR to determine if code on site will survive a rename.
wp search-replace "http://foo.com" "https://foo.com" --dry-run --report-changed-only --all-tables --precise --recurse-objects

# STDERR to /dev/null to suppress incompetent coder's diagnostic spew.
wp search-replace "http://foo.com"      "https://dev.foo.com" --report-changed-only --all-tables --precise --recurse-objects
wp search-replace "http://www.foo.com"  "https://dev.foo.com" --report-changed-only --all-tables --precise --recurse-objects
wp search-replace "https://foo.com"     "https://dev.foo.com" --report-changed-only --all-tables --precise --recurse-objects
wp search-replace "https://www.foo.com" "https://dev.foo.com" --report-changed-only --all-tables --precise --recurse-objects

# Now run the Elementor hack, if you're running Elementor
wp elementor replace_urls "http://foo.com"      "https://dev.foo.com"
wp elementor replace_urls "http://www.foo.com"  "https://dev.foo.com"
wp elementor replace_urls "https://foo.com"     "https://dev.foo.com"
wp elementor replace_urls "https://www.foo.com" "https://dev.foo.com"

Select allOpen in new window

>>read up on this anytime you can't sleep, as it's a sure cure for insomnia
LOL, I will.

I didn't know about #1, and #2. I'll look into LAMP as well.

I'll try the plugin Scott mentioned in couple of hours. I told my manager I might install it. It worked on my local WP site. I feel more comfortable with it. I just didn't want to make things worse than it is now.

Management cutoff offshore today and pushed the go-live from Jan 4 to Jan 15. This should help us - or at least me to learn more about the site. 

The big consideration these days is Page Builder, like Elementor, who use non-standard data nonsense.

Even when I migrate a site with Duplicator or BackupBuddy, my first step is to get onto the command line + do all the manual wp-cli commands above.

You'll likely be shocked at all the renames missed by serialized data rename code... which you'd expect work... which doesn't because of non-standard data polluting the database.

I'll use that plugin Scott mentioned. I'll suggest #4 to my manager but I know it won't happen at least not  until go-live.

For now, I want the code locally.

Installed the plugin and it's restoring. Hopefully it will work :)

once you copy your side over you can remove the plug in

I stopped it and will redo this whole thing again. This can't be working correctly. It was still going on the same table.

1) If you use a Wordpress backup plugin, or standalone code, if you have a Page Builder in use... especially Elementor, be sure to check notes to determine if your tool of choice provides same facility as wp-cli.

You can easily determine this by running a database search afterwards for your original domain name.

If some residue persists, then run wp-cli to clean up remaining problems.

2) And yes, because you did an SQL UPDATE, you'll have to restore your database + start over.

>>2) And yes, because you did an SQL UPDATE, you'll have to restore your database + start over.

I didn't run the SQL update. I did have a database created first, had the tables moved over from QA and then ran the plugin update.

I deleted the database and the code in www folder. I'll start again.

In theory, you could replace folders, but look to see what the contents are of that folder and that the layout is what is expected for WP.  A migration of some form will be the easiest option for you and that migration can include both database and files. Especially with Avada. Also with Avada, you can have a second site but it has to be password protected. I typically buy 2 licenses of Avada so I can have one for production and one for staging where the staging is not password protected but it is set to not allow search bot's to be indexed. 

Thanks. I'm redoing it. Didn't know the migration will do the database too.

I'll see how the second time works.

Maybe try a different plug in for migrating. 

I just checked that table in QA.  It has 11,000 rows. I think that's what's going on. Needs to go thru all the rows.

Creates the table and inserts row? if that's the case, it will eventually end after 11,000 something rows.

 I can exclude tables but in the paid version. I'll let it run and see what happens.

Oh... I think I see the problem...

If this is a hang making a backup, this relates to the barely functional hosting for this site.

https://webpagetest.org/result/211221_AiDc86_d03aed5eb0607c905074495d0f405bac/ shows all manner of slow wait times.

This means almost all backup plugins will lose their mind in various ways + hang forever.

The way I make backups...

1) Try https://wordpress.org/plugins/duplicator, if this fails proceed...

2) Try https://ithemes.com/backupbuddy, if this fails proceed...

3) Setup ssh access to machine. Start up a shell. Backup database into DocumentRoot directory. The clone (rsync -av) all files to new machine.

This works 100% of the time + can be a pain to get working.

4) Consideration: For well tooled hosting, any Backup plugin you use should work.

For badly tooled hosting, you have to muck about... trying to bypass the bad tooling...

*Note* - If you exclude tables, expect to have an unstable restored site.

Some plugins break WordPress standards, by not honoring wp-config.php -> wp_prefix... so if you have... incorrectly prefixed tables... you can't exclude these, as they may be required.

I won't exclude. Let me look at your steps. 

Update: Duplicator worked. Thanks, David. 

You're welcome!

Hang in there!

Thanks!