Make WordPress core updates only update the core

[mtekk]

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/).

[scribu]

Not really sure what you're getting at. What exactly is touched in wp-content when updating, currently?

[nacin]

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.

[dd32]

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

[bergius]

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.

[nacin]

Replying to bergius:

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.

I'm referring to the most recent theme, assuming you're upgrading from a version prior to the release of said default theme. I suppose with an optional way to disable that for client sites.

[ramiy]

+1

[jb510]

+1 please... I've already got 3 emails from clients asking me WTF Hello Dolly is and where it came from...

This makes perfect sense to me. I can support keeping Hello Dolly and Akismet in the default install, but neither should ever re-install during an update.

[computerwiz908]

I think that this is a no-brainer. It is very frustrating to have to delete Hello Dolly every time I update WordPress...

[dd32]

Accepting this and marking as 3.2 for tracking purposes, Until the 3.2 scope meeting is done, no specific enhancements are a given.

[hakre]

Replying to dd32:

Accepting this and marking as 3.2 for tracking purposes, Until the 3.2 scope meeting is done, no specific enhancements are a given.

Thanks for the traction, but please keep in mind that #16862 is for the Akismet and Hello Dolly Plugin only.

Related: #16838

[scribu]

The blessing: ​https://wpdevel.wordpress.com/2011/03/18/wordpress-3-2-the-plan-faster-lighter/#comment-17309

[dd32]

(In [17576]) Be a party-pooper; No more Akismet Dancing upon upgrade; Respect custom WP_CONTENT_DIR for bundled plugins/theme installation; Respect custom WP_CONTENT_DIR/WP_LANG_DIR for Language files when upgrading; Standardise WP_Filesystem path method returns (They're trailing slash'd). Adds an exclusion list to copy_dir() as well as WP_Filesystem_Base::wp_lang_dir(). See #14484 See #11495

[dd32]

(In [17577]) Typo in r17576, Twentyten isn't new to 3.2. See #14484 See #11495

[dd32]

Point of discussion:

• 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

[duck_]

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.

[dd32]

duck_: Yeah.. I realised that last night after signing off.

the WP_LANG_DIR code also won't work for 3.2 upgrades thanks to me only adding wp_lang_dir() in the same commit.

The downside of adding a "copy" of the function is that we can't just include it for 3.1-3.2, it needs to be available for every version since the Auto upgrades started.

My original attempt was pretty much duplicating copy_dir() in upgrade-core.php, which is what I think I'll have to revert it to using.

The skiplist makes it so much simpler.. but unfortunately makes it also not work for 3.2 upgrades.

[scribu]

Maybe we should accept that it will only work after 3.2, just like automatic upgrades started working only after manually upgrading to WP 2.7.

[dd32]

The alternative is:

 // 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

[nacin]

Replying to duck_:

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.

[dd32]

I strongly suggest we do exactly this.

It has the obvious downside that those who don't upgrade to 3.2 first will have the old bug re-introduced temporarily, but benefits the majority of users doing it that way.

[nacin]

Right, but it's not actually a regression for them, which is nice.

[dd32]

(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

[dd32]

(In [17581]) @ignore for _copy_dir(). Props duck_. See #14484

[ramiy]

Why not add this feature to 3.1.1 or 3.1.2 or any other minor release befor 3.2 ?

[dd32]

Why not add this feature to 3.1.1 or 3.1.2 or any other minor release befor 3.2 ?

point releases are maintenance releases only; they're designed to fix critical/security bugs & regressions. Major features/enhancements only go into the next major release.

[ramiy]

i know that. but it can solve the problem.

[hakre]

How do you ensure that bundeled stuff won't be installed if they are not found on disk?

[dd32]

How do you ensure that bundeled stuff won't be installed if they are not found on disk?

By only copying them if the introduced version was newer than the previously-installed version.

[strider72]

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.

[nacin]

It's not just reappearing plugins. It's also edited themes. Also, we're now detecting custom content directories and upgrading those, I believe.

[travisnorthcutt]

Not to mention many (most?) users don't (and likely don't know how to/don'w want to) use a custom wp-content directory.

[dd32]

(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

Opened a new ticket for tracking this #17173

[dd32]

(In [17736]) Include TwentyEleven in the 3.2 upgrade process. Props markmcwilliams. See #14484

[dd32]

Believe this can be closed for 3.2 now.