Make WordPress Core

Opened 14 years ago

Closed 13 years ago

#14484 closed task (blessed) (fixed)

Make WordPress core updates only update the core

Reported by: mtekk's profile mtekk Owned by: dd32's profile dd32
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.0.2
Component: Upgrade/Install Keywords: needs-testing
Focuses: Cc:

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

Change History (44)

#1 @scribu
14 years ago

  • Keywords reporter-feedback added

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

#2 @nacin
14 years ago

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.

#3 @dd32
14 years ago

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

#4 @mikeschinkel
14 years ago

  • Cc mikeschinkel@… added

#5 follow-up: @bergius
14 years ago

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.

#6 in reply to: ↑ 5 @nacin
14 years ago

  • Keywords reporter-feedback removed

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.

#7 @nacin
13 years ago

  • Keywords 3.2-early added
  • Milestone changed from Awaiting Review to Future Release

#8 @nacin
13 years ago

  • Keywords 3.2-early removed

#9 @ramiy
13 years ago

  • Cc ramiy added

+1

#10 @Denis-de-Bernardy
13 years ago

  • Cc Denis-de-Bernardy added

#11 @jb510
13 years ago

  • Keywords core hello dolly added
  • Version set to 3.0.2

+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.

#12 @computerwiz908
13 years ago

  • Cc computerwiz908 added

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

Last edited 13 years ago by computerwiz908 (previous) (diff)

#13 @toscho
13 years ago

  • Cc info@… added

#14 @hakre
13 years ago

  • Cc hanskrentel@… added

#15 @ptahdunbar
13 years ago

  • Cc trac@… added

#16 @dd32
13 years ago

  • Keywords 3.2-early added; core hello dolly removed
  • Owner set to dd32
  • Status changed from new to accepted

#17 follow-up: @dd32
13 years ago

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

#18 in reply to: ↑ 17 @hakre
13 years ago

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

#19 @hakre
13 years ago

  • Keywords needs-patch added

#20 @scribu
13 years ago

  • Keywords 3.2-early removed
  • Milestone changed from Future Release to 3.2
  • Type changed from enhancement to task (blessed)
Last edited 13 years ago by scribu (previous) (diff)

#21 @dd32
13 years ago

(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

#22 @dd32
13 years ago

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

#23 follow-up: @dd32
13 years ago

  • Keywords needs-testing added; needs-patch removed

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

#24 follow-up: @duck_
13 years ago

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.

#25 @travisnorthcutt
13 years ago

  • Cc travis@… added

#26 @dd32
13 years ago

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.

#27 @scribu
13 years ago

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.

Last edited 13 years ago by scribu (previous) (diff)

#28 @dd32
13 years ago

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

#29 in reply to: ↑ 24 @nacin
13 years ago

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.

#30 @dd32
13 years ago

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.

#31 @nacin
13 years ago

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

#32 @dd32
13 years ago

(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

#33 @dd32
13 years ago

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

#34 @ramiy
13 years ago

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

#35 @dd32
13 years ago

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.

#36 @ramiy
13 years ago

i know that. but it can solve the problem.

#37 in reply to: ↑ 23 @hakre
13 years ago

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

#38 @dd32
13 years ago

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.

#39 @strider72
13 years ago

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.

#40 @nacin
13 years ago

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

#41 @travisnorthcutt
13 years ago

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.

#42 @dd32
13 years ago

(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

#43 @dd32
13 years ago

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

#44 @dd32
13 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

Believe this can be closed for 3.2 now.

Note: See TracTickets for help on using tickets.