Flush Cache button (orange instead of blue)

  • Resolved csmicfool

    (@csmicfool)


    8 years, 7 months ago

    On one of my installs, the “Flush cache” button is blue. On another install, it’s orange.

    What do the different colors mean?

    I tried to flush cache with the instance running w/ orange button and it appears to have lost some wp_post_meta data. Unsure if this is related or not, my team and I are still trying to find root cause of the data loss.

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter csmicfool

    (@csmicfool)

    8 years, 7 months ago

    Are the colors just different wordpress versions? I see in one version button-primary is blue, orange in the other. The class is from WP, not the plugin.

    Plugin Author Till Krüss

    (@tillkruess)

    8 years, 7 months ago

    The “Flush Cache” and “Enable Object Cache” buttons are suppose to be always blue, just like all other primary buttons in WordPress.

    The “Disable Object Cache” button is always suppose to be red.

    If the buttons have other colors, it’s probably your theme or more likely another plugin overriding loading CSS where it shouldn’t. You could try disabling all plugins one by one and checking if the original button color is restored.

    Regarding the data loss, all the “Flush Cache” button triggers is a wp_cache_flush() call, which will only delete your object cache (Redis) and does not touch your database (MySQL) at all.

    • This reply was modified 8 years, 7 months ago by Till Krüss.
    Thread Starter csmicfool

    (@csmicfool)

    8 years, 7 months ago

    Thanks for the feedback. No clue what’s changing the button color, quite odd. I assumed it meant something was configured wrong.

    We traced the issue down to a strange emoji character (thumbsup) from user input which passed json validation and didn’t get encoded, but choked under serialization. Removing the stray characters restored all of the data w/ next sync.

    Do you have any advice regarding serialization? Are there params within the plugin or is it purely up to the phpredis/predis client?

    Plugin Author Till Krüss

    (@tillkruess)

    8 years, 7 months ago

    Could you elaborate on that? Did MySQL or Redis choke on the emoji? If it was Redis, what table/coloum was the emoji stored in? What’s the Unicode for the emoji?

    Thread Starter csmicfool

    (@csmicfool)

    8 years, 7 months ago

    The character is “👍”

    Encodes as \ud83d\udc4d

    stored in wp_postmeta, mysql using utf8mb4, and redis clients should be using igbinary

    Plugin Author Till Krüss

    (@tillkruess)

    8 years, 7 months ago

    Okay, thanks!

    Right now this plugin only uses PHP’s serialize() method.

    You’re welcome to submit a pull request to the GitHub repo: https://github.com/tillkruss/redis-cache

    Thread Starter csmicfool

    (@csmicfool)

    8 years, 7 months ago

    Thanks for the info.

    Repo shows it’s using maybe_serialize() which is the WP way to do it. Should be good since it won’t double-serialize.

    The issue came up again today with a different character (umlaut) in wp_options table.

    What we were able to diagnose was that there appeared to be some discrepancies in how each server in the farm was serializing/de-serializing. We also saw that serialized values in options.php could be retrieved ok because it wasn’t being pulled from the object cache, but get_option() was failing to load it and returning a null value without logging an error because it does use the object cache.

    Updated all servers to use phpredis (pecl) w/ igbinary enabled for PHP (still not 100% sure if that’s being used in the path to redis or not but I followed whatever documentation I could find for our oldass servers). Then flushed the redis object cache and was no longer able to reproduce in the same way.

    • This reply was modified 8 years, 7 months ago by csmicfool.
Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘Flush Cache button (orange instead of blue)’ is closed to new replies.