Viewing 6 replies - 1 through 6 (of 6 total)
  • Plugin Author Pedro

    (@petredobrescu)

    Hello Matthias,

    We’ve been trying to identify what could cause this, but we have no answer at the moment, without being able to reproduce it in our test environments. There is no real change in this aspect between versions 6.0.2 and 6.0.3, the cache flush was introduced in version 6.0.2. I tend to believe the actual plugin update (which changes the version) is somehow triggering continuously both ShortPixelPlugin ::check_plugin_version() and InstallHelper::activatePlugin(). Something seems to prevent the plugin version from getting updated correctly on your setup. If you still have a site where this is reproduced, can you send us the content of the spio_settings option from the options table?

    Thread Starter Matthias Kittsteiner

    (@kittmedia)

    You’re right, it doesn’t seem to be related to any explicit change from 6.0.2 to 6.0.3. The issue remains the same as before, where the settings are not readable and thus the version check always triggers InstallHelper::activatePlugin() again.

    However, I think I’ve got the problem. I’ve used the filter pre_option_spio_settings to apply default settings to all sites in our multisite. Unfortunately, this is the wrong filter, as it doesn’t allow accessing the original value (which I tried to migrate in my default settings). Thus, the currentVersion key was not available to the plugin. I now changed the filter to option_spio_settings and it works quite well so far.

    There’s still a problem that the cache may not properly update, but I tracked that down and currently can’t find the reason for it. It seems to be outside of plugin territory, though, since the update in update_option works fine, but subsequent requests, it’s empty again. However, this is currently just a small subset of sites that are affected by this and the following script seem to work to delete the faulty entry:

    $options = \wp_load_alloptions();
    unset( $options['spio_settings'] );
    \wp_cache_set( 'alloptions', $options, 'options' );

    It only updates the cache because the database entry is fine. However, I’m not sure why this entry seems the only one that won’t be properly updated if part of the alloptions.

    Plugin Author Pedro

    (@petredobrescu)

    @kittmedia can you please tell me how was the update to 6.0.4? Were there any issues this time?

    Reading your last reply makes me think about removing the object cache flush after the install scripts are executed, to avoid other issues.

    Thanks, I’m waiting for your confirmation on this, to know if we can close this ticket as well.

    Plugin Author Pedro

    (@petredobrescu)

    Hello @kittmedia

    I want to follow up on this ticket and ask if you are still having any issues. If not, I’d like to mark this ticket as resolved.

    Thank you!

    Thread Starter Matthias Kittsteiner

    (@kittmedia)

    Unfortunately, I still had the problem when not using a filter to forcefully overwrite the saved version in the settings option. However, we moved to another plugin to optimize our images, though. So even if the problem persists, we don’t need help anymore.

    Thank you for your effort!

    Plugin Author Pedro

    (@petredobrescu)

    Hello Matthias,

    I’m sorry to hear that and I’m glad that you found a solution for your image optimization needs. We’ll be here if you think about using our services again.

    All the best!

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

The topic ‘Too much cache flushing’ is closed to new replies.