WP 5.5, child themes, customizer and a weird cache issue

Question

Update:

I created a fresh new installation of WordPress, copied both Base and Base Child themes and activated Base Child. The Appearance/Customize gives the same white screen as described in point 1 below.

I then activated Base and the Appearance/Customize screen has the same error, which did not occur on the previous WP installation. This leads me to believe I have an issue with my customizer code. I WILL get to the bottom of this.

---

I developed a custom theme, let's call it "Base", based on https://underscores.me/, which is the boilerplate for several other child themes. The Base theme features several theme mods accessible via the theme customizer. I also created a child theme of Base, A.K.A. "Base Child", right now containing only the style.css file, which is copied below:

/*
Theme Name: Base Child
Template: base
Theme URI: https://blabla.com/
Author: Me
Author URI: https://blabla.com/
Description: Base Child
Version: 1.0.0
Text Domain: base-child
Tags: custom-background, custom-logo, custom-menu, featured-images, threaded-comments, translation-ready
*/

The only plugins installed are:

1. ACF Photo Gallery Field
2. Advanced Custom Fields (the free version)
3. Simple Page Ordering

Everything works fine when the Base theme is activated, meaning all custom post types are there, the theme customizer works perfectly, all shortcodes behave like they should etc.

Things can be very confusing from now on, so please be patient with me. As soon as I activate Base Child, weird things start to happen:

1. If I go to Appearance/Customize, I get a screen showing only the "You are customizing Site Name" message and the page title is "Customizing: Loading..." forever. Nothing else works.
2. Related to point 1, a console inspection reveals this JS error on the page: Uncaught SyntaxError: Unexpected token '<' on customize.php on line 5240, and when looking at the page source, I'm finding what looks like a php error: Warning: sprintf(): Too few arguments in C:\wamp64\www\base-boilerplate\wp-includes\theme.php on line <i>1027</i>
3. Trying to replicate this issue with another theme, I installed Twenty Twenty and declared Base Child to be a child of Twenty Twenty in its style.css. I was amazed to see that all the custom post types created in Base were present in Base Child as a Twenty Twenty child. Going to Appearance/Customize, I get the same behavior as at point 1. It's as if Base Child was still a child of Base.
4. Clearing the browser cache has no effect on point 3.
5. Opening WP Admin in another browser not used before has no effect on point 3.
6. Activating Twenty Twenty and then activating Base Child (still as a child of Twenty Twenty) makes Base Child behave like a real child of Twenty Twenty. No more custom post types and Appearance/Customize works as expected. At this point, Base Child is activated.
7. Declared Base Child as a child of Base in its style.css. Went to the browser and it looks like Base Child is still a child of Twenty Twenty. No custom post types, no Appearance/Customize issues.
8. Activate Base, then activate Base Child as a child of Base: CPTs of Base appear, Appearance/Customize ceases to work as described in point 1.

I'm baffled. Looked everywhere, tried everything, nothing helped. It seems WP has a cache of its own, database related perhaps, otherwise I can't explain why the CPTs remain when I switch themes. It has nothing to do with browser cache.

Please help.

Answer 1

In WordPress the current theme and parent theme are stored in the database, as the template (parent theme) and stylesheet (child theme) options in wp_options. These are set when you activate a theme based on the activated theme's directory name, and the Template: header of the theme's style.css, if it exists.

These options are what's used to determine which directory to load files from, such as functions.php, and any files loaded with get_template_directory_uri() etc.

Since the parent theme is set when the child theme is activated, if you try to change the parent theme by editing the child theme's style.css after activating it, the parent theme will not change because the database still has the old value. You need to deactivate and reactivate the theme for any change to the parent theme to be recognised.

That covers points 3-8. Regarding the error in point 2, the JS error is almost certainly just caused by the PHP error. Judging by the line number, the PHP error seems to be being thrown by a use of get_theme_mod() with a default value (the second argument) that contains %s in it somewhere. If this is present then it's treated as a sprintf string and passed the parent theme and child theme URIs for some reason. It seems that if too many %s are present this will throw the error you are seeing. This line from the documentation might provide a clue:

If the modification name does not exist, then the $default will be passed through sprintf() PHP function with the template directory URI as the first string and the stylesheet directory URI as the second string.

I honestly have absolutely no idea what on earth this is for, and can't find any mention of, or discussion about, this behaviour.

Answer 2

I found the culprit.

I have several theme mods in my customizer code, one of them being the footer text that features a few "variables" like %year% and %site% in the default value, to be replaced with the actual values in the frontend. As soon as I replaced them with {{year}} and {{site}} things started to work normally.

Looking back at the sprintf() PHP warning I received, naming my variables using the % sign generated the mayhem, especially the %site% which begins with a %s, that was passed to sprintf() as Jacob mentioned:

If the modification name does not exist, then the $default will be passed through sprintf() PHP function with the template directory URI as the first string and the stylesheet directory URI as the second string.

So sprintf() received an extra %s, without the expected argument. The warning was generated inside an inline JavaScript, thus breaking the syntax.

So, if you want to use variables or text placeholders in the $default value of a theme mod, avoid using % as delimiters...