• Resolved Hans Schuijff

    (@hanswitteprins)


    I’ve been getting fatal errors on the WordPress update page when checking for updates on a website of a friend. I found in the log that it was caused by WPForms. Normally it works again when just refreshing the page, but it probably shouldn’t crash.

    The line of code that is crashing is in src/Helpers/CacheBase.php:438 with PHP Fatal error: ?Uncaught Error: Call to a member function getAll() on array.

    $response_headers ?= wp_remote_retrieve_headers( $request )->getAll();

    The return of wp_remote_retrieve_headers( $request ) in that case is an empty array. It’s not prepared for that response.

    Regards.

Viewing 11 replies - 1 through 11 (of 11 total)
  • Plugin Support Ralden Souza

    (@rsouzaam)

    Hi @hanswitteprins,

    Thanks for reaching out!

    When you get a chance, could you please share the full stack trace of the error? With this information, we will be able to check this.

    In case it helps, we have a guide on how to enable debugging in WordPress here. From there, you should be able to get stack trace from the error and share it with us.

    Also, please enable WPForms Logs and share any logs related to the issue here.

    Thanks!

    Plugin Support Shawon Chowdhury

    (@shawon001)

    Hi @hanswitteprins ,

    We haven’t heard back from you in a few days, so I’m going to go ahead and close this thread for now. But if you’d like us to assist further, please feel welcome to continue the conversation.

    Thanks!

    Also getting this exact same error. Any updates on this?

    Plugin Support Ralden Souza

    (@rsouzaam)

    Hi @j0aoj0aquim,

    Thanks for reaching out!

    We haven’t encountered an error like the one reported here in WPForms version 1.9.0.1. When you have a moment, could you please confirm if you’re using our latest version?

    If the issue persists with WPForms 1.9.0.1, please create a new post in our WPForms Lite support forum. This is the next step outlined in the forum’s FAQ.

    When you do, please share the full stack trace of the error. If you need help with this, we have a guide on how to enable debugging in WordPress. Following that guide should help you get the stack trace from the error to share with us.

    Additionally, please enable WPForms Logs and include any logs related to the issue in your new topic.

    Thanks!

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    @j0aoj0aquim @rsouzaam The line of code is easy enough to solve, just check the return of the function for type before using it as an object.

    Changing the line I mentioned earlier in something like this will solve it.

    ? ? ? ?$response_headers ?= wp_remote_retrieve_headers( $request );
    ? ? ? ? if ( ! is_object( $response_headers )
    ? ? ? ? || ! method_exists( $response_headers, 'getAll' ) ) {
    ? ? ? ? ? ? return [];
    ? ? ? ? }
    ? ? ? ? $response_headers ?= $response_headers->getAll();

    or

    ? ? ? ?$response_headers ?= wp_remote_retrieve_headers( $request );
    ? ? ? ? if ( ! is_a( $response_headers,"WpOrgRequestsUtilityCaseInsensitiveDictionary" ) ) {
    ? ? ? ? ? ? return [];
    ? ? ? ? }
    ? ? ? ? $response_headers ?= $response_headers->getAll();

    or something like:

    ? ? ? ?$response_headers ?= wp_remote_retrieve_headers( $request );
    ? ? ? ? if ( is_array ($response_headers ) ) {
    ? ? ? ? ? ? return [];
    ? ? ? ? }
    ? ? ? ? $response_headers ?= $response_headers->getAll();

    Any of those should prevent the crash.

    Looking more closely ate the code before the crashing statement, I’m guessing this function will crash when a pro version doesn’t have a license code. So that might have been the underlying problem. I don’t know what version you’re talking about, but it might explain why it hasn’t been reported here earlier.

    Since the wp_remote_retrieve_headers() function may still return an empty array (instead of an WpOrgRequestsUtilityCaseInsensitiveDictionary object) when is_wp_error( $request ) returns false, it may be right to just check for the type of the header before using any methods on it anyway. Not crashing seems the more elegant way of resolving such issues.

    Tested the latest 1.9.0.1 version and it seems to solve the issue. Thanks.

    • This reply was modified 3 months, 2 weeks ago by j0aoj0aquim.

    I’m facing the same issue after updating to WordPress 6.6.1 with the paid version of WPForms.

    After inserting the code from @hanswitteprins inside CacheBase.php on line 438, the error has been resolved. Thanks.

    Plugin Support Ralden Souza

    (@rsouzaam)

    Hi @hanswitteprins, @j0aoj0aquim, @mhscodafweb,

    @hanswitteprins, thank you so much for sharing all the details!

    I want to let you know that I’ve created a report about this issue to inform our development team.

    I apologize for the inconvenience this has caused, and I’m unable to provide an estimated time for when a fix will be released. However, I’m keeping track of this topic and will make sure to update you as soon as a solution is available.

    Thanks!

    Plugin Support Ralden Souza

    (@rsouzaam)

    Hi @hanswitteprins, @j0aoj0aquim, @mhscodafweb,

    I’m excited to let you know that we’ve released WPForms Lite 1.9.0.3! In this version, we’ve adjusted the code to prevent the issue you reported.

    I apologize for any trouble this may have caused, and I appreciate you bringing it to our attention.

    If you need any assistance with using WPForms Lite, please don’t hesitate to reach out.

    Thanks!

    Thread Starter Hans Schuijff

    (@hanswitteprins)

    @rsouzaam Great, thank you!

    Plugin Support Ralden Souza

    (@rsouzaam)

    Hi @hanswitteprin,

    You’re most welcome!

    If you need any more assistance with using WPForms Lite, please don’t hesitate to reach out.

    Thanks!

Viewing 11 replies - 1 through 11 (of 11 total)
  • You must be logged in to reply to this topic.