[wp-trac] [WordPress Trac] #60290: Changeset #56635 breaks template loading in multisite network using switch_to_blog()

[WordPress Trac]

#60290: Changeset #56635 breaks template loading in multisite network using
switch_to_blog()
-------------------------------------------------+-------------------------
 Reporter:  metropolis_john                      |       Owner:  joemcgill
     Type:  defect (bug)                         |      Status:  reopened
 Priority:  normal                               |   Milestone:  6.5
Component:  Themes                               |     Version:  6.4.2
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests changes-    |     Focuses:
  requested 2nd-opinion                          |  performance
-------------------------------------------------+-------------------------
Changes (by manfcarlo):

 * keywords:  has-patch has-unit-tests => has-patch has-unit-tests changes-
     requested 2nd-opinion
 * status:  closed => reopened
 * resolution:  fixed =>


Comment:

 As flagged in comment:11, the solution committed here is not tested with
 template parts that use `get_theme_mod` or `get_template_directory_uri`.
 Many template parts use these. For example, the `header.php` in
 [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 content/themes/twentyeleven/header.php Twenty Eleven],
 [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 content/themes/twentytwelve/header.php Twenty Twelve] and
 [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 content/themes/twentyfourteen/header.php Twenty Fourteen] use
 `get_template_directory_uri` for the HTML5 polyfill. The Twenty Twenty-One
 [https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-
 content/themes/twentytwentyone/template-parts/header/site-branding.php
 site-branding.php] and [https://github.com/WordPress/wordpress-
 develop/blob/trunk/src/wp-content/themes/twentytwentyone/template-
 parts/header/site-header.php site-header.php] use `get_theme_mod` to
 conditionally output markup based on the presence of a theme mod.

 With the solution committed, if blog A has Twenty Twenty-One and blog B
 has another theme, such as a block theme, switching from blog A to blog B
 will fetch the template part from Twenty Twenty-One but fetch the theme
 mods from the block theme, which likely doesn't use theme mods, so Twenty
 Twenty-One's conditional markup will never output, even if the theme mod
 is set and it would have output without the blog switched.

 If blog A has Twenty Eleven, Twenty Twelve or Twenty Fourteen, switching
 from blog A to blog B will fetch the header from the old theme but
 generate the HTML5 polyfill URI for the block theme, which likely doesn't
 have an HTML5 polyfill and is likely to generate a 404 error.

 The scenarios above are clearly bugs. For a long time, these bugs were
 difficult to fix because of the use of the `TEMPLATEPATH` and
 `STYLESHEETPATH` constants. 6.4 prevented these bugs if not fixed them.
 The patch committed reinstates these bugs.

 Understandably, this ticket was opened on the basis of reinstating long-
 standing behaviour. However, by the same token, a whole release cycle (4
 to 5 months) has passed since 6.4, and there is every chance that
 theme/plugin authors have since deployed code that relies on the 6.4
 behaviour, perhaps not being aware of the previous behaviour. They will
 not understand why 6.5 causes this breakage, especially since the patch
 has no documentation and the code is not very easy to interpret without
 locating the commit message. The last thing anyone wants is to give people
 a reason to downgrade from 6.5 to 6.4.

 If this is to be treated as a fix of a regression, the further things
 should be done:

 * committed to 6.4, as 6.4 introduced the regression
 * extra documentation added to explain why it works this way and warn
 against errors caused by `get_theme_mod` and `get_template_directory_uri`
 (see also #60332)
 * addition of a filter or similar to reinstate the previous 6.4 behaviour
 for those who need it

 It's clearly a matter of opinion whether 6.4 was a regression or not, so
 the extra work is better avoided and I would rather just revert. I don't
 see the evidence that the 6.4 behaviour is causing any major problems for
 anyone, other than encouraging them to improve their code.

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