meta values not showing without hard-refresh

Hi @cjyabraham, thanks for letting me know.

The behaviour is strange, could you clarify me the following:

1. Does it happen only in CPT?
2. Are you using meta for the data type?
3. When you indicate “Go back” in 3, do you mean clicking the browser’s back button?
4. Have you noticed if the same behaviour happens in other parts of the editor (featured image, categories, tags, etc.)?
5. Just to confirm, are you using WordPress 5.3.2?

Thanks,
álvaro

Thanks for the quick reply.

1. I haven’t tried on non-CPTs as we don’t use this plugin on any. My guess is that it has nothing to do with CPT or non-CPT.
2. Yes. The code is here: https://github.com/LF-Engineering/lfevents/blob/master/web/wp-content/mu-plugins/custom/lfevents/admin/class-lfevents-admin.php#L897
3. Either clicking the browser’s back button or clicking on the CPT listing in the menu (eg. “All Events”). You can actually click around the wp-admin for a while and then go back to the new CPT and see that the data is not showing in the meta fields.
4. It does not appear to be a problem for the CPT’s categories, feature image, menu order and other built-in fields.
5. Yes 5.3.2 running in a Pantheon environment.

Thanks for the information.

I tried the steps you mentioned with the test cases that I have, but I couldn’t reproduce the issue.
I also tried with the plugin you linked but couldn’t reproduce it either.

Could you share a GIF or video so that I can try to reproduce it exactly in the same way with the plugin you are using?

Yes. Here is a video: https://drive.google.com/file/d/1B36L7-5K8-7fkcfrqN49REfgk70b7DIN/view?usp=sharing

Also, I could provide you with access to a test instance if you’d like to debug? Perhaps it has something to do with the way Pantheon has configured things…

Thanks.

Thanks for the video.

I followed the same steps but couldn’t reproduce the issue.
Could it be a conflict with another plugin or maybe some caching plugin?
Could you confirm the issue is still there if there is only post-meta-controls and your plugin active?

Sure if you point me to the repo I can try to test it, I am not familiar with Pantheon though.

I deactivated all plugins except for post-meta-controls and the MU plugin and tried again and it’s still a problem. Perhaps Pantheon is overly-aggressive with its REST call cacheing? Maybe something can be done to explicitly reset the cache?

• This reply was modified 5 years, 1 month ago by cjyabraham.

It sounds strange that the meta data is being cached but the rest of the content is not. But I am not familiar with Pantheon.

I sent you an email, lets see if I can figure out the issue.

It seems like in your site the WP core get_post_custom_keys is either not returning an array or not returning the current saved keys. The plugin understands this as if there is no previously saved meta data, so it sets the default_value in each field.

I haven’t been able to reproduce this in my enviroment, so it’s difficult to test it (the code). It could be that there is some kind of cache going on.

Could you test if the behaviour is the same publishing a post instead of saving it as a draft?

I am going to see if I can patch it in some way. I will keep you updated.

Thanks

Yes, it’s the same behavior when publishing as when saving.

I also just tested it on another site we are developing with a different theme and I get the same behavior.

Thanks.

Hi @cjyabraham,

I tried to use the same plugin you shared in a pantheon site I created to test the issue, and it works correctly for me. I noticed in your test site there are different plugins installed. Possibly one of the plugins is conflicting with this plugin (I tried some of them on my test site but couldn’t find any that created this conflict though).

Could it be some configuration of the server that is caching the database results or the REST endpoint data?

Interesting. Hmm. I’ve just tried deactivating all plugins and still I have the problem. And, as mentioned earlier, I tried with a different theme and that didn’t fix it either. I thought it was something to do with Pantheon but since you say it’s not a problem on your instance, that rules that out. Anyway, let me give it some more thought…

I just replicated your test. I setup a brand new sandbox Pantheon site with only three plugins:
– Post Meta Controls v 1.3.1
– LFEvents MU plugin
– Pantheon MU plugin

I performed the steps and the test did not work. That is, when I entered meta values into a new Event, navigated to the Events listing and then back to the new Event, the meta values did not show up. They only show up when I do a hard-refresh of the browser.

Can you confirm that this was the test you performed?

Here is a video showing the instance: https://drive.google.com/open?id=1AlBRFiYuaw541-MLvxlQBMq1NXcFJi9v

Not sure if it matters but I’m using Chrome v 80.0.3987.106

Hold on. I just deleted the Pantheon MU plugin from the above instance and now the test works fine. The meta values appear as they should. So something in the Pantheon MU plugin is causing this issue. I will investigate further.

So Pantheon recommends using this code to exclude specific REST API paths from the cache: https://pantheon.io/docs/mu-plugin#wp-rest-api-code-classlanguage-textwp-jsoncode-endpoints-cache

Do you know offhand which API calls I need to exclude for Post Meta Controls?
Maybe this regex?
#^/wp-json/post-meta-controls/v1/?#

• This reply was modified 5 years, 1 month ago by cjyabraham.
• This reply was modified 5 years, 1 month ago by cjyabraham.
• This reply was modified 5 years, 1 month ago by cjyabraham.

I’m glad you could find the incompatibility. The plugin uses the following route:

/wp-json/post-meta-controls/v1/items?post_id=123&post_type=page

So I think your regex should work. You could also make it more specific:

#^/wp-json/post-meta-controls/v1/items#

Let me know if it worked.