Make WordPress core updates only update the core

Description

Since both plugins and themes can be updated within WordPress now, it's time to keep all of the updates separate. Really, everything in wp-content (or what ever the user has that named) should not be touched (including the index.php sitting in wp-content/, wp-content/plugins/, and wp-content/themes/).

Oldest firstNewest firstThreaded

Comments only

Change History (44)

I think dd32 and I agree here -- wp-content no longer needs to be touched. (Hello Dolly, Akismet, Twenty Ten.) We will however need to copy over the current default theme if it does not exist in the install.

I think dd32 and I agree here -- wp-content no longer needs to be touched.

Only 2 exceptions which i can think of:

New default themes as you mention

If we can get a post-upgrade message for the new things, then new themes can be ignored for core upgrades, Current installs can then just use the Theme Installer if they wish to try out the new themes.

Updated Language files

This ties into custom wp-content dir's as well, at present, the core upgrader is not aware of custom dir's, so if you use the constants to make it 'my-content', the upgrader will still dump the stuff into 'wp-content' even if its not used. Theres another ticket for that

Just wondering, why do you need to copy over the default theme? If it doesn't exist, it has probably been deleted for a reason.

This is one thing that always irritates me with every upgrade. It keeps installing the default theme, Aksimet and Hello Dolly. I'm using my own custom theme, and I'm not using these plugins. That's why I removed them in the first place. Now, it's not a big deal as long as they are up to date, but as soon as there's a new version, you get notifications. This can be confusing for clients or any user not tech-savvy.

CORE_UPGRADE_SKIP_NEW_BUNDLED - It's been mentioned there should be a way of preventing future default themes/plugins from being installed with upgrades. That constant does just that. Need to check if anyone has a better idea for the constant name.

Testing is needed here as well, particularly with localised installs, and those with custom wp-content directories

To test WP_LANG_DIR: 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

Do we want upgrades to 3.2 to skip the wp-content shenanigans? At present moving to 3.2 will overwrite wp-content with that from the downloaded package. This is because the upgrade will make use of the 3.1 (or below) version of copy_dir without skip lists.

This could be overcome with a temporary 3.2 version of copy_dir (named _copy_dir for example) in update-core.php which would only be included for 3.2. However, there are a number of drawbacks. This 'fix' would only work for updates to 3.2, still the same problem (which would occur anyway) for 3.1 -> 3.3, unless it was kept indefinitely which doesn't sound good. Also I think there would be extra problems with language packs, see #11495 comment 20, without extra workarounds for 3.2 which doesn't sound nice either.

// Copy root files manually
dirlist()
foreach ( $list as $file )
if is file, then copy
if is directory and not wp-content, then copy_dir()
// Do wp-content stuff
..existing code in core after last commit

This could be overcome with a temporary 3.2 version of copy_dir (named _copy_dir for example) in update-core.php which would only be included for 3.2. However, there are a number of drawbacks. This 'fix' would only work for updates to 3.2, still the same problem (which would occur anyway) for 3.1 -> 3.3

I strongly suggest we do exactly this. Use a temporary solution so people who update to 3.2 can benefit from this now, and rip it out in 3.3-dev. If you go from 3.1 to 3.3, you won't get this until you're using 3.3, which is fine by me -- the alternative is the same position. There's no cost in this cost-benefit analysis.

(In [17580]) Back-compat for core upgrades with pre-3.2. Utilises a temporary _copy_dir() function which can be removed in 3.3-dev to bring immediate wp-content relief to the 3.1-3.2 upgrades. See #14484

Although the reappearing plugins etc. are annoying, it's easily remedied by using a custom wp-content directory. So -- the ideas discussed may be a good idea anyway, but we should be careful of needlessly complicating things. This is almost (almost!) a solution without a problem.

(In [17580]) Back-compat for core upgrades with pre-3.2. Utilises a temporary _copy_dir() function which can be removed in 3.3-dev to bring immediate wp-content relief to the 3.1-3.2 upgrades. See #14484