Matthieu-P. Schapranow

@doublezed2: I have identified the GitHub issue mentioned above (#44009) as possible connected to my support question here. Therefore, I have added relevant information to the GitHub issue and requested reopening the issue from earlier this year. Unfortunately, I am not allowed to reopening the issue (missing access permission). Therefore, I would be very thankful if you could reopen linked GitHub issue. Many thanks!

To summarize my observations up to now: WordPress admin users do not see any issues. Any non-admin users without the manage_options WordPress capability will receive a HTTP 403 for the jetpack REST API endpoint /wp-json/jetpack/v4/connection/data. Typically, you do not want to have non-admin users equipped with manage_options capability, because it basically allows to manage and change the majority of WordPress settings. This might be connected to the issue ticket from Jan 2024: https://github.com/woocommerce/woocommerce/issues/44009. I will link this thread there and request additional support.

As current_user_can() is using map_meta_cap() to check for capabilities, you also require to enable the capability manage_options (meta capability) in addition to jetpack_connect_user capability for your user or user role to make it work.

Thanks for the prompt reply.

I had always “add try / catch block” enabled as a kind of safety net, which triggered the following error: Uncaught SyntaxError: missing } after try block -- note: { opened at line 196, column 4

When disabling to use try/catch, the error vanished. Good to know that latest hints about using the “try / catch” block indicate that it is _generally discouraged_.

Many thanks, let’s close the ticket here.

• This reply was modified 1 month, 2 weeks ago by Matthieu-P. Schapranow.

Thanks for the prompt reply.

Logged error in the browser console was Uncaught?SyntaxError:?missing } after try block <- try / catch block comes from the plugin Autoptumize. When looking into the code location of the error, it points to the purify js lib. Thus, I was able to drill down the exclusion to purify.min.js and it apparently still works as an expected. Apparently, this 3rd party lib is the root source for the issue.

Path to exclude from Autoptimize: wp-content/plugins/easy-fancybox/vendor/purify.min.js or even more generic, if any other plugin is making use of Dom purify: vendor/purify.min.js.

I also tried to replace the bundled version 3.1.5 in your plugin by the latest release 3.1.7 of lib dom purify from the GitHub repo, but it does not fix the error at. I have tried the minified and un-minified version, both result in the same error. Thus, I will open a support ticket at Autoptimize to look into this as well.

Many thanks!

Matthieu

Many thanks for the prompt integration into production.

Hi all,

The current problem with 21.9 is connected to the use of WP_Filesystem() in wp_opcache_invalidate_directory(). If you have not setup dedicated filesystem credentials or you are using a multi-site installation the request for WP_Filesystem will return a login dialog to provide credentials resp. an error, which is not handled. See php error log attached. For the time being, please consider to revert to version 21.8.1 here.

