Malae

It has occurred again. Until I find the cause, I have disabled Link Tweaks.

Hi Andrew,

Yes, there were several instances of the number of saved revisions being reduced, but this hasn’t happened recently and all seem to be working as expected. Thank you for your help.

Thank you for the reply.
I have looked at the scap-utility-functions.php file and see that it is checking for non-Latin letters, Javascript , accessibility – response code is 200, url is protocol relative http, https etc. It would not have found any of these issues as the url is https:// with latin letters and numbers and no code.

Line 69 $is_accessible_response = scap_verify_file_url_accessible($fileurl);
seems to have determined that it is not accessible, which is obviously not the case. Your answer is therefore again not addressing the real issue. I want to continue using this plugin and would appreciate your discussing the issues further with the developer.

Hello Kris,
Thanks for your quick response. I was surprised that it showed 503 errors – it must have been a hosting server glitch. No problem unless it occurs again.

I doubt that testing on a dev site would provide much information, unless the URL of the file in question was known.

It would seem that you were not aware of the changes in the version 1.9.12 of the plugin that caused it to throw the cURL 28 error. You did not address the addition of the scap-utility-functions.php file in this version, for which I sent you the information where it throws the error in line 69, when it checks if the file is accessible.

On my site, the file is a stream from a radio station and is played on a radio plugin on the home page and the Compact WP Audio Player plugin allows a user to play the stream on another page without added information. Note that the radio plugin has played the stream for well over a year and continues to do so. I also have this site on a LAMP server for development with the plugin version 1.9.9. On updating, it immediately ceased playing and had a similar cURL 28 error. This server has few limitations.

Hi Guido,

The sending is now ok. Thank you for your reply. The sending is now ok. The proble after sending seems to have be a caching problem. I had recently added a caching plugin and am working on sorting that out.

Hi,
No it was not a spam folder issue. The main problem is that after sending the mail, the contact form Thank You! message cannot be cleared and contact form cannot be used. This has now occured on other sites (all WordPress ver. 6.4.3 and PHP 8.0.) with this plugin and I have been forced to use another plugin, which does not have this issue.

My apologies, I was not thinking clearly when I posted and the information was incomplete.

I have a site on a LAMP server where I am testing a plugin (not in the wordpress directory). It works fine except that it throws a fatal error if I open the Customizer. I was able to create the issue again and the details are as below.

The following from wp-debug:

PHP Warning: Undefined array key "line" in /query-monitor/collectors/php_errors.php on line 364

Fatal error: Uncaught TypeError: strnatcasecmp(): Argument #1 ($string1) must be of type string, array given in /wp-includes/class-wp-customize-widgets.php:1131
Stack trace: 0 /wp-includes/class-wp-customize-widgets.php(1131): strnatcasecmp() 1 [internal function]: WP_Customize_Widgets->_sort_name_callback() 2 /wp-includes/class-wp-customize-widgets.php(1050): usort() 3 /wp-includes/class-wp-customize-widgets.php(714): WP_Customize_Widgets->get_available_widgets() 4 /wp-includes/class-wp-hook.php(324): WP_Customize_Widgets->enqueue_scripts() 5 /wp-includes/class-wp-hook.php(348): WP_Hook->apply_filters() 6 /wp-includes/plugin.php(517): WP_Hook->do_action() 7 /wp-admin/customize.php(123): do_action() 8 {main}

thrown in /wp-includes/class-wp-customize-widgets.php on line 1131

Details as reflected in Query Monitor:

Fatal error: Uncaught Error: strnatcasecmp(): Argument #1 ($string1) must be of type string, array given in /wp-includes/class-wp-customize-widgets.php on line 1131 Call stack: strnatcasecmp() wp-includes/class-wp-customize-widgets.php:1131 WP_Customize_Widgets::_sort_name_callback() usort() wp-includes/class-wp-customize-widgets.php:1050 WP_Customize_Widgets::get_available_widgets() wp-includes/class-wp-customize-widgets.php:714 WP_Customize_Widgets::enqueue_scripts() wp-includes/class-wp-hook.php:324 WP_Hook::apply_filters() wp-includes/class-wp-hook.php:348 WP_Hook::do_action() wp-includes/plugin.php:517 do_action() wp-admin/customize.php:123

Hi NerdPress,

I’m happy to see your adoption of this useful plugin.

In checking the issues, I can report several things that happened both before and since version 5.2 was issued.

My settings have all boxes checked except Delete revisions older than. Number of revisions: 6 . No database table boxes are checked.

I had noticed while using the previous recent plugin versions that some old stable sites with no recent changes, or revisions the number of revisions saved had been reduced to 5!! In one case no revisions were reported or visible in the Classical Editor on some pages. This continued despite adding define( ‘WP_POST_REVISIONS’, true ); to the wp-config.php file, deactivating plugins and reinstalling WordPress. It seems that the revisions were deleted, but can now be added by repeatedly saving after small changes made to check the issue – this on a page which had been unchanged for 10 years!

Those problems aside, the issue I reported was after using the Optimize DB (one-click) on the Admin bar, it did not find any revisions and still does not show or fix them. However, after running the Analyze page it does report the revisions on the pages and other items and running Optimize does work.

Thanks for fast response.

Sorry, missed the details,
WP: 6.4.2
PHP 8.1
Plugin: 4.1.18

Plugin version: 4.1.18
Same error with PHP 8.1

@imee624455)

It has been 8 months since I posted the deprecated PHP errors and the plugin was updated twice since then.
Please provide advise which version your details refer to.

Some hosting companies are falsely reporting this as mine did, but version 5.1 is the updated version that fixed the vulnerability.

I found the issue of any installation using any English language other than English en_US being able to benefit very interesting as it had not been immediately obvious to me, until I thought about it. The main issue is not translations of the content, but that of the language of the WordPress installation.

Most of my sites are single language, but use English en_GB and when optimised they are fast enough, but with the Performant Translations plugin they definitely load faster. This would also apply single language sites using en_AU, en_CA, en_NZ, and en_SA, not to to mention all the other languages.

I was particularly interested in the plugin, because I have one trilingual site with many large images and videos, which is sluggish especially on the backend. The page loading time was reduced although the backend is still slow.

I believe the case for integrating the plugin into the core is well proven and I hope it will be implemented as soon as possible.