Daniel Iser
Forum Replies Created
-
Thanks for the confirmation. Please take a moment to rate & review the plugin and or support to spread the word.
@shiw06)- patch coming in v2.2.5. Seems they had code in place to prevent redirects for some reason, had to add some overloads to make sure the redirect occurred..
To be clear this issue only occurs with redirect protection. Should be fixed now.
Also tracking an issue with searching for events by name, they use Custom Post Types for events, but don’t disallow the typical REST API method of searching for them. Need to find way to point our post type fields towards their data in these scenarios (probably not the only plugin doing this).
Marking resolved as the initial issue seems to be resolved in this patch.
Thanks for the info, will check into adding some language detection rules.
@tubescreamer – You will probably find its actually browser based caching of both redirects and session status.
That is done at the host/server level by passing flags for browsers to cache more long term, but has major side effects.
Others include going to home page, logging in, then hitting back and seeing the home page shows you still not logged in, even a simple refresh won’t show. Only when you do a few and tell the browser to bypass cache do you see it change.
@bearstar – Try it now.
@avagp – That issue was should be resolved in v2.2.3 I believe. Try updating to the latest version and that should be resolved (v2.2.4).
https://ww.wp.xz.cn/support/topic/warning-attempt-to-read-property-term_id/#post-17514013
- This reply was modified 2 years, 2 months ago by Daniel Iser.
Ok so I just tried adding some metabox custom fields to product editor, had no issues. Maybe you can send your metabox config php and give me some idea of what types of restrictions you have applied.
- Does deactivating restrictions fix the issue?
If so you have restrictions applied to content and admins that are trying to be loaded there via the REST API, because it isn’t loaded, the data isn’t showing.
v2.2.0 made restrictions start applying to the REST API. We tried to make it so that requests from the WP Admin do not have restrictions applied to them in general but its possible those do it differently that we detect for.
- There is an error actually occurring during loading of that data. Check server error logs etc and report the errors so we can debug further.
Let me know.
@soyshinoda – Can you clarify what types of extra fields you have for your products? Is it only the custom fields boxes that are breaking?
@dynasec – Thanks for confirming.
@robin-labadie – Its available now.
Try the update that just went out. It should resolve this particular error, hopefully its the last one you see.
Patch incoming :), was just waiting on someone else to confirm..
@frogdogtech – No your safe in this case. If you check our changelog we noticed right after 1.18.3 went out that SVN had not committed every file, it missed a single new file.
1.18.4 resolved that right away but unfortunately some sites got the other version cached in update list before we could push it out. Sounds like that might have been you in this case.
Updating to the latest should resolve it.
Sorry, to be more specific the PHP error message. Should be avialble from your hosting dash hopefully.
Will be something like PHP Error: Fatal ….
Effectively to check conditions we set the global $post and call setup_post, this makes most WP conditionals just work, such as is_post() etc.
In the case of WooCommerce, they tap into the_post (called within setup_post), to setup their global $product var, which also calls for taxonomy data, making queries.
Thus, WooCommerce makes tax query, our rule engine sets global post to check if any restrictions apply to this query, this then triggers WooC to set the global $product, making a new tax query, and on and on.