deltafactory
Forum Replies Created
-
@corybeal Turn off error display and you’ll be OK. Either set WP_DEBUG_DISPLAY to false or modify your PHP error_reporting/display_errors settings. In many hosting environments that can also be configured from the cPanel or similar web UI.
In my case it is due to WPForms Lite trying to get the theme name during the
wpforms_loadedhook which is triggered duringplugins_loaded.I understand the need to delay translations until the entire WP application state is “loaded”. I hope the solution within this and other plugins is easy enough… All the best.
This deprecation was introduced somewhere around PHP 8.2. I am experiencing it as well after updating my PHP version.
Thanks for the guidance! Your snippet works with the
letremoved (it’s already declared in the args.)I’ve added a value to the snippet for now which can be incremented manually for now and be properly implemented soon. Thanks for your help.
You’re correct that the plugin is not setting cache headers. I haven’t pinpointed the source, but it might be part of the server config. The caching is actually desirable in this case as long as it’s implicitly invalidated when the data is modified.
The counter I envision would be a meta value stored with the map and incremented when any aspect of the map was modified. A timestamp from the last-modified date would be a simpler alternative as long as it’s updated when related records are changed. I’m assuming you handle cache invalidation for the WP REST integration so the increment counter/modified date could be set at that point in the code as well.
To implement this myself all I would really need is a way to get a custom parameter into the data sent to the REST API. Some sort of hook into WPGMZA.Map.prototype.getRESTParameters would be all it took. Is that something that already exists or could be implemented in the future?
Confirming the same experience. Running PHP 8.1, WP 6.3.2
I see PHP 8.1 support was greatly improved in your latest release. Thank you!
I have nothing further to contribute, but if you decide to implement it that would be great!
Is there an update to this issue? I just installed the latest version of the plugin where the problem still exists.
- This reply was modified 2 years, 11 months ago by deltafactory.
I am not able to change themes on a production site. I had laid out a clear test-case which I will now document for you with images.
First, the view you expect:
In this image, the link to the user’s profile is the avatar placeholder.
The view I am reporting:
The avatar image is gone and so the link is no longer visible/usable.
The only setting changed to achieve this difference is in the admin Settings > Discussion towards the bottom.
Since you might ask, the test case was captured on a clean site:
- Fresh install of the latest WordPress
- Awesome Support is the only plugin active
- The current theme is Twenty Twenty-Three
The cause was an old version of the WooSlider plugin which hooked to
manage_posts_custom_columnand modified output for the “id” column. I’ve modifies the slider plugin as development stopped a long time ago.Quick follow-up: I am not seeing the issue on a smaller install which leads me to believe there’s a conflict somewhere with the custom column output. I’ll investigate but it’s safe to assume that the problem isn’t within this plugin. Thanks.
Thanks, looking forward to it!
That code won’t work as the second argument to the hook is an array with the post fields, not the ticket id. In my implementation the second argument of the hooked function is
$postdataand then$ticket_id = $postdata['post_parent'];As you can tell, I’ve already resolved it for my use case.
Can you confirm whether you will be addressing it for all of your users in a future release?
After some digging in, I have some possible answers. The fix was to adjust the action hook to
wpforms_process.- Reusing of Turnstile tokens is not allowed. On a normal submission cycle the form isn’t submitted until all client-side validation passes. This means that the siteverify API isn’t called until most field validation passes.
- Our testing process triggered an extra level of email validation which occurs on the server-side. During that submission, the Turnstile token is submitted and verified. However the form itself has not been completed when email validation fails.
- If the error with the email address is corrected, the subsequent submissions reuse the Turnstile token when calling siteverify which will fail. This may resolve itself after 5 minutes when the token expires IF the widget is configured to refresh itself.
By changing the action hook where Turnstile validates, all other validation has passed before siteverify is called. This is not an ideal fix because other plugins may run during this later hook (as recommended by the developers in the code!) and fail submission, creating the same scenario.
The optimal solution would refresh the Turnstile token has been used to call the siteverify API and if the form fails server-side submission for any reason.