WeekScoop

The post you are reading was not published manually. It went live because a cron job fired at the top of the hour, checked a queue, validated the content, generated a banner image, uploaded it to WordPress, scheduled the publish, and sent a Telegram message to let the operator know it was done. All of that happened without anyone being at a keyboard. This is what automation looks like when it is running properly — not as a science project, but as a production system that has been running reliably for months.

The Core Publish Flow

The automation runs on a schedule: every hour, a publish script checks the post queue. If there is a pending post, it proceeds through a sequence of steps in order. First, it reads the content and validates it is present. Second, it generates a banner image using a keyword-driven overlay system. Third, it uploads the image to WordPress via the REST API. Fourth, it creates the WordPress post with the correct title, content, category, tags, and affiliate CTA. Fifth, it updates the local queue file with the publish timestamp and WordPress post ID. Sixth, it fires a Telegram message with the post title, word count, and live URL. All of this takes about 15-20 seconds of compute time.

The queue is a JSON file — simple, portable, human-readable — that tracks every post from topic generation through to publish. Each entry has a status, timestamps, content, image path, and affiliate links. The publish script does not need a database server. The simplicity of this architecture is a feature, not a limitation. A JSON file is easy to back up, audit, modify manually if something goes wrong, and version control.

Where OpenClaw Fits

OpenClaw is the orchestration layer. It runs the gateway that routes Telegram messages, executes cron jobs at scheduled times, manages subagent sessions, and provides the access layer for the various scripts. The Python scripts handle the specific tasks — WordPress publishing, ClickBank link management, image generation — while OpenClaw handles the scheduling, messaging, and coordination. Without OpenClaw, each component would need to be triggered independently. With it, the entire system operates through Telegram.

The Single Points of Failure

Every automation system has failure modes. The single points of failure here are: the WordPress REST API, the VPS host, and the ClickBank affiliate link structure. Each is mitigated by monitoring. The queue guardian script checks every 30 minutes that posts are publishing as expected. If the queue has not moved in more than two publish cycles, it fires an alert to Telegram. The operator can then diagnose and fix before the queue runs dry.

The Affiliate Link Automation

Every post has affiliate links embedded in the CTA. Rather than hardcoding individual links, the CTA is assembled dynamically from the product name and the ClickBank affiliate ID using a templated format. If the affiliate ID changes, every link in every published post can be updated by re-running the link builder against the queue, without editing each post individually in WordPress. The CTA text is also managed centrally — when the decision was made to remove ClickBank mentions from the CTAs, the change was applied by updating the script and re-running it against all published posts via the WordPress REST API.

Queuing and Scheduling Architecture

The queue is not just a passive list of posts to publish — it is an active scheduling system with built-in logic for managing the timing and sequencing of posts. Each post has a status field, a priority weight, and a published timestamp. The publish script reads the queue in priority order, publishes the next available post, and marks it as published with the current timestamp. If the publish fails — if the WordPress API returns an error, if the image upload fails — the post remains in pending status and the publish is retried on the next run.

This retry logic is critical for reliability. A failed publish that is not retried silently would stall the queue. The queue guardian script checks for exactly this situation: it monitors the queue state, alerts if the pending count has not decreased within two publish cycles, and flags any posts that have been in pending status for more than 48 hours. The operator receives a Telegram alert before the queue stalls, not after it has been stalled for days.

The Image Generation System

The banner image generation system uses a template-based approach: a set of base images with appropriate mood and aesthetic, overlaid with text that is rendered based on the post title and topic keywords. The overlay text is rendered using PIL (Python Imaging Library) with fonts and sizing configured to produce readable text at the sizes used by WordPress and social sharing. The generated image is uploaded to WordPress media library, and the returned media ID is attached to the post at creation time.

The image system is deliberately simple — it produces consistent, recognisable banners rather than trying to generate custom artwork for each post. The aesthetic consistency of the blog’s visual identity is maintained without requiring manual image selection for each post. The topic keywords drive the selection of base image and overlay colour scheme from a small library of templates, giving variety within a consistent visual language.

Failure Recovery and Manual Override

The most important design principle of this system is that every component can be operated manually if the automated path fails. If the publish script fails, posts can be published directly through WordPress admin. If the image generation fails, images can be uploaded manually and attached to posts. If the queue file is corrupted, it can be reconstructed from the WordPress post history. The automation exists to reduce manual work, not to create a dependency that requires the automation to be working in order for the operator to do their job.

Ready to support your health? Browse supplements on Gumroad — buy now from £8.