We had one setting to change and took the fastest route: write it straight into the database.
The write succeeded. A SQL query showed the new value. The site was still reading the old one.
The symptoms sent us the wrong way
That setting decides which theme the site runs. With the old value, the new theme never loaded at all. No styles, no functions, and the front end fell back to the default look.
That looks exactly like “the new theme has an error, so the system fell back to the default theme.” We did go down that path for a while, checking the syntax, the required files and the format of the theme declaration one by one. All fine.
How to tell them apart
Eventually we asked the system two different questions. Does this theme have any errors? Is it in the system’s list of themes?
No errors, and it’s in the list, so it isn’t broken. The problem wasn’t the theme or the database. Something between the two was in the way.
That something was the persistent object cache. When the site reads a setting it asks the cache first, and if the cache has a value it never goes to the database.
Two things
First, after any write that bypasses the application, clear the cache.
Second, after clearing it, verify from a separate process. In the original process, the theme’s styles and functions had already loaded before the cache was cleared, so checking right there still comes back empty and you’ll think clearing did nothing. We fell into that one too.
Writing to the database directly isn’t a mistake, and neither is taking a shortcut. That time we just forgot that by skipping the application, we’d also skipped the step where it clears the cache for you.
