Opened 14 years ago
Closed 14 years ago
#14484 closed task (blessed) (fixed)
Make WordPress core updates only update the core
Reported by: | mtekk | Owned by: | 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)
#2
@
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
@
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
#5
follow-up:
↓ 6
@
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
@
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.
#11
@
14 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.
#16
@
14 years ago
- Keywords 3.2-early added; core hello dolly removed
- Owner set to dd32
- Status changed from new to accepted
#17
follow-up:
↓ 18
@
14 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.
#20
@
14 years ago
- Keywords 3.2-early removed
- Milestone changed from Future Release to 3.2
- Type changed from enhancement to task (blessed)
#21
@
14 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
#23
follow-up:
↓ 37
@
14 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:
↓ 29
@
14 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.
#26
@
14 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
@
14 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.
#28
@
14 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
@
14 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
@
14 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.
#34
@
14 years ago
Why not add this feature to 3.1.1 or 3.1.2 or any other minor release befor 3.2 ?
#35
@
14 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.
#37
in reply to:
↑ 23
@
14 years ago
How do you ensure that bundeled stuff won't be installed if they are not found on disk?
#38
@
14 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
@
14 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
@
14 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
@
14 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.
Not really sure what you're getting at. What exactly is touched in wp-content when updating, currently?