• Resolved Enuratique

    (@enuratique)


    The good news is it appears my donation form still works on the website (catcove.org). The bad news is I can’t access the Admin Dashboard without entering recovery mode because of a critical error after updating to 3.6.1. I don’t recall what version I was using previously but it’s been a while since I updated the plugin. Lesson learned, I should have made a backup beforehand.

    But in recovery mode, this is the error I’m getting from the plugin:

    An error of type E_ERROR was caused in line 23 of the file /var/www/wptbox/wp-content/plugins/give/vendor/paypal/paypal-checkout-sdk/lib/PayPalCheckoutSdk/Core/UserAgent.php. Error message: Uncaught Error: Call to undefined function PayPalCheckoutSdk\Core\php_uname() in /var/www/wptbox/wp-content/plugins/give/vendor/paypal/paypal-checkout-sdk/lib/PayPalCheckoutSdk/Core/UserAgent.php:23 Stack trace: #0 /var/www/wptbox/wp-content/plugins/give/vendor/paypal/paypal-checkout-sdk/lib/PayPalCheckoutSdk/Core/PayPalHttpClient.php(24): PayPalCheckoutSdk\Core\UserAgent::getValue() #1 /var/www/wptbox/wp-content/plugins/give/vendor/paypal/paypalhttp/lib/PayPalHttp/HttpClient.php(73): PayPalCheckoutSdk\Core\PayPalHttpClient->userAgent() #2 /var/www/wptbox/wp-content/plugins/give/src/PaymentGateways/PayPalCommerce/Repositories/Webhooks.php(196): PayPalHttp\HttpClient->execute() #3 /var/www/wptbox/wp-content/plugins/give/src/PaymentGateways/PayPalCommerce/Webhooks/WebhookChecker.php(98): Give\PaymentGateways\PayPalCommerce\Repositories\Webhooks->updateWebhook() #4 [internal function]: Give\PaymentGateways\PayPalCommerce\Webhooks\WebhookChecker->checkWebhookCriteria() #5 /var/www/wptbox/wp-content/plugins/give/src/Helpers/Hooks.php(43): call_user_func_array() #6 /var/www/wptbox/wp-includes/class-wp-hook.php(324): Give\Helpers\Hooks::Give\Helpers\{closure}() #7 /var/www/wptbox/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() #8 /var/www/wptbox/wp-includes/plugin.php(517): WP_Hook->do_action() #9 /var/www/wptbox/wp-admin/admin.php(175): do_action() #10 /var/www/wptbox/wp-admin/plugins.php(10): require_once('...') #11 {main} thrown

    I’m using WordPress version 6.4.3 and PHP version 8.0.25 on EasyWP. But I’m wondering if the GiveWP plugin’s version of php_uname() is being blocked now and that’s why I’m getting this error? The only relevant Google search results for this error that turn up are other folks (not using EasyWP) saying their webhosts have disabled php_uname in PHP version 8.0 due to “security reasons”.

    Is this the issue at hand? Are other people having this problem? I searched the forums here and didn’t see any mention of this specific error.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Thread Starter Enuratique

    (@enuratique)

    I have confirmed they’ve disabled this on EasyWP and there’s no way to enable it. Is it possible to gracefully handle exceptions on this function call and provide a default value back? This function is disabled on many common hosts.

    https://www.namecheap.com/support/knowledgebase/article.aspx/9901/2279/easywp-list-of-php-functions-disabled-on-easywp-platform/

    Plugin Support Matheus Martins

    (@matheusfd)

    Hi, @enuratique.

    Glad you reached out.

    php_uname() returns a description of the operating system PHP is running on. This is the same string you see at the very top of the phpinfo() output. For the name of just the operating system, consider using the PHP_OS constant, but keep in mind this constant will contain the operating system PHP was built on.

    On some older UNIX platforms, it may not be able to determine the current OS information, in which case it will revert to displaying the OS PHP was built on. This will only happen if your uname() library call either doesn’t exist or doesn’t work.

    I saw you confirmed with your host that this function is disabled on your site. Right now, this is a necessary function for GiveWP.

    We created a bug report for it here: https://feedback.givewp.com/bug-reports/p/prevent-fatal-error-when-phpuname-is-disabled.

    We are actively tracking user issues to make sure our dev team is aware of them and can get them fixed. You can use the link to check in for updates or to provide additional details of your own.

    Give the post above a look, and let me know if you would like me to add any additional details. I want to ensure your need is as accurately reflected as possible, and I’m happy to include an internal note to our teams with any specific information you would like them to have.

    Feel free to reach out to us if you have any further inquiries or require additional assistance. We’re always happy to help!

    Thread Starter Enuratique

    (@enuratique)

    Hi Matheus,

    Thanks for your response, and yes that all makes sense. That bug report you linked to from July 2023 is the same issue I’m experiencing. I would +1 that bug report for prioritization. In the mean time, is there a way to disable tracking? Or do I have to SFTP into my wordpress instance and comment out usage of php_uname() and hard code the OS string in the file referenced in the stack trace? I’m not sure how the value is used by the plugin. The bug report implies the value returned by php_uname() is used in usage tracking (so hardcoding any gibberish string would not break functionality).

    Any short term solutions you can suggest other than the above?

    Thanks!

    • This reply was modified 1 month, 3 weeks ago by Enuratique.
    Thread Starter Enuratique

    (@enuratique)

    For anyone else reading this, modifying the file at /wp-content/plugins/give/vendor/paypal/paypal-checkout-sdk/lib/PayPalCheckoutSdk/Core/UserAgent.php to comment out calls to php_uname() and hardcoding strings in it’s place, replacing the file on the server, deactivating and reactivating the plugin fixed my issue. This is a pretty ghetto solution but at least I can access plugin settings now.

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