softglaze

Hi, your guess is very likely right. That class file (src/Service/Admin/ExportImport/ExportRestController.php) is part of the plugin, in 14.16.16, 14.16.17 and the current 14.16.18, which was released on 23 October. During an update, WordPress removes the old plugin files and copies the new ones, so for a short moment some files are missing. Any request that runs in that moment can throw “class not found”, and it stops once the update has finished.

So if the errors stopped after the update, there is nothing to fix. You can check by comparing the times of the errors with the time of the update.

If they come back later, reinstall the plugin: download 14.16.18 from its plugin page, go to Plugins > Add New > Upload Plugin, upload the zip and choose “Replace current with uploaded”. Then clear OPcache or your host’s cache, so PHP does not keep an old copy of the files.

Did the errors only appear around the time of the update?

Hi, yes. The plugin page and the update data on WordPress.org both say 2.29.29 is tested up to WordPress 7.1.3.

The “Not tested” text on your Updates screen comes from update information your site saved earlier. WordPress shows “Not tested” when that saved data does not have a tested version of 7.1.3 or higher. Go to Dashboard > Updates and click “Check again”, and it should change to “Yes (according to its author)”.

About security: the changelog for 2.29.19 says “Vulnerability: Reflected Cross-Site Scripting via the ‘seraph_accel_prep’ parameter.” That fix came after your 2.29.8, so 2.29.29 includes it. If that is the issue your scanner reports, updating will fix it.

Take a backup first, then update. If the scanner still flags something after the update, please share the exact name of the issue it shows.

Thanks @futtta, happy to help, and thanks for adding the details about line 118 and the inline CSS settings.

@calliko, I would start with Frank’s first step: in Settings > Autoptimize, uncheck “Inline all CSS?”, save, clear the cache and check the page again. If the notice is still there, check “Keep HTML comments?” next. Let us know which one fixes it for you.

Hi, Redirection fires these actions when a redirect changes, so the cache plugin can hook into them:

• redirection_redirect_updated ($id, $redirect): when a redirect is created or updated
• redirection_redirect_deleted ($redirect): when a redirect is deleted
• redirection_redirect_enabled and redirection_redirect_disabled ($id): when a redirect is switched on or off

The source URL to purge is $redirect->get_url(). For the two hooks that only pass the ID, load the redirect first with Red_Item::get_by_id( $id ). For example:

add_action( 'redirection_redirect_updated', function ( $id, $redirect ) {
	if ( $redirect && ! $redirect->is_regex() ) {
		// Purge $redirect->get_url() here with the cache plugin's purge function.
	}
}, 10, 2 );

Two things to tell the cache plugin team:

• Regex redirects have no single URL, so check $redirect->is_regex() and purge more widely for those.
• These hooks only fire when redirects are saved through Redirection itself (the admin screen, its REST API or Red_Item::create()). Rows written straight into the database table do not fire them.

The full list is in the Redirection docs: https://redirection.me/developer/wordpress-hooks/

How does your sync create the redirects?

Hi, it already works on the front end. If “Auto Apply Sort” is checked in Settings > Post Types Order, the Query Loop block shows your custom order to visitors.

Only the preview inside the editor still shows the posts by date. The editor loads that preview with a date order request, and the plugin leaves requests with their own order alone. So the editor preview and the live page can look different.

With Auto Apply Sort on, your custom order always comes first, and the “Order by” setting of the Query Loop block only decides the order of posts that have the same position.

Can you check the published page while logged out, with any page cache cleared? It should already be in your custom order there.

Hi, the account and billing for the premium version are kept by WP-PDF, not by WordPress.org, so volunteers here cannot look them up. The quickest way is to contact them directly: https://wp-pdf.com/contact/

To help them find the account, send them:

• the site URL
• the license key: it is saved on the site, usually shown in the PDF Embedder settings, or set in wp-config.php as PDFEMB_LICENSE_KEY
• the date and amount of the last yearly charge from your card or bank statement

Please do not post the license key or any account email here, because this forum is public.

Hi Bill, if you used Bulk actions > Move to Trash, the pages are not gone yet:

1. Go to Pages and click the “Trash” link at the top of the list.
2. Select the Mail Mint pages and choose Bulk actions > Restore.
3. Restored pages come back as Drafts, so open each one (or use Quick Edit) and publish it again.

They keep the same page IDs, and Mail Mint remembers those IDs in its settings, so everything works again without other changes. WordPress empties the Trash after 30 days by default, so do it soon.

If they were deleted permanently, deactivating and activating the plugin will not create them again, because that only happens on a new install. In that case, create the pages yourself with these shortcodes:

• Mint Mail Opt-in Confirmation: [optin_confirmation]
• Mint Mail Preference: [preference_page]
• Mint Mail Unsubscribe Confirmation: [unsubscribe_confirmation]
• Mint Mail Unsubscribe Survey: [unsubscribe_survey]

Then select the new pages again in the Mail Mint settings.

For the funnel videos, the Mail Mint team can point you to the right one.

Hi, the plugin cleans up after itself if you remove it in the right order. Take a full backup first, then:

1. If you used Image Optimization: go to LiteSpeed Cache > Image Optimization and click “Destroy All Optimization Data”. Do this first, because the uninstall does not remove the image optimization table. It reverts the optimized images and deletes the optimization files the plugin made.
2. Deactivate the plugin on the Plugins screen. This sets WP_CACHE back to false in wp-config.php and removes its object-cache.php drop-in and its .htaccess rules.
3. Click Delete. The uninstall removes all litespeed.* options, drops its own tables (avatar, crawler, crawler_blacklist, url and url_file) and deletes the wp-content/litespeed folder. On multisite it does this for every site.

After that, nothing from LiteSpeed Cache should be left in the database, except the litespeed_img_optming table if you skipped step 1.

If you also used QUIC.cloud, check your QUIC.cloud account too, since that service is outside WordPress.