giggles420

I also have this issue.

Shortcodes still not working in 3.6.2.

Thank you.
That worked.

I use a php file like this, which I normally load in a browser when I want to purge the URLs:

<?php
if ( ! headers_sent() ) {
header( 'Expires: Wed, 11 Jan 1984 05:00:00 GMT' );
header( 'Cache-Control: no-cache, must-revalidate, max-age=0' );
}

define( 'DOING_CRON', true );

if ( ! defined( 'ABSPATH' ) ) {
/** Set up WordPress environment */
require_once DIR . '/wp-load.php';
}
do_action("swcfpc_purge_cache", array("https://example.com/111/", "https://example.com/222/", "https://example.com/333/"));

I searched through the previous version of the plugin for “purge_cache_urls_async” as it was mentioned in the debug log, and found it in libs/cloudflare.class.php. I did not find purge_cache_urls_async in the current version of cloudflare.class.php but similar code is in src/Services/Cloudflare_Client.php in the current version of the plugin.

• This reply was modified 3 weeks, 5 days ago by giggles420.

Heads up – Wordfence has flagged the plugin again
https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/rvg-optimize-database/optimize-database-after-deleting-revisions-51-cross-site-request-forgery-via-odb-start-manually

This report from Wordfence may help:
“This is due to missing or incorrect nonce validation on the ‘odb_start_manually’ function.”

https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-plugins/rvg-optimize-database/optimize-database-after-deleting-revisions-50110-cross-site-request-forgery-via-odb-start-manually

I also see that message when saving settings.

It appears to be OK now. Thank you.

While waiting for update, I changed line 3487 in /wp-content/plugins/schema-and-structured-data-for-wp/output/output.php to this from a previous version of the plugin:

"@id" => trailingslashit(get_home_url()).'#'.$menu_name->name,

That seems to have stopped the error.

• This reply was modified 1 year, 8 months ago by giggles420.

Mailer: phpmailercURL Version: 7.88.1OpenSSL Version: OpenSSL/1.1.1tOS: Linux vm2595.tmdcloud.com 3.10.0-1160.2.2.el7.x86_64 #1 SMP Tue Oct 20 16:53:08 UTC 2020 x86_64PHP: Linux 8.1.16 CPHP Dependencies: iconv=Yes, spl_autoload=Yes, openssl=Yes, sockets=Yes, allow_url_fopen=Yes, mcrypt=No, zlib_encode=YesWordPress: 6.1.1 en_US UTF-8WordPress Theme: xn2020WordPress Plugins: Ad Inserter Pro, AddToAny Share Buttons, Advanced Database Cleaner, Advanced Random Posts Widget, Autoptimize, Honeypot for Contact Form 7, Contact Form 7, Disable Lazy Load, Disqus Conditional Load Pro, Enable Media Replace, GD Rating System, Image Regenerate & Select Crop, Imagify, Index WP MySQL For Speed, Jetpack, Permalink Manager Lite, Post SMTP, Redirection, Relevanssi, Optimize Database after Deleting Revisions, Schema & Structured Data for WP & AMP, Search Meter, Surbma | Divi Remove Project CPT, UpdraftPlus – Backup/Restore, W3 Total Cache, WebP Express, Widget Options, Wordfence Security, Yoast SEO, Super Page Cache for Cloudflare, WP External Links, WP-PageNavi, WP Sitemap Page, WPS Hide Login, XN RelatedWordPress wp_mail Owner: /home/xxxtrana/public_html/wp-includes/pluggable.phpWordPress wp_mail Filter(s): PostsmtpMailer->get_mail_argsWordPress wp_mail_from Filter(s): wordfence::fixWPMailFromAddressWordPress phpmailer_init Action(s): wpcf7_phpmailer_initPostman: 2.4.3Postman Prevent Message Sender Override (Email|Name): No | NoPostman Active Transport: Gmail API (https:oauth2://www.googleapis.com:443)Postman Active Transport Status (Ready|Connected): Yes | YesPostman Deliveries (Success|Fail): 2879 | 12Postman Email Log (Enabled|Limit|Transcript Size): Yes | 100 | 128Postman PHP LogLevel: 2147483647


(domain and hostname removed)

I have the same issue with object cache using memcached, WP 6.1.
I thought it was coming from Imagify because the imagify plugin and W3 Total Cache were updated at the same time, but Imagify’s support pointed to this Github issue which they think is related:

“It looks like this is coming from action scheduler usage of wp_cache_flush_runtime() function, and W3TC does not explicitly declare support for it with wp_cache_supports(). This change happened in v6.0 and v6.1 of WP. You can check this GitHub Issue for further information.”
https://github.com/W3EDGE/w3-total-cache/issues/584

Using W3 Total Cache for Object Caching (memcached)

After further investigation, it turns out it was NOT W3 Total Cache, but another plugin that had automatically updated at the same time.

OK thank you!

OK. Does that the cached_html_pages directory will continue to grow with .tmp files until cache is manually purged?