Wordpress Migration only works if db is directed to old hosting

You didn't say what OS you are running on your Linode or how you did the migration.

With WP, 95% of the time it is a owner or permission problem or both. On my Ubuntu 20 server

Directories should have permissions of 755, or rwxr-xr-x. Files should have permissions of 644, or rw-r--r--. The wp-config can be 600 or 604.

755 does not work for me so I run directories at 775. I don't yet know why 755 won't work but I'll figure it out.

I set my ownerships to $USER:www-data.

Hi thanks for the reply, I'm using the marketplace install on Debian, and I tried duplicator for the migration and migrate guru and even a manual migration of the database.

when you say owner or permission problem, what exactly do you mean? I had the folder of wp set to 777 for the migration process, I did not touch the owners.

how is that related to the database though? if the wp-config is using the old database on the old hosting the site works fine, but once I direct it to the new one that's when the problem starts, but it's not a problem connecting to the database, I've had that happen to me in a few of the combinations I ran.

the ownership is similar to what you wrote.

how is that related to the database though?

It's not. mysql(1) and it's associated server process(es) mysqld(1) use their own user/group (mysql:mysql) for ownership & permissions. These have nothing to do with the web server or php (which is what @acanton77 is talking about).

I'm not a mysql(1) expert and I don't play one on tee-vee, but it seems to me that your database didn't migrate as you expected it to. Or, there's something in some WP/plugin php file someplace that's not right (/usr/bin/*grep will be your friends). Given the plethora of poorly-written, un-tested and un-maintained plugins that are foisted on the the unsuspecting WP user base, none of that would be surprising to me at all.

Make sure your versions of WP match up on old vs new installations. WP changes (far too) frequently. Ditto for any plugins you may have installed. My spidey-sense about such matters is tingling…

If your database did migrate as you expected it to, I would look at mysql(1) users, passwords, roles and capabilities next.

Make sure you take a snapshot of your Linode or have a recent backup so that you can resurrect the patient if the surgery fails. I like snapshots for this because they don't change unless you change them.

-- sw

P.S. Just remember this experience the next time someone pitches doing something with WP and asks/tells you to support it! The few times I've done anything with WP it's always turned out badly and I ended up wasting a whole bunch of time before abandoning it in complete frustration. Like Facebook, I generally think WP is evil.

WP releases are far too frequent, not tested well and are, more often than not, extremely buggy ("We'll prioritize the fix at level zero for the next release 48 hrs from now."). Add to that a pile of plugins/themes that are developed by "Hey, it works for me in my extremely narrow set of ad hoc circumstances…let's make it available to the public and then abandon it tomorrow" developers, you have a recipe for a giant disaster if you get within a 100 miles of it.

But, then, you probably knew all that… If you didn't before, you certainly do now. I suspect you're going to have to rebuild your site… Just take a few shots and down an IPA and get ready for the battle ahead.

Hey and thanks for the detialed reply, I have posted this on another forum as well, and was led down another path where I found these:

[Sun May 09 06:32:19.216587 2021] [php7:error] [pid 18107] [client 18.222.75.248:56618] PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /var/www/wordpress$
[Sun May 09 06:43:10.681034 2021] [access_compat:error] [pid 21992] [client 75.119.215.210:38307] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php
[Sun May 09 06:57:56.295325 2021] [access_compat:error] [pid 18107] [client 208.97.136.31:48368] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php
[Sun May 09 07:15:02.529616 2021] [access_compat:error] [pid 21991] [client 144.91.74.140:54734] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php
[Sun May 09 07:35:08.137176 2021] [access_compat:error] [pid 17337] [client 62.210.111.85:5907] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php, referer:$
[Sun May 09 07:41:10.998717 2021] [access_compat:error] [pid 22499] [client 165.227.71.206:61978] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php
[Sun May 09 07:47:27.157936 2021] [access_compat:error] [pid 21998] [client 198.12.246.118:51976] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php
[Sun May 09 08:05:00.949217 2021] [access_compat:error] [pid 17359] [client 107.180.235.105:39148] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php
[Sun May 09 08:05:39.617098 2021] [access_compat:error] [pid 21992] [client 107.173.248.219:1670] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php, refere$
[Sun May 09 08:05:40.646823 2021] [access_compat:error] [pid 23419] [client 198.12.108.219:51807] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php, refere$
[Sun May 09 08:05:41.683400 2021] [access_compat:error] [pid 17337] [client 192.3.139.139:16185] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php, referer$
[Sun May 09 08:05:42.472018 2021] [access_compat:error] [pid 22339] [client 192.3.195.125:60125] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php, referer$
[Sun May 09 08:23:12.749354 2021] [access_compat:error] [pid 17337] [client 97.79.238.65:49196] AH01797: client denied by server configuration: /var/www/wordpress/xmlrpc.php

