WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#41947 closed defect (bug) (invalid)

upload_path wrong after server move

Reported by: steevithak Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.8.2
Component: Upload Keywords: close
Focuses: Cc:

Description

I recently moved a Wordpress 4.8.2 site from one server to another. The Domain name did not change. I moved the site by copying the files to the new server. The database did not move, it remained on the same, remote server.

After the move the site exhibited problems related to the upload directory path and was spuriously creating empty upload directories in the wrong place. If the spurious upload directories were deleted, they reappeared again within minutes.

On the original server, websites were in a directory path like this:

/var/www/whatever.com/www

On the new server, website paths were only slightly different, like so:

/var/www/whatever.com/html

I eventually discovered (by checking the wp-admin/options.php page) that the upload_path was still pointing to the path used on the old server (i.e. "/var/www/whatever.com/www/wp-content/uploads"). This incorrect value was apparently leading Wordpress to try to recreate the upload directory and subdirectories along the old, now non-existant path.

After manually changing the upload_path value to match the correct location on the new server, everything started working ok again. None of the server migration guides provided in the wordpress docs warn about this problem or mention the symptoms or how to detect that a change is needed, or tell you how to reach the options.php page where the problem can be diagnosed and fixed. For example, here's the best documentation I could find on moving a wordpress site:

https://codex.wordpress.org/Moving_WordPress

So it seems there are two possible bugs here and I'm not sure which is valid and needs to be fixed.

Possibility 1: Wordpress core should adjust the upload path automatically when the site is moved and failure to do so is a bug.

Possibility 2: There's some valid reason why Wordpress can't detect the change or update the upload_path value automatically and this not a code bug but an unfortunately pitfall of moving Wordpress sites. In this case, I think we're just dealing with a Wordpress documentation bug in that the migration document fails to warn about this problem or describe the fix for it.

One simple fix might be to make the upload_path visible in the admin general settings page where the other paths are found as this is the first place I looked when I began to suspect the problem. It took a little googling to find out there were more settings that are only accessible on the hidden options.php page.

Change History (9)

#1 follow-up: @technosailor
2 years ago

This isn’t really a bug. It’s an option and, like the name suggests, doesn’t lend itself to being a decision. Besides being an option, you’d be doing a database call on every page load for something that won’t change often. Definitely plugin territory with minimal effort.

Last edited 2 years ago by technosailor (previous) (diff)

#2 @technosailor
2 years ago

One other thing. Use the relative path and WordPress will understand or... just don’t set because your path is the default when nothing is set:

wp-content/uploads/

#3 in reply to: ↑ 1 @steevithak
2 years ago

I can confirm that setting upload_path to "wp-content/uploads/" seems to work as well as the full path. And that seems like a good plan to avoid the problem in the future, should the site move again. No plugin or per-page database stuff was needed, by the way, I just edited the path on the options.php page as described in the bug report and that fixed it right up.

I got curious and started checking the upload_path value on other wordpress sites I have access to. On most recent sites I checked (and all sites that I've personally installed) the upload_path value field is empty. So I guess the question I have now is how would a value get into that field in the first place? Is this a deprecated field of some sort that was used on older wordpresses? In any case, I think the bug as reported still stands as it's a legitimate problem a developer asked to move a wordpress could run into.

#4 @dd32
2 years ago

  • Component changed from General to Upload
  • Keywords close added

The upload_path option is used for when you're storing the uploads in a non-standard location. If it's being uploaded into wp-content/uploads it can/should be left blank (Along with the upload_url_path option).

The upload_path option is exposed on the Settings -> Media screen, and unless it was set previously, it's hidden by default in newer versions of WordPress.

IMHO: If you're setting upload_path, it's not something that can be automatically updated, and must be taken into consideration when you're moving servers - you've told WordPress to store files there after all.

It sounds like https://codex.wordpress.org/Moving_WordPress could maybe do with a reference to it, the codex is a wiki and anyone can edit it as they see fit.

I don't think anything needs to be changed here, I'd suggest this should be closed as invalid myself.

#5 @dd32
2 years ago

Turns out that once upon a time, WordPress did auto-set upload_path to ABSPATH/wp-content/uploads (so it's not always user set). We seem to have stopped doing that somewhere between 2.7 and 3.7 (I can't find where exactly).

Unfortunately it's not possible to detect when the value was set by the user vs set automatically, so it's hard to know when it should be auto-updated.
WordPress could simply null out the option when it equals the default location, but that has the slight possibility of breaking scenario's where it's been set deliberately and WordPress is being used in a scenario with multiple servers with a shared uploads directory.

#6 @steevithak
2 years ago

I didn't realize the codex was user-editable. I've added a small section warning about the need to check the upload_path value when moving old or customized wordpress sites. Someone may want to check my text and clean it up if it doesn't follow any writing guidelines that exist but it should be pretty close.

This bug can definitely be closed. I think if the bug existed, it was just a documentation bug rather than a code bug and we can consider it fixed now.

#7 @dd32
2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Status changed from new to closed

Thanks @steevithak
I'm going to mark this as invalid for now, hopefully people will never have to think about it in the future :)

#8 follow-up: @steevithak
2 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

Sorry to reopen this but I noticed that my addition to the Moving Wordpress page documenting this potential problem has been removed in its entirety. Since we decided the bug was actually just a lack of documentation, this removal essentially re-opens the bug. Rather that start an edit war by restoring my text in the wiki myself, I would appreciated it if an admin or editor could take a look and either re-add it or add something equivalent so that other people running into the problem can solve it more easily. Clearly my attempt made someone unhappy. Thanks.

https://codex.wordpress.org/Moving_WordPress

#9 in reply to: ↑ 8 @jdgrimes
2 years ago

  • Resolution set to invalid
  • Status changed from reopened to closed

Replying to steevithak:

Sorry to reopen this but I noticed that my addition to the Moving Wordpress page documenting this potential problem has been removed in its entirety. Since we decided the bug was actually just a lack of documentation, this removal essentially re-opens the bug. Rather that start an edit war by restoring my text in the wiki myself, I would appreciated it if an admin or editor could take a look and either re-add it or add something equivalent so that other people running into the problem can solve it more easily. Clearly my attempt made someone unhappy. Thanks.

https://codex.wordpress.org/Moving_WordPress

I've reinstated a slightly modified version of the section you added. Thanks for your understanding and contribution!

Note: See TracTickets for help on using tickets.