Plugin Author
Pedro
(@petredobrescu)
Hello @kittmedia and thanks for opening this thread
Starting with SPIO version 6, we have a new way of storing the settings, in a single option, rather than multiple options as we used to have until now. Therefore, the option wp-short-pixel-currentVersion is normal to remain updated because it isn’t used anymore in SPIO 6.
While we cannot reproduce the use case you described above, I could imagine that something like this could happen if the new settings are not saved for some reason and this is something we should look at closely. I hope it’s fine to contact you directly and check this situation on a site where we can reproduce the behavior, so we can add a proper fix. While your fix might solve the effects of the issue, it doesn’t solve the cause, because SPIO 6 doesn’t check anymore the old option, so something must be off there.
As always, we’ll get back here with an update when this is sorted out.
Thank you!
You’re right. It doesn’t fix the problem. It was a coincidence that the error that brought this behavior on my table didn’t occur for a couple of minutes after that.
Unfortunately, I cannot give you access to a site where this problem occurs.
However, after some more digging, I could at least get why the option has wrong data: For an unknown reason, the option is stuck in the alloptions cache key (we’re using https://github.com/Automattic/wp-memcached/ as Object Cache). After deleting this cache key ( wp_cache_delete( 'alloptions', 'options' )) and updating the spio_settings directly afterwards with our desired values, seem to be working now:
$ wp option get spio_settings
array (
'mediaLibraryViewMode' => 1,
)
$ wp eval-file update-script.php # script with cache deleting and updating the option
$ wp option get spio_settings
array (
'mediaLibraryViewMode' => 1,
[…]
'currentVersion' => '6.0.1',
[…]
)
This was, however, reproducible on all of our system running the above mentioned caching mechanism.
Plugin Author
Pedro
(@petredobrescu)
That’s an interesting find and thanks for the investigation @kittmedia!
If I read this correctly, the issue you mentioned only occurred right after upgrading to version 6? After alloptions everything works fine and the settings are saved correctly? We’ll do our best to test this with memcached and see if we can also replicate the same behavior.
Yes, it was after upgrading and yes, after doing the steps I mentioned above all works fine so far.
Plugin Author
Pedro
(@petredobrescu)
thanks for the confirmation @kittmedia!
We have tested this in multiple environments with memcached enabled, but weren’t able to reproduce it in any way. The install scripts run once after the upgrade, then we can’t see them anymore. Maybe there was also some interference caused by another active plugin and/or theme. On thing that came to mind during testing was if, by any chance, the shutdown hook doesn’t run, or similar. However, that might result in settings not being saved at all, since we do the actual save on shutdown.
In version 6.0.2 we included an object cache flush at the end of the install scripts, which normally should handle the situation you described with the alloptions being hanged. Do you still have an install with this behavior where you could test if 6.0.2 fixes this issue?
Do you still have an install with this behavior where you could test if 6.0.2 fixes this issue?
(Un)fortunately, no. I fixed all of them, so sorry that I can’t test it explicitly in such an environment. However, forcing a cache flush seems to be a good step, here.
Ha! I just found that one test instance is not yet fixed. So feel free to send the updated code so I can test. 🙂
Plugin Author
Pedro
(@petredobrescu)
Great, please update to version 6.0.2 as it already contains the proposed fix (the object cache flush at the end of running the install scripts).
I look forward to getting your feedback about this!
Yes, that version is now working properly, here. Thank you!
Plugin Author
Pedro
(@petredobrescu)
Great, thanks for the confirmation, Matthias!