and the one I think is responsible:
[Sun May 09 06:32:19.216587 2021] [php7:error] [pid 18107] [client 18.222.75.248:56618] PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /var/www/wordpress/wp-content/themes/jarida/index.php:1\nStack trace:\n#0 {main}\n thrown in /var/www/wordpress/wp-content/themes/jarida/index.php on line 1

that last one is the theme of the website, which would explain seeing only links and text.

however, that does not explain why it breaks when I change the wp-config file.

as for all the things you said about WP, I know, and I have taken a few steps to mitigate the stupidity of it, both sites are running the latest versions of the plugins and WP, and auto-update of plugins is enabled.

plus I try to use plugins that are updated frequently and have millions of downloads.

You can fix all the xmlrpc.php errors by just disabling it…it’s a giant security hole anyway.

Try inserting a get_header() function in /var/www/wordpress/wp-content/themes/jarida/index.php that emits some recognizable text to see if that makes your site display (even if it’s wrong). If it does, you may have run into a theme incompatibility… Is the version/config of php the same on old vs new?

however, that does not explain why it breaks when I change the wp-config file.

Have you looked at the mysql log for any clues? It could be a database read problem because the user doesn’t have enough capability…

All just a guesses…. Hopefully you’ll get lucky sooner rather than later.

— sw

thanks for the notice, I disabled the xmlrpc now and hope that cleans the logs.

as for the header, the first line in that file is
so I guess it's in there already?

If it does, you may have run into a theme incompatibility… Is the version/config of php the same on old vs new?

last I checked they are both sites are running PHP 7.3 and the theme works on the old site, we just recently updated the theme as well.

as for the MySQL logs, the file is empty, so I guess they aren't enabled by default. but as for the permissions, I even tried authenticating with the root user as a test in the wpconfig, still had the same problem.

EDIT: I was not aware it creates a new log each day, checking those now.

EDIT 2: 3 days of empty logs in SQL. and the last test was run yesterday.

This stuff:

mysql> GRANT ALL PRIVILEGES ON databasename.* TO "wordpressusername"@"hostname"
-> IDENTIFIED BY "password";
Query OK, 0 rows affected (0.00 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec) 

mysql> EXIT

is not recreated when you migrate a database. This is because mysql(1) keeps it in a table that is not part of your WP database. Not having the a user for the database with the correct privileges can cause the problems your seeing.

I copy/pasted the example above from someplace else. You need to substitute your own database name, host name and password.

Here's a tutorial on mysqld(1) logging:

https://www.pontikis.net/blog/how-and-when-to-enable-mysql-logs

as for the header, the first line in that file is
so I guess it's in there already?

Yes, but PHP is saying the function is undefined. That means the file it's defined in was not loaded before the function was called (or at all)…or the signature for the function changed so that what you're calling doesn't match what's defined (PHP keeps track of such things).

Here's the WP doc on it:

https://developer.wordpress.org/reference/functions/get_header/

-- sw

Not having the a user for the database with the correct privileges can cause the problems your seeing.

we are talking about the MySQL user, right? because I don't have another user for the machine and my old hosting does not have any users for where the website (not the database) is stored.

i think that solved it,

FLUSH PRIVILEGES;

how can I make sure that everything works before I kill the previous hosting?

also "define('AUTH_KEY'," should stay like they were in the old hosting right? because that's what it is now, and everything works.

we are talking about the MySQL user, right?

Yes… in my example the mysql(1) USER would be "wordpressusername"@"hostname".

how can I make sure that everything works before I kill the previous hosting?

I dunno…assuming your Linode has an IP address, you can access your site as https://1.2.3.4/blah/blah/blah . When you switch your domain name to the new (Linode) IP address, there's going to be an up-to-48-hr period while the new DNS settings propagate around the world.

also "define('AUTH_KEY'," should stay like they were in the old hosting right? because that's what it is now, and everything works.

I suppose. You'll have to ask someone more adept at WP administration than me. Here's more information:

https://www.wpbeginner.com/beginners-guide/what-why-and-hows-of-wordpress-security-keys/

From what this says, I would assume the answer to your question is yes…AUTH_KEY should remain undefined.

-- sw

assuming your Linode has an IP address

yeah, the DNS has already been targeting the linode machine from Sunday, but the database in the wp-config was directed to the IP of the old one.

AUTH_KEY should remain undefined.

it is not undefined, it uses the same ones from the old wp-config, but the site works, guess I'll try tomorrow to change that and see if something breaks, and if not I'll start shutting down the old host.

anyway, thank you so much for all your help! I hope this thread also helps people who have the same problem in the future.

it is not undefined,

From your previous post, I assumed that AUTH_KEY and it's siblings were undefined. My bad… Sorry.

anyway, thank you so much for all your help!

You're welcome.

-- sw