Automatic upgrade does not use custom directory structure

Description

When you define WP_CONTENT_DIR, WP_LANG_DIR, WP_PLUGIN_DIR, and/or WPMU_PLUGIN_DIR to some non-standard values and try to automatically upgrade WordPress to new version, new files will end in default locations (wp-content, etc) instead of custom ones.

After I tried to upgrade core automatically, updated plugin and theme files ended within default C:\wordpress.local\wp-content dir. I would expect that they will be moved and overwrite old files in C:\wordpress.local\my-plugins and C:\wordpress.local\my-content\themes.

Translation files (I have upgraded to pl_PL version) also ended in C:\wordpress.local\my-content\languages\ instead of C:\wordpress.local\content\languages\.

Although we need to be careful how we do this as some people may have moved the plugins directory away because they don't want the default plugins in it.

This depends on how the Canonical plugins varies for this release IMO, I'm thinking that the default plugins are going to be replaced anyway, And they're not suited to being included in the core-upgrade process at all.

The same goes for themes, The default theme should be upgraded - If it exists, If not, it shouldnt be copied over at all perhaps.

Languages however, are a definite for a path rewrite, Perhaps WordPress should just deal with that branch instead for now?

Ah i see what you mean now. I guess, This means we'll need a rewrite process during the upgrade for the wp-content folders..

Can you name file(s) / function(s) where this might be applicable sothat they can be reviewed if they reflect propper const values? I'd like to focus on the concrete bug before doing free-thinking about upcomming features.

I'd like to focus on the concrete bug before doing free-thinking about upcomming features.

The feature IS the bugfix.

WordPress uses ABSPATH for the core upgrade and assumes thats where files live. But as pointed out, Those who move their content direcotry, end up with files in their default location rather than their custom location. End of story. Therefor, The upgrade needs an extra step afterwards, to check if any custom directories are defined, and move/copy/overwrite them with the new files too.

I'd like to focus on the concrete bug before doing free-thinking about upcomming features.

The feature IS the bugfix.

WordPress uses ABSPATH for the core upgrade and assumes thats where files live. But as pointed out, Those who move their content direcotry, end up with files in their default location rather than their custom location. End of story. Therefor, The upgrade needs an extra step afterwards, to check if any custom directories are defined, and move/copy/overwrite them with the new files too.

As has been mentioned before, wp-content should probably be removed from the core upgrade all together, and copy over only what we need -- i.e., the current default theme if the directory does not exist.

We can then rely on the theme/plugin updaters for Akismet et al.

That would require some tweaks in the auto upgrade code, though not in this direction.

[17576] should've largely fixed this, the only custom path not being respected here was WP_LANG_DIR. wp-content will not longer be created either.

I believe that fixes this ticket, however, I'm leaving this open for now pending more testing of the changes.

To test: You'll need to take a 3.2 install, modify it's version to indicate 3.1, set a custom WP_CONTENT_DIR and/or WP_LANG_DIR, and perform a automatic re-installation from Dashboard->Update, the result should be that wp-content doesn't exist, and that the language files have been updated

This is going to fatal error on upgrades from a version less than 3.2 to a package containing a language directory. This is because the upgrade will be using update-core.php from 3.2, but $wp_filesystem->wp_lang_dir() is not defined in 3.1 and below.

Might have to check is_callable and leave the problem for updates to 3.2, but fixed from 3.2 and beyond.

The alternative is to switch ->wp_lang_dir() to ->find_folder(WP_LANG_DIR); since it's just a wrapper.

The function will be useful for the language packs which is why I added it instead of just calling directly.

The other issue is that on <3.1 WP_LANG_DIR will be defined as wp-includes/languages unless wp-content/languages exists, which will cause problems for that code for upgrades to a zip which includes language files, yet wp-content/languages doesnt exist on the system - a very edge case

Whilst we're at it, might as well add a FTP_LANG_DIR override constant like the rest. (To skip path searching)

Going with is_callable would protect against the fatal, but given we're not copying wp-content, those who do NOT use a custom WP_CONTENT_DIR / WP_LANG_DIR would've missed out on language files during the update.