[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.4.4
Component:  Themes                               |     Version:  6.4.2
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch has-unit-tests changes-    |     Focuses:
  requested fixed-major                          |  performance
-------------------------------------------------+-------------------------

Comment (by manfcarlo):

 Replying to [comment:30 joemcgill]:
 > After feedback from many longstanding contributors and component
 maintainers, including @swissspidy and @jeremyfelt, I decided to fix this
 bug.

 Replying to [comment:30 joemcgill]:
 > Based on your response, it sounds like your concern is theoretical
 rather than an issue that is affecting your project, whereas this issue
 was opened to address a change in behavior that was adversely effecting
 real sites. Now that this issue is solved, I'd encourage you to open a new
 issue to address the issues you've described here.

 My concern is that I am a heavy user of `switch_to_blog` and until this
 ticket was not aware of this behaviour with templates and template parts.
 I would have to think about it some more to determine if it affects my
 project.

 Prior to [57596], the use of a bulleted list in the documentation strongly
 suggested that plugins were the only thing not switched. Even the change
 to `PHP code loaded with the originally requested site, such as code from
 a plugin or theme` does not cover this because templates and template
 parts are not pre-loaded like `functions.php` and there is no structural
 reason that they can't be switched.

 Honestly, it's unlikely that I would open a new ticket at this stage, as I
 don't see how a new ticket would be able to achieve anything that this
 ticket can't, and more dead-end tickets is not what the project needs.
 However, seeing as you consulted with @jeremyfelt, who drafted the change
 to the documentation, it looks like #60332 will need to be re-opened to
 cover this.


 Replying to [comment:30 joemcgill]:
 > I agree with you that we should consider backporting this fix to 6.4 as
 well, so I've moved this to the 6.4.4 milestone for consideration, but at
 this time no other maintenance releases are planned for 6.4. If another
 maintenance release does not happen before 6.5, this should be closed as
 fixed.

 I see that there is one other ticket in the 6.4.4 milestone, there is a
 lot of demand for a new maintenance release, and a lot of the same
 arguments made over there also apply here:

 > We're going to get hundredes of calls asking us to rollback the change
 and this is going to cause a lot of pain both to our customers and to us.

 > This isn't a "new feature" to be added in a major version. This is a
 major bug to be patched in the major version it was introduced in.

 > Anyway, 835 million sites use WordPress. As of now 41,750,000 of those
 run WordPress 6.2. So millions of sites will have this bug for quite
 awhile if as many people continue to run 6.4 for as long as they have been
 running 6.2.
 >
 > The idea that this will go away in a few weeks in 6.5 is a fantasy. 6.5
 does not make this problem go away.

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