**Problem**
When you schedule two social posts for exactly the same minute (but different seconds), only the first one ever fires. The second one stays in future status and is never published—unless you click “Publish now,” which bypasses WP-Cron altogether and loops through both networks immediately.
—
**Technical details**
* **Custom post type**: social_post is registered in classes/core.php via register_post_type().
* **Scheduling**: In create_social_post() (same file), the plugin does:
$post_date = $date->format(‘Y-m-d H:i:s’);
wp_insert_post([
‘post_date’ => $post_date,
‘post_status’ => ‘future’,
‘post_type’ => ‘social_post’,
/* … */
]);
That fires WP Core’s _schedule_post_hooks() on transition_post_status, which calls
wp_schedule_single_event( strtotime($post->post_date_gmt), ‘publish_future_post’, [ $post->ID ] );
* **WP-Cron trigger**: You’re using a system cron that does
wget -q -O – ‘https://your-site.pl/wp-cron.php?doing_wp_cron’ >/dev/null 2>&1
once per minute.
* **Why it breaks**: On each wget run (say at 14:05:00), WP-Cron will only execute events scheduled **≤14:05:00**. A post set for 14:05:17 or 14:05:30 is still “in the future” at second 0, so it waits for the next cron tick. But that next tick often never runs (due to lack of traffic, HTTP caching of wp-cron.php, etc.), so those events never fire.
* **No built-in recovery**: Unlike core’s handling for the default post type (where WP re-schedules missed publishes on init), the plugin has **no fallback** to scan and publish overdue social_post entries.
—
**Suggested feature**
Add a small internal cron hook—fired on every WP-Cron invocation—that:
1. Queries for all social_post with
* post_status = 'future'
* post_date <= current_time('mysql')
2. Calls wp_publish_post( $post_id ) on each one.
That way, **no scheduled social post ever gets skipped**, regardless of its seconds-offset or how often wp-cron.php actually runs.
