Pantera Północy

Hi @vedantgandhi28 ,

I’m working on this together with @p0rkchop and after stepping through the plugin code it became clear that the issue is not WordPress failing to dispatch a request but the implementation of purge_all() itself we are/were using to attempt cache pruning after some manual non-standard table updates via a custom API.

In FastCGI mode it always calls unlink_recursive() and never respects the purge_method = get_request setting, so no HTTP purge is ever issued, which is why nothing appeared in the Nginx access log; to work around this cleanly we removed our previous do_action(‘rt_nginx_helper_purge_all’) call and replaced it with a targeted approach that queries only published posts and pages containing our [fsvmgrshrtlink] shortcode and then called $nginx_purger->purge_url($url, false) for each, which correctly mapped to the GET method and should generate visible purge requests (we’re still testing), effectively laser-scoping only the URLs we actually modify instead of triggering the filesystem-based full cache wipe. Like so:

function fs_vmgr_clean_cache() {
	global $nginx_purger, $wpdb;

	// Checking wpdb may be excessive, but better to be safe than sorry
	if (!isset($wpdb) || !is_object($wpdb) || empty($nginx_purger) || !is_object($nginx_purger) || !method_exists($nginx_purger, 'purge_url')) {
		return;
	}

	$post_ids = $wpdb->get_col(
		$wpdb->prepare(
			"SELECT ID FROM {$wpdb->posts} WHERE post_status = 'publish' AND post_type IN ('post','page') AND post_content LIKE %s",
			'%[fsvmgrshrtlink%'
		)
	);

	if (!empty($post_ids)) {
		foreach ($post_ids as $post_id) {
			$url = get_permalink((int)$post_id);
			if ($url) {
				$nginx_purger->purge_url($url, false);
			}
		}
	}

	// do_action('rt_nginx_helper_purge_all');
}