[wp-trac] [WordPress Trac] #29618: Improve `is_child_theme` to check for a valid Template value in child stylesheet comment header

[WordPress Trac]

#29618: Improve `is_child_theme` to check for a valid Template value in child
stylesheet comment header
-----------------------------------+------------------------------
 Reporter:  lancewillett           |       Owner:
     Type:  enhancement            |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Themes                 |     Version:
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch 2nd-opinion  |     Focuses:
-----------------------------------+------------------------------

Comment (by nacin):

 Always happy to have other opinions.

 On a typical frontend load, WordPress does not actually perform any
 seeking operations from disk. The file headers for plugins, style.css, and
 translation PO files are only read when necessary, like when displaying a
 list of the available ones or when performing an update check.

 Activated plugins are cached as an array of PHP files to include. The
 theme is cached as a few DB options, up to four: stylesheet, template,
 stylesheet_root, and template_root.

 Hard drives can only do so many I/O operations per second. And that's
 assuming the disk is local. Hosts using NFS will not be super happy if we
 read the top of style.css every time trying to confirm a child theme
 really is a child theme.

 I think that `wp_get_theme()->parent()` is nicely named, and it returns
 the WP_Theme object when there is a parent, or false otherwise. And for
 more advanced usage, if the theme has an invalid parent, then
 wp_get_theme()->errors()->get_error_code() will return
 `"theme_no_parent"`. It's important to have these functions, but at the
 same time, it's important and helpful to be able to do things quickly.
 Most of the theme API does no filesystem verification, not just
 is_child_theme().

 And this is for a mismatch that shouldn't really happen in practice.
 What's the practical need for this? Something can indeed go wrong, but in
 most cases we can account for that. Maybe the theme editor should ensure
 that if "Template:" either appeared or disappeared, that 'template' is up
 to date. (At least I don't think it does now.) Ultimately the fact that
 things go wrong is ultimately why wp-admin/themes.php has
 validate_current_theme(). (In fact, one reason we only do this on wp-
 admin/themes.php is because intermittent I/O failures used to potentially
 cause a site to reset to Kubrick. This is not fun.)

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