[wp-trac] [WordPress Trac] #17173: Review the usage of _copy_dir() introduced in #14484

[WordPress Trac]

#17173: Review the usage of _copy_dir() introduced in #14484
-----------------------------+-----------------------
 Reporter:  dd32             |       Owner:  dd32
     Type:  defect (bug)     |      Status:  accepted
 Priority:  normal           |   Milestone:  3.2
Component:  Upgrade/Install  |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  3.3-early        |
-----------------------------+-----------------------

Comment (by nacin):

 I spent a long time with a giant whiteboard with koopersmith and PeteMall
 at WordCamp Reno dealing with some of the roadblocks I've been hitting
 implementing a new API and build process.

 While working on the new API, I had been under the impression that we
 could just wire in the new no-plugins-no-themes zip into the existing API
 version, and avoid our _copy_dir() hack for 3.2.

 The issue is that our current API is inadequate. Here it is:
 {{{
 upgrade
 http://wordpress.org/download/
 http://wordpress.org/wordpress-3.1.3.zip
 3.1.3
 en_US
 4.3
 4.1.2
 }}}

 In particular, on update-core.php, there's a button to download the newest
 version. It presumably once linked to /download/, the second line
 returned. But it now links directly to the zip, which is where we'd need
 to shoehorn in our own custom zip. So you see the problem: The same URL is
 used for two different things. No shoehorning allowed.

 So, here is what I am doing and proposing:

  - I have been working on a new build script on WP.org for content-less
 builds and also partial builds. This is quite complicated, as there's an
 entirely different build process for languages as well. The main one
 should be done soon, and I'm still looking into the languages
 complication. At worst, we flip a switch when that is done.

  - We need a new API. We were going to do this for partial builds anyway,
 but we need one now. So, I'll be posting a patch to switch over to /1.6/
 hopefully as early as today, which will be a serialized response that can
 scale to support partial builds, and importantly will support content-less
 builds.

  - We need to leave _copy_dir() in for one or two release cycles. We can
 leave this in now for the immediate 3.1 to 3.2 (maybe 3.3) benefit. It
 isn't grandfathered code we need to keep forever -- it's okay if someone
 updating from 3.1 to 3.4 (or 3.3) gets their Akismet and Hello Dolly
 stomped on.

  - Partial builds require some changes to core, particularly due to a
 decision we made on md5'ing files. Otherwise, it's just the matter of
 choosing a zip to download. I have code from dd32 that I've been massaging
 into a patch. My goal is to have everything working by tomorrow.

 So, for 3.2, here's what I'm potentially thinking:

  - Leave in _copy_dir().

  - Have a new API that returns whatever we need or will need. Just a
 matter of wiring it in.

  - No UI changes at this time.

  - No partial build support. However, we'll have the ability to tell core
 to instead use the partial build URL through a temporary constant or
 filter. Thus we can test this through the 3.2.x cycles, and include md5
 checking in 3.3.

 That said:

 The new API, once fully functional, can be wired in at any time. Can
 probably do it today. But if partial builds are near and dear to anyone,
 then you're either out of luck or we need to scrap md5 implementation as a
 project requirement.

 I think md5 is a nice-to-have, rather than a requirement. A button "Update
 to latest" can trigger the partial build, and "Full re-install" would
 trigger a full upgrade/reinstall. This would be easy to implement -- it
 requires the new API, which we're doing anyway, and a new button (if we
 can do a partial build).

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/17173#comment:9>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software