• Resolved livingmiracles

    (@livingmiracles)


    Hello,

    I’m curious if this plugin (reCAPTCHA) has been tested to be compatible with PHP 8+? I understand that I will need to update the PHP on my websites and test it out on the actual websites to be sure, but hearing from the plugin developers whether this plugin has been tested to be compatible with PHP 8 or not will help give me a sense of how much testing and bug fixing there is likely to be before I start the process.

    I appreciate any information you can give!

Viewing 8 replies - 1 through 8 (of 8 total)
  • Plugin Support andrewsupport

    (@andrewsupport)

    Hi,

    We don’t claim that BestWebSoft’s reCaptcha plugin is compatible with the PHP 8.0 versions. We claim that the reCaptcha plugin is compatible with the WordPress version from 5.6 to 6.0.2. Since support for PHP 8 is available only in WordPress beta version, we do not exclude the possibility of some incompatibilities in the case of using the reCaptcha plugin on the site with the PHP 8 version. We can only recommend you test the work of the plugin with PHP 8 version and contact us if you face any issues.

    Thread Starter livingmiracles

    (@livingmiracles)

    Ok, thanks for letting us know.

    Best,
    Living Miracles

    Plugin Support andrewsupport

    (@andrewsupport)

    HI,

    We are always glad to help you. For more convenience, you can do it via our Help Center in order to receive a faster reply.

    Hi all,

    I am currently in transition to upgrade to php 8.1, which brought up a problem in bws_functions.php. You are using an WP_Filesystem object to check whether a local file exists. However, if there was no proper WordPress filesystem method set, it will fall back to FTP requiring to add username/passwords settings prior to use. So the use of WP_Filesystem will fail with an error. I would recommend to use php’s file_exists method instead, please find a quick fix.

    
    --- bws_functions.org.php       2022-10-06 13:07:32.414120430 +0200
    +++ bws_functions.php   2022-10-06 13:09:22.507408608 +0200
    @@ -744,8 +744,7 @@
                    $page = isset( $_GET['page'] ) ? sanitize_text_field( wp_unslash( $_GET['page'] ) ) : '';
    
                    $jquery_ui_version = isset( $wp_scripts->registered['jquery-ui-core']->ver ) ? $wp_scripts->registered['jquery-ui-core']->ver : '1.12.1';
    -               WP_Filesystem();
    -               if ( ! $wp_filesystem->exists( dirname( __FILE__ ) . '/css/jquery-ui-styles/' . $jquery_ui_version . '/' ) ) {
    +               if ( ! file_exists( dirname( __FILE__ ) . '/css/jquery-ui-styles/' . $jquery_ui_version . '/' ) ) {
                            $jquery_ui_version = '1.12.1';
                    }
                    if ( 'et_divi_options' !== $page ) {
    

    Cheers!

    Plugin Support andrewsupport

    (@andrewsupport)

    Hi,

    Unfortunately, we cannot reproduce this problem in our local environment. Please contact us via our Help Center in order to detect the reason and find the solution for you and users with the same error.

    Hi @andrewsupport,

    thanks for your reply. The error is still present in the latest version of the plugin. You can easily reproduce the error by setting up WordPress and setting WordPress filesystem method. Please do not define any credentials for FTP (by default they should be empty). I am running WordPress in a multi-site environment, where none of the individual site owner has direct access to the WordPress filesystem by intention – all updates and plugins are managed by service provider instead. The default filesystem method for all site owner is defined as follows:

    
    if (!defined('FS_METHOD'))
            define( 'FS_METHOD', 'ftpext' );
    

    The error occurs when the google-captcha plugin has been configured by one site owner to protect the wp-admin login prompt. In particular, it will fail to test for the existence of CSS files, because it will trigger WordPress filesystem access via FTP, which would ask for credentials. Therefore, people will be unable to access to login screen, instead they will see the WordPress error page: “There has been a critical error on this website…”.

    The php error logged is as follows:

    
    [11-Dec-2022 14:15:36 UTC] PHP Fatal error:  Uncaught TypeError: ftp_nlist(): Argument #1 ($ftp) must be of type FTP\Connection, null given in /usr/share/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php:4
    20
    Stack trace:
    #0 /usr/share/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php(420): ftp_nlist()
    #1 /var/lib/wordpress/wp-content/plugins/google-captcha/bws_menu/bws_functions.php(748): WP_Filesystem_FTPext->exists()
    #2 /usr/share/wordpress/wp-includes/class-wp-hook.php(308): bws_admin_enqueue_scripts()
    #3 /usr/share/wordpress/wp-includes/class-wp-hook.php(332): WP_Hook->apply_filters()
    #4 /usr/share/wordpress/wp-includes/plugin.php(517): WP_Hook->do_action()
    #5 /usr/share/wordpress/wp-admin/admin-header.php(118): do_action()
    #6 /usr/share/wordpress/wp-admin/index.php(137): require_once('...')
    #7 {main}
      thrown in /usr/share/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php on line 420

    As I do not expect the touch the WordPress filesystem access layer, I would recommend to replace the use of WordPress’ filesystem wp_filesystem to php’s file_exists, because the php code is running where the CSS file should be located as well; thus having direct filesystem access to it as well.

    Hope the description helps to understand my proposed change.

    Thanks!

    Plugin Support andrewsupport

    (@andrewsupport)

    Hi @theschappy ,

    According to the requirements of WordPress, we have made changes from file_exists to wp_filesystem. The WordPress coding standards are designed to ensure that plugins are implemented as little as possible directly into the file system and work indirectly through wp_filesystem.

    Hi @andrewsupport,

    Thanks for coming back to this error message. I have just provided a quick fix to overcome the aforementioned error message. I do not question the use of WordPress’ file system abstraction, which is for sure the best option to handle user files and associated security issues, but it appears inapplicable to your check. A better option to check for the existence of the required CSS files would be during activation of the plug-in and setting an plugin option accordingly instead of checking it during run-time.

    Hope this helps to find an adequate fix,

    Matthieu

Viewing 8 replies - 1 through 8 (of 8 total)
  • The topic ‘PHP 8+ Compatibility’ is closed to new replies.