Post to inbox: one checkbox that sends every post as a campaign

What ScalarWP built

ScalarWP started by proving the send in isolation: one hook, one hardcoded list, about 150 lines, committed on its own — because debugging the send inside a 2,755-line class had hidden which step was failing. Reading FluentCRM’s scheduler explained the earlier failures. Its tick only picks up campaigns in two statuses, and “scheduled” — the status the old code set — is one FluentCRM’s own interface merely passes through; worse, housekeeping archives a scheduled campaign with no pending emails. And the old code wrote recipients as parallel list and tag arrays, when FluentCRM holds them as {list, tag} pairs — so segmentation found nothing it could read and failed closed to zero subscribers. The fix was to stop guessing and copy what FluentCRM’s controller does when someone clicks Send.

The send engine now runs on the ordinary save of a published post — not the publish transition, which fires before the block editor’s separate meta-box request delivers the sidebar fields and so reads a configuration that is not there yet. Config saves at one priority, the send runs at the next, and the condition is “published and not yet sent”, made safe by a sent marker on the post. Each send detaches its own hook against recursion, creates a draft campaign through FluentCRM’s Campaign model, renders through FluentCRM’s classic design template filter so smartcodes, click tracking and unsubscribe behave exactly as in hand-built campaigns, emits one {list, tag} pair per selection — falling back to the main list rather than sending to nobody — sets the campaign processing, fires the processor’s own non-blocking trigger, and writes back the campaign ID and a recipient count read from the campaign’s own rows. Any exception lands on the post as a failed send the sidebar shows.

The editor sidebar carries the controls: the send checkbox (new posts inherit a global auto-enable), subject and preheader with sensible fallbacks, list and tag checkboxes loaded from FluentCRM and cache-invalidated the moment they change in the CRM, a last-send panel in green, amber or red, and inline warnings for oversized posts or an empty CRM. Preview renders through the plugin’s email-safe pipeline — captions become float layouts, stray shortcodes are stripped, image paths go absolute, styles go inline because email clients ignore stylesheets — and writes a step-by-step trace to the console. Test send delivers the rendered email through the FluentCRM-configured sender with a TEST prefix; send now runs a real campaign after confirmation, for posts published before the plugin existed. Every button is nonce- and capability-checked.

One settings screen under Posts holds the defaults, the last ten campaigns with status and links both ways, the last ten critical errors, and an administrators-only system status panel that says what is wrong in a sentence — including a sender check that reads FluentSMTP through FluentSMTP’s own default-connection helper, after the first version read option keys the plugin has never used and warned on every load. Around the code: an activation gate that refuses to run without FluentCRM 2.5+, transient caches with six invalidation hooks, a daily cleanup job, structured logging with a critical ring buffer — plus the FluentCRM list and tag setup, and handover to a team that publishes without us.