Given that Pods does not attempt to write to the DB for settings like these unless a form is submitted, I wonder if there’s something else going on here that’s interfering.
Here are a few more ideas I had for you to look around at:
* Check for add_option() or update_option() calls in your code to see if that setting name is somehow written to somewhere
* Check for pods() or pods_api() calls in your code to see if that setting pod / field is somehow written to somewhere
* Check for other options, is this happening for any other options outside of Pods?
* Do you have open tabs in your browser with the setting form open, perhaps something is going on there with a browser extension?
Thank you so much @sc0ttkclark for helping out. I’ll grep search through all running plugins to see if I can find the conflict.
(This specific pod is the only affected one. Other pods are never affected. Neither are other custom options I’ve added without Pods Framework.)
I’m finally one step closer. I made sure that no other plugin tries to edit the settings for the affected custom settings page pod. I also created a brand-new custom settings page pod for a custom post type, which turned out to lose it settings in the same way. I then cloned the whole site and experimented with different settings for Pods performance. I both found settings that work (!) and narrowed down potential settings that can cause the conflict.
Here are the settings that do not cause the issue.
- Watch changed fields for use in hooks: Disable watching changed fields
- Watch WP Metadata calls: Enable watching WP Metadata calls
- Override WP Metadata values: Enable overriding WP Metadata values
Here are the settings that do cause the issue.
- Watch changed fields for use in hooks: Enable watching changed fields
- Watch WP Metadata calls: Disable watching WP Metadata calls
- Override WP Metadata values: N/A
I’m not sure which of these settings that actually causes that issue and which plugin I’m running that interferes with Pods. My next step is to clone the site again and this time only change Watch changed fields for use in hooks.
Thank you for your efforts in finding the conflict here!
I have some bad news. The issue occurred again on a site even though I had the above-mentioned settings. I’ll update the thread again as soon as I have another clue about what’s going on. It may or may not be related to another seemingly randomly occurring issue: Pod’s tabs disappeared after update.
Hi @karlemilnikka
While this could be way to easy, could you check your browser console for JavaScript errors?
Cheers, Jory
Absolutely. I’ll check that the next time it happens.
Hi @keraweb.
I found a cloned site copy where the issue had occurred as well. There are unfortunately no errors in the console. Just like before, running Pods repair shows no issues even though the data is missing in the database.
I’ll update this thread again as soon as I have another clue of what might be going on.
Just a thought.. Could this be related to the cache issues from you other thread?
https://wordpress.org/support/topic/pods-tabs-disappeared-after-update/
@keraweb Maybe. I’m keeping daily track of when/if any of the two issues occur. The next time one of the occurs, I’ll check if the other has occurred as well.
Unfortunately, the issue with missing tabs occurred today without my Custom Settings Pages losing their data. The issues do not share a common cause, @keraweb.
For bypassing readers: The consequences of my issue with Custom Settings Pages losing their data can be avoided. The reason I still maintain this thread is just to find the underlying cause. It’s most likely caused by a plugin conflict.
@sc0ttkclark has already found the solution to the issue with missing tabs.
This is just a quick follow-up. The issue hasn’t occurred for more than two months now. That’s of course a good thing, but unfortunately, we will probably never get to know what caused it.
Hi @karlemilnikka
Thanks for the follow-up here! Indeed good to hear that it didn’t occurred again. I guess some change in your installation fixed it, however, if it does occur again, let us know!
Cheers, Jory
