Path error when adding site

[johnm (John McCurdy)]

I just moved all my sites from an Apache server to an Nginx server. My process was to copy the files to the new server, dump the database to an SQL file and import it to the new server, then point the domain to the new ip address. I also rebuilt my dashboard site from the ground up on a different server and re-added the child sites after they were moved.

Most of the sites moved without issue, but one is stubbornly refusing to let me add it back to the freshly installed MainWP dashboard. Everything else is fine, but when I activate the MainWP Child plugin on this site and add it to the dashboard, I get this error:

Unable to create directory /home/wlc/public_html/wp-content/uploads/mainwp/. Is its parent directory writable by the server%3F

Now, the problem here is NOT that the directory isn’t writable. It’s that the path is from the old Apache server and simply doesn’t exist on the new server. So here’s what I’ve done:

First, I deactivated the child plugin and used the Better Search Replace plugin to search the database for the old path (/home/wlc/public_html/) and replace it with the new path (/sites/[domain.tld]/files/). Then I reactivated the child plugin and tried again, and got the same error. Since then:

I’ve searched the database, multiple times and multiple ways, for “public_html” because that’s a unique part of the old path that should be found despite any encoding or serialization in the database. It’s not there.

I checked wp-config.php, and found a reference to the old path related to an old caching plugin. I removed that and made sure there isn’t anything else unusual in the file, but the problem persists.

I downloaded the wp-content folder, and then the whole site, and used PowerGrep to run a text search through everything for any hint of the old path. It found nothing.

I turned on the debug log and discovered another plugin (Divi Booster) was also holding onto the old path. I removed it and the errors in the log stopped, but MainWP still gives the same error when I try to connect the site, and does not create a log entry.

I deactivated and deleted the child plugin and manually removed every reference to MainWP from the database, the reinstalled and reactivated the plugin, and the problem remains.

So at this point I’m totally stumped. It’s a complex site and I’m not getting paid to rebuild it right now, so I’d really like to find this problem. But I cannot for the life of me figure out where that old path is still coming from!

Any ideas?

[bogdan (Bogdan Rapaić)]

Hi @ johnm, have you tried to remove the old path like this:

1. On the child site go to the …/wp-admin/options.php page, it will show you all wp_options database table options.
2. Use the Ctr + F to find the following string: upload_path
   
   
3. Delete the value from the field
4. Scroll all the way to the bottom and save changes

This should fix the problem.

The other maybe easier way to do it is this:

Go to the Settings > Media and delete teh Store uploads in this folder field. Leave it blank and save changes.

Let me know how it goes

[johnm (John McCurdy)]

I’ll be damned… It was the media setting. I never saw that before, and after I cleared it the site connected with the dashboard just fine. Thanks Bogdan!

But… What I don’t understand is, where did that setting come from? It has to be stored somewhere, but I still can’t find it in my dump of the database from before I fixed it.

Thanks for the tip about options.php, I didn’t know about that before. But I had already fixed the upload_path setting in the database, so that wasn’t it.

[bogdan (Bogdan Rapaić)]

This problem occurred because the clone process cloned the value from the original site. You can find that in the wp_options table in your database, in the upload_path field.

[johnm (John McCurdy)]

Yes, but one of the first things I did was change the upload_path field in the wp_options table, and later I cleared it completely. So that setting had to be stored somewhere else, and in some form that couldn’t be found through a text search of the live database or of the sql dump file.

Oh well, very strange…

Thanks for your help!