[wp-trac] [WordPress Trac] #34306: Twenty Sixteen as default theme

[WordPress Trac]

#34306: Twenty Sixteen as default theme
----------------------------+-----------------------
 Reporter:  SergeyBiryukov  |       Owner:
     Type:  task (blessed)  |      Status:  assigned
 Priority:  normal          |   Milestone:  4.4
Component:  Bundled Theme   |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  has-patch       |     Focuses:
----------------------------+-----------------------
Changes (by nacin):

 * keywords:   => has-patch


Comment:

 I have thought about this for a while now, and even nearly drifted off to
 sleep the other night trying to rack my brain on how to address this
 (@helen can attest). I have discovered a truly marvelous solution of this,
 which this margin is too narrow to contain.

 No, I'm kidding. I think I got it. [attachment:34306.2.diff] reworks how
 we use `WP_DEFAULT_THEME`. [Note: While @dd32 and I have studied the patch
 and its approach, it is untested.] `WP_DEFAULT_THEME` is typically used
 for falling back to or setting a default theme. The key is it needs to
 exist. WordPress until now has always assumed it existed, which was
 already an imperfect assumption, as the newest default theme could have
 been deleted after being installed.

 So normally what we'd want to do here is one of two things:
  1. Set `WP_DEFAULT_THEME` by default to false, then when we need to,
 just-in-time check to see what is installed. This doesn't work because
 `WP_DEFAULT_THEME` has always been assumed by both core — and thus
 presumably plugins — to be the name of a theme. We shouldn't break that
 assumption.
  2. Set `WP_DEFAULT_THEME` by default to the latest default theme that is
 installed. This doesn't work because we'd need to hit the filesystem to
 determine this, and we definitely don't want to hit the filesystem in this
 situation.

 So instead, we must do a third option:
  * Set `WP_DEFAULT_THEME` to the latest default theme. In this case, it
 would be `twentysixteen`.
  * However, it may not always exist — it could be deleted after a new
 install, it could be not installed during upgrade, it could be set to an
 invalid identifier, etc.
  * Thus, every time we want to use it, we must verify its existence, and
 if it does not exist, then we must fall back to the latest core default
 theme that is installed. This could very easily be Twenty Fifteen, or it
 could be Twenty Ten, or it could be Kubrick.
  * But, if none of them are installed, well, we're in an interesting
 situation. What do we do? In the case of `validate_current_theme()`, we
 should do nothing — we don't have a valid theme to switch to, so we'll
 have to stay with our invalid theme. In the case of `populate_options()`
 (for an initial blog), we can simply instantiate the site with
 `WP_DEFAULT_THEME` — which is what we already did previously when the
 theme didn't exist (we didn't check). This would only really come into
 play in multisite. cc @jeremyfelt. I think it's past the point where we
 add UI to set a network default theme. Before then, should we possibly
 choose a theme that is "allowed" for the network, since we can presume
 those exist?
  * Finally, `WP_DEFAULT_THEME` is used in some incredible (and incredibly
 old) code that takes a pre-1.5 template directory, wp-layout.css file,
 etc., and turns it into a real WordPress theme. It'll actually continue to
 work (yes, I thought this out) since someone updating from 1.2 or earlier
 (presumably one of us trying to be funny) will need to download the zip
 and copy over the core files, which includes moving the new wp-content
 directory into place.

 Additionally, the patch does *not* install Twenty Sixteen on upgrade. It
 still allows this to happen by listening to an explicit define of
 `CORE_UPGRADE_SKIP_NEW_BUNDLED` as `false`. I think we could probably wrap
 all default themes in that check, otherwise if you're upgrading from 4.0,
 you will get Twenty Fifteen but not Twenty Sixteen.

 Again, note, patch not tested. Also, as @helen indicates above, this
 should be done in two commits, leaving the `WP_DEFAULT_THEME` change to
 `twentysixteen` for the second commit, and propping everyone who
 contributed. It's not that we couldn't include them all in the credits
 either way, it's that it's still cool to see your name here.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/34306#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform