Hi @karlemilnikka
This sounds like a possible plugin conflict. Maybe your settings name is conflicting? Or maybe it could be a cache issue?
Cheers, Jory
Thank you very much for the reply, @keraweb. I’m currently investigating if it could be a Redis cache issue. I’ll update the post if I find out anything.
Hi @karlemilnikka
I was wondering whether you have an update for us on this topic. Let me know!
Cheers, Jory
Hi @keraweb. Thanks for following up. Not yet. It has happened once again, but I still don’t know what caused it.
Hi @karlemilnikka
Thank you for letting me know. I’ll close the ticket for now. In case you might indeed find the conflict and it’s Pods related then please file a bug report with all details for us to reproduce.
pods.io/submit
Thanks! Jory
This is just a quick update. I haven’t found out what’s causing the issue (yet). I’m just adding more information in case anyone else is experiencing the same issue.
Earlier today, Pods lost the settings again. Just like before, the pages were still set in wp-admin but they couldn’t be retrieved by calling get_option( ‘field_name’ )[0] until I had resaved the custom settings page. Our other custom settings pages weren’t affected. Clearing Pods cache didn’t help. Neither did running the repair process.
(Since the last time this happened, we’ve moved from an Apache server on Cloudlinux to a Litespeed server on Ubuntu. We’ve also replaced Krüss’ Redis plugin with Litespeed Cache’s integrated Redis plugin.)
Very interesting issue here, did you already submit this as a bug that I can look over the full details on?
A couple of minutes later, I actually have some insights to share (@keraweb). I still don’t know what’s causing the bug. I do however have a solution.
There are two ways to retrieve a setting from a custom settings page: the WordPress way and the Pods way (documentation). It’s just the WordPress way that’s affected. I tested this on a copy of our site with Pods Framework as the only running plugin.
When the problem occurred, the WordPress way stopped working until I had re-saved the custom settings page.
get_option( 'opal_pages_academy_settings_general' )[0];
The Pods way still works just like it’s supposed to.
$settings = pods('opal_pages');
$settings->field('academy_settings_general')['ID'];
@sc0ttkclark. Thanks. I haven’t submitted a bug-report yet since I haven’t found a consistent way to reproduce the issue. I’ll do that as soon as I’ve found a reliable way to do so.
This is another quick update with a little more information. When the issue occurs, the options are actually missing from the _options table. As soon as I resave the settings page, all options are added back to the _options table (with new IDs).
On my mission to find what’s causing the issue, I’ve now removed all multi-choice options and all listings for LearnDash’s post types, since that’s two major differences between the settings page that loses the settings and the settings pages that don’t.
I’ll update the thread again in 30 days with the result.
We didn’t have to wait 30 days. When I woke up today, the settings were lost again.
Can you find what actions were done this night? Maybe a server update?
@keraweb, I really wish I could find it. I didn’t update the server that night. There are no traces of any changes in WP Activity Log Pro and I can’t find any cronjobs that trigger the issue. I’ll post more information in this thread as soon as I have any.
(Please note that I’m not posting here to get support from you and your amazing colleagues. I’m just posting here in case anyone else is experiencing the same issue. I’ll submit a ticket as soon as I have any usable information regarding this plugin and/or server compatibility issue.)
