ufukart

@sdkjambo,

No — this request does not appear to be related to my plugin.

The log entry you shared:

/wp-admin/admin-ajax.phpaction=as_async_request_queue_runnerUser-Agent: WordPress/6.9.1

Originating from the hosting server itself

This pattern is typically generated by Action Scheduler, which is a background job queue system used by WooCommerce and some other plugins. The as_async_request_queue_runner parameter specifically belongs to Action Scheduler.

Missed Schedule Post Publisher plugin:

Does not use admin-ajax.php

Does not use Action Scheduler

Does not make external HTTP calls

Does not create server-side loopback requests

The plugin runs entirely during normal WordPress page loads and simply checks for posts that are stuck in future status.

If Cloudflare is blocking something, the only thing that matters for this plugin is:

Does a real visitor request successfully reach WordPress?

If Cloudflare is blocking:

admin-ajax.php,

loopback requests,

or server-to-server calls,

that would typically affect other plugins (especially WooCommerce or anything using Action Scheduler), but there is nothing specific to whitelist for this plugin.To clarify the situation, I suggest checking:

1. When a real visitor accesses the site, does WordPress execute normally?

2. Are Cloudflare WAF rules or Bot Fight Mode blocking requests before they reach PHP?

3. Is /wp-admin/admin-ajax.php specifically blocked? (Not required for my plugin, but may affect others.)

In short: the log entry you shared belongs to Action Scheduler, not to my plugin.

Hi @sdkjambo ,

This plugin does not use any external hosting provider, third-party service, specific user agent, or custom HTTP version. It runs entirely within your own WordPress installation and is triggered when a visitor accesses your site.

There is nothing external to whitelist. Even if aggressive caching is enabled on Cloudflare, the plugin will still run whenever a real visitor or bot triggers a cache-initiating request that reaches WordPress. As long as a request is processed by WordPress, the plugin can perform its scheduled post checks and publish missed posts.

Regarding WP-Cron: the plugin does not depend on WP-Cron being enabled. Even if WP-Cron is disabled via DISABLE_WP_CRON, the plugin can still function because it performs its checks during normal page loads.

If you are seeing specific blocked requests in Cloudflare logs, please share the blocked URL and rule ID so I can help identify the exact cause.
I hope this answers all your questions. If not, please do not hesitate to write again.

• This reply was modified 5 months, 1 week ago by ufukart.
• This reply was modified 5 months, 1 week ago by ufukart.

Because the WordPress core publishing flow changed after WordPress 6.9, the plugin could occasionally miss scheduled posts.
In the new version, publishing is handled using WordPress’s native status transition system, and cron scheduling has been made more reliable.

Hi @clicknathan

You’re absolutely right, and I really appreciate your feedback. I’m currently working on a new version of the plugin, and I agree that placing the settings under the standard Settings menu is a better and more standards-compliant approach. I’ll make sure to address this in the upcoming update. Thanks again for taking the time to share your thoughts!

Yes, you are right. I didn’t think about this when I wrote the plugin. I will add this feature in the next update. Thank you for feedback.

I’m sorry for that. Problem solved. Please update plugin.

Thank you so much for your support. Good bye.

Only for options page and tutorials. Not important.
Because every user can use different message formats. For that we can’t use po/mo files for messages.

I would like add default message on every languages but I don’t now how do I do this.
Maybe I can add default message to po/mo files in English and users can add.

• This reply was modified 7 years, 5 months ago by ufukart.