[wp-trac] [WordPress Trac] #59633: Ensure theme files caching mechanisms are filterable and caches can be manually cleared

[WordPress Trac]

#59633: Ensure theme files caching mechanisms are filterable and caches can be
manually cleared
--------------------------+--------------------
 Reporter:  aferciaWhile  |      Owner:  (none)
     Type:  defect (bug)  |     Status:  new
 Priority:  normal        |  Milestone:  6.4
Component:  Themes        |    Version:  trunk
 Severity:  normal        |   Keywords:
  Focuses:  performance   |
--------------------------+--------------------
 Splitting this out from #59591.

 #59591 surfaced the need of a broader, holistic discussion about theme
 files caching mechanisms. While caching is of course a welcomed
 performance benefit, it may introduce problems as pointed out in #59591.

 Some of these problems will be mitigated by https://github.com/WordPress
 /wordpress-develop/pull/5462 and https://github.com/WordPress/wordpress-
 develop/pull/5495

 However, there are scenarios where the caches won't be cleared, thus
 leading to potential PHP notices / warnings or non functional UI.

 So far, theme files caching consists of a few parts:

 - Caching of data from theme pattern files.
 - Other instances of cached theme files are already in core, as mentioned
 in https://core.trac.wordpress.org/ticket/59591#comment:24
 - A similar caching mechanism is in the works for template files.

 Typically, the caches will be invalidated when:
 - There is a theme update.
 - The theme version is new.

 However, #59591 highlighted that there are legitimate scenarios and user
 flows where the caches will not be cleared out. For example. when adding /
 deleting / renaming pattern files via FTP. This potentially applies to any
 other cached files.

 Scenarios I could think of so far:

 **Incomplete themes updates**
 A theme update is unsuccessful ending up with incomplete / corrupted files
 or missing files. This is not uncommon especially for themes with a large
 amount of files, as the files write operation may simply fail. In these
 cases it's a common practice to upload the theme via FTP. Likely,
 WordPress won't understand the theme is 'new' and caches won't be cleared.

 **Hosting companies providing a staging environment**
 If the staging environment is provided by simply copying production to
 staging, I'm not sure the caches will be cleared and I'm not sure what
 would happen. Anyways, this seems to be a scenario that hasn't been
 considered in the current implementation.

 **Professionals and web agencies that manage sites for their customers**
 They may want to provide custom pattern files to their customers by simply
 uploading the pattern file via FTP. Caches won't be cleared.

 To my understanding, any flow that bypasses a theme update via the
 WordPress admin and a theme version compare would not clear the caches.

 There's likely several scenarios where this may happen that I can't think
 of at the moment. Any additional case and concerns are welcome in the
 comments below.

 As of now, these caching mechanisms can't be disabled other than setting
 the `WP_DEVELOPMENT_MODE` constant to `theme`. However, this constant is
 meant for developers. Users, site owners, site managers, and even agencies
 or hosting companies are not required to know what this constant is. In
 some cases they could not have the ability to change it anyways.

 There may be cases where users (in the broader sense: final users,
 agencies, hosting companies etc.) would also want or need to disable
 caching entirely. To my knowledge, as fo now there is no way to disable
 it.

 I'd like to invite everyone to better consider the current implementation.
 So far, I could think of a couple things:

 == Filters
 I'd tend to think _any_ caching mechanism should be filterable in order to
 disable it. Ideally, there should be a filter to disable any caching
 everywhere and then a series of more granular filters to disable specific
 caching (e.g. only patterns, only templates, etc.0.

 == Provide a way to clear caches in the UI
 It appears there are legitimate cases where users would need to manually
 clear the caches. As mentioned above, this need may arise when theme files
 are updated outside of the WP admin. Such an UI control could offer a
 quick, easy, way to solve any caching problem.

 Overall, I'd think the work done so far has been remarkable and it is for
 the greater good of performance. However, performance should never come at
 the cost of breaking legitimate user flows or, even worse, potential
 breakages. In this regard, I'm not sure all the potential scenarios have
 been considered and I'd recommend extreme caution with the introduction of
 this feature in Core.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/59633>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform