We needed to change one setting, and we took the shortest route: write it straight into the database.
The write succeeded, and a query returned the new value. The application kept reading the old one.
The symptoms point the wrong way
That setting decides which set of styles is active. Reading the old value meant the new set never loaded. No styles, no functions, and the front end dropped back to its default look.
That looks exactly like “the new set has an error, so the system fell back to the default.” We spent a while down that path, checking syntax, required files and the declaration format. All fine.
The test
Ask the system two questions. Does that set have any errors? Can the system list it?
If there are no errors and it shows up in the list, it isn’t broken. The problem isn’t at either end. It’s in the middle: something is sitting between you and the database.
That something is the persistent object cache. When the application reads a setting, it asks the cache first, and if the cache has a value it never goes to the database.
Two rules
① After any write that bypasses the application layer, clear the cache.
② Then verify from a fresh process. In the same process, the styles and functions were loaded long before you cleared anything, so checking on the spot still comes back empty and you’ll conclude that clearing didn’t help. We made that mistake too.
The bigger lesson
Taking a shortcut isn’t the mistake. Forgetting what the shortcut skipped is.
Every layer of cache is a copy, and every copy is another chance to be lied to.