[24-Jan-2024 06:44:16 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:438<br>Stack trace: 0 /usr/share/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php(438): ftp_nlist() 1 /usr/share/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php(456): WP_Filesystem_FTPext->exists() 2 /usr/share/wordpress/wp-admin/includes/class-wp-filesystem-ftpext.php(757): WP_Filesystem_FTPext->is_file() 3 /usr/share/wordpress/wp-admin/includes/file.php(2772): <strong>WP_Filesystem_FTPext->dirlist() 4 /var/lib/wordpress/wp-content/plugins/wordpress-seo/wp-seo-main.php(361): wp_opcache_invalidate_directory() 5</strong> /usr/share/wordpress/wp-includes/class-wp-hook.php(324): wpseo_init() 6 /usr/share/wordpress/wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() 7 /usr/share/wordpress/wp-includes/plugin.php(517): WP_Hook->do_action() 8 /usr/share/wordpress/wp-settings.php(506): do_action() 9 /usr/share/wordpress/wp-config.php(71): require_once('…') 10 /usr/share/wordpress/wp-load.php(50): require_once('…') 11 /usr/share/wordpress/wp-blog-header.php(13): require_once('…') 12 /usr/share/wordpress/index.php(17): require('…') 13 {main}

Cheers,

SCHAPPY

Just as an addition for the latest version of the plugin. There are two folders now, one for legacy and one for the lite version of the plugin. My aforementioned fix applies to the legacy version of the plugin, the updated location of the file is legacy/public/js/cookie-law-info-public.js.

In course of the plugin transition there is the identical file in the main public folder (without the prefix legacy) public/js/cookie-law-info-public.js, which is apparently not longer used by the plugin and a leftover, which will be removed in future releases.

Cheers,

Matthieu

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

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!

Hi @makspostal,

Just a quick fix from my side to disable the corresponding filter to attach to the WordPress hook robots_txt.

@maybellyne: Thanks for your effort to making the Yoast plugin such as great tool. However, it appears to be a very invasive way to attach to robots_txt at priority “99999” without letting people knowing that the plugin starts manipulating robots.txt. Please consider to add a custom preference setting or a filter, which can be overwritten in function.php of a theme, to control the call of the function filter_robots.

--- src/integrations/front-end/robots-txt-integration.org.php      2022-11-08 15:04:33.425277229 +0100
+++ src/integrations/front-end/robots-txt-integration.php  2022-11-08 15:04:42.677050142 +0100
@@ -64,7 +64,7 @@
         * @return void
         */
        public function register_hooks() {
-               \add_filter( 'robots_txt', [ $this, 'filter_robots' ], 99999 );
+       //      \add_filter( 'robots_txt', [ $this, 'filter_robots' ], 99999 );
        }

        /**

Cheers,

Matthieu

• This reply was modified 2 years ago by Matthieu-P. Schapranow.
• This reply was modified 2 years ago by Matthieu-P. Schapranow.
• This reply was modified 2 years ago by Matthieu-P. Schapranow.

Hi @ahmedkaludi,

I am running WordPress 6.0.2 on PHP8.1 (FPM); the warnings occur in the php.log. I have not investigated why the variable $q is not set properly –– if this is for a specific page or subset of pages. PHP8 became more sticky with regards to the use of undefined variables, so it is the best to check for it before use.

Best,

Matthieu

Hi Aaron,

good approach. I appreciate your support!

Cheers,

Matthieu

Hi Aaron,

Thanks for the prompt reply. I expect the underlying problem is connected to function updatePermalinkCache() in DataAccess.php:1978, where a SQL script is read in from the file updatePermalinkCache.sql.

Let us assume that the SQL statement triggers issues due to whatever reason, it will be used to call in DataAccess.php:186 the function queryAndGetResults and the underlying $wpdb->get_results. One option would be to add an try catch block here, but you are right, this is not what would be the expected behavior.

Would be great if someone from W3 Total Cache support team could have a look at this.

Thanks!

Matthieu

Hi @magazine3,

just to clarify: your recent link to the github issue points to another error while enabling the plugin connected to schema_type.php.

The post’s author is referencing a PHP warning from php8+ affecting output/function.php (captured also from my PHP logs as follows):

PHP Warning:  Undefined array key "title" in .../schema-and-structured-data-for-wp/output/function.php on line 3408
PHP Warning:  Undefined array key "description" in .../schema-and-structured-data-for-wp/output/function.php on line 3410
PHP Warning:  Undefined array key "uploadDate" in .../schema-and-structured-data-for-wp/output/function.php on line 3411
PHP Warning:  Undefined array key "duration" in .../schema-and-structured-data-for-wp/output/function.php on line 3412
PHP Warning:  Undefined array key "viewCount" in .../schema-and-structured-data-for-wp/output/function.php on line 3418

I do not know why some of the array values remain empty, but as a quick fix, I just added a default value.

--- function.org.php    2022-10-11 12:28:42.354689807 +0200
+++ function.php        2022-10-11 12:31:20.730785565 +0200
@@ -3405,17 +3405,17 @@
             $input1['itemListElement'][] = array(
                 '@type'                                            => 'VideoObject',
                 "position"                      => $vkey+1,
-                'name'                                     => $v_val['title'],
+                'name'                                     => $v_val['title'] ?? '',
                 'url'                                      => $v_val['video_url'],
-                'description'                      => $v_val['description'],
-                'uploadDate'                       => $v_val['uploadDate'],
-                'duration'                         => $v_val['duration'],
+                'description'                      => $v_val['description'] ?? '',
+                'uploadDate'                       => $v_val['uploadDate'] ?? '',
+                'duration'                         => $v_val['duration'] ?? '',
                 'contentUrl'                       => $v_val['video_url'],
                 'embedUrl'                         => $v_val['video_url'],
                 'interactionStatistic'          => array(
                     "@type" => "InteractionCounter",
                     "interactionType" => array("@type" => "WatchAction" ),
-                    "userInteractionCount" => $v_val['viewCount']
+                    "userInteractionCount" => $v_val['viewCount'] ?? ''
                     ),
                 'thumbnailUrl'                  => isset($v_val['thumbnail_url'])? $v_val['thumbnail_url'] : saswp_get_thumbnail(),
             );

Cheers!

Matthieu

• This reply was modified 2 years, 1 month ago by Matthieu-P. Schapranow.