Forum Replies Created

Viewing 2 replies - 1 through 2 (of 2 total)
  • Thread Starter sebastienvercammen

    (@sebastienvercammen)

    @scribit weForms shortcodes now work. I’ve updated my review (see score + text at the top). Thanks for being responsive.

    Thread Starter sebastienvercammen

    (@sebastienvercammen)

    Hey @scribit – a review is a personal opinion about an experience. I think it’s reasonable to give it 1 star when just installing it can cause the admin dashboard to no longer work at all. I’m lucky to be technical enough to get involved, but others might not be, so that’s why I find a 1-star review reasonable. Reviews are something they see before installing, support tickets in progress are not.

    Now, what I’ve done since then to try to help you out:

    1. var_dump of the delete_option to make sure it was succeeding. It was, no problem found.
    2. Installed a brand new website w/ a clean WordPress from scratch + installed all the same versions (all latest) of the exact same plugins, including caching layers and Let’s Encrypt SSL certificate. The tried installing Shortcodes Finder. The problem did not reoccur.
    3. Then I went back to the original website on which the problem occurred to reinstall Shortcodes Finder and see the error in action again.

    And here’s the thing…

    The problem went away.

    The original website can now install and use Shortcodes Finder without any issue at all. Reinstalling does not make the problem go away.

    For reference, I’m the hoster, so I can guarantee there have been no changes whatsoever except my manual debugging tests.

    I did some more digging:

    1. WordPress source code of add_option shows that they call wp_cache_set on line 675 here. This is the mechanism that adds the option.
    2. wp_cache_set source code calls the global object cache.
    3. Remember my original post: I’m using Redis Object Cache. So I dove into that source code.
    4. Which brings us to a custom set() for the global cache instance. Followed by a set() on the redis instance. Which is using PhpRedis, in which we can find a reference to set() in the PHP stub that’s implemented in set() in the C code. This maps to Redis’ (the actual cache engine) SET operation.

    At this point, the documentation mentions that a key can only exist once, so that’s validated.

    Then I did the reverse, for WordPress’ delete_option:

    1. Calls wp_cache_delete
    2. Calls $wp_object_cache->delete
    3. Calls Redis Object Cache’s delete
    4. Calls PhpRedis’ del
    5. Calls Redis’ DEL operation, which we can find in the Redis docs here

    And all of it seems straightforward. I didn’t find anything suspicious at first sight.

    So I’ve updated my review to 4 stars. I couldn’t find the source of the problem, but that doesn’t mean it didn’t (or won’t) happen – and it’s still unfortunate that it doesn’t recognize the weForms shortcodes. If those things were solved, it would get 5 stars.

Viewing 2 replies - 1 through 2 (of 2 total)