Yes! Use [launchmind_blog limit=\"6\" columns=\"3\"]<\/code> for a blog list or [launchmind_post slug=\"your-post-slug\"]<\/code> for a single post.<\/p><\/dd>\nDoes this plugin track my visitors?<\/h3><\/dt>\nNo. This plugin only communicates with Launchmind servers to fetch your blog content. No personal data from your site visitors is collected or transmitted.<\/p><\/dd>\n
What data is sent to Launchmind?<\/h3><\/dt>\nOnly your API key and content requests (such as post slugs and language preferences) are sent to authenticate and retrieve your blog posts. No visitor data is transmitted.<\/p><\/dd>\n
Is the \"Powered by Launchmind\" branding required?<\/h3><\/dt>\nNo. The branding is disabled by default. You can optionally enable it in the block settings or shortcode attributes if you wish to display it.<\/p><\/dd>\n\n<\/dl>\n\n\n
5.2.0<\/h4>\n\n\n- Server-side pageview beacon.<\/strong> The plugin now POSTs a pageview from PHP on every actual Launchmind article render \u2014 independent of JavaScript, cache plugins, or render-mode globals. Until 5.2 every pageview was tracked client-side via
navigator.sendBeacon<\/code>, which silently dropped on sites where (a) LiteSpeed Cache \/ WP Rocket JS-optimization stripped or deferred the inline script, (b) the page was rendered through a CPT path where $GLOBALS['launchmind_blog_post_data']<\/code> wasn't populated and the JS injection self-guard returned early, or (c) the visitor used an ad-blocker that flagged \/api\/tracking\/plugin-view<\/code> as a tracker domain. Affected sites showed zero traffic in their partner dashboards despite real visitors. The PHP-side beacon fires from template_redirect<\/code> (deferred to register_shutdown_function<\/code> so it never blocks the response), resolves the article slug via three independent paths (CPT global \u2192 query var \u2192 post object), filters out common bot User-Agents, and POSTs the same {subscription_id, article_slug, platform, event_type, source: \"server\"}<\/code> payload the JS beacon already sends. Customers who want PHP tracking off can opt out with add_filter('launchmind_disable_server_pageview', '__return_true');<\/code> (the JS beacon stays under the existing enable_analytics<\/code> setting).<\/li>\n- Backend dedup window keeps partner counts honest.<\/strong> When a v5.2 site fires both beacons for the same pageview (PHP from render + JS from the rendered page), the backend now dedups on
(subscription_id, article_slug, ip_hash)<\/code> within a 30-second window: the first beacon to arrive increments the partner counters, the second is recorded for audit but skips the increment RPCs. End result for partners: exactly one pageview per visitor, regardless of which side succeeded \u2014 sites that previously showed zero traffic because of a stripped JS beacon now count via PHP, sites with healthy JS keep counting via JS, and sites with both running don't double-count.<\/li>\n- Diagnostic meta tag in
wp_head<\/code>.<\/strong> Adds <meta name=\"launchmind-article\" content=\"<sub>:<slug>:<plugin_version>\"><\/code> on Launchmind article pages so support \/ debugging tools can verify a page is actually rendered by the plugin without trawling logs. Self-guards on the same is_singular<\/code> check as the beacon \u2014 no-op on non-Launchmind pages.<\/li>\n- Click beacon labelled
source: \"client\"<\/code><\/strong> for symmetry with the new server-side flag. No behavior change \u2014 clicks remain JS-only because outbound link interception requires a browser-side DOM listener.<\/li>\n- No PHP API, database, settings, shortcode or rendering-mode change. Drop-in upgrade for every existing 5.1.x install. Customers running aggressive cache plugins (LiteSpeed Cache, WP Rocket, Cloudflare APO) should see partner-dashboard pageviews start appearing within minutes of upgrade for the first time since installing the plugin.<\/li>\n<\/ul>\n\n
5.1.11<\/h4>\n\n\n- WhatsApp \/ Telegram \/ Signal link previews now show the cover image.<\/strong> Partner-uploaded cover images for Launchmind articles are typically 2-4 MB high-resolution PNGs (great for in-article rendering on desktop, problematic for chat-app preview crawlers). WhatsApp's preview crawler skips images larger than ~1 MB and fails outright above ~5 MB; LinkedIn and Facebook handle the same images fine because they re-process server-side at higher size limits. 5.1.11 detects when the cover image is hosted on Supabase Storage (the default for Launchmind partner uploads) and rewrites the og:image \/ twitter:image URL to use Supabase's
\/render\/image\/public\/<\/code> transformation endpoint with width=1200&height=630&quality=80&resize=cover<\/code>. The transformed URL serves a ~150 KB JPG that all major chat-app preview crawlers accept, while the in-article body image still uses the raw high-resolution URL. Non-Supabase image hosts (Pexels, custom CDNs, theme-hosted) are left untouched \u2014 they either auto-optimize or already serve appropriately sized files. No new options.<\/li>\n- Settings tab now documents the unified-blog shortcode pattern.<\/strong> The Shortcode and Examples sections now show the
[launchmind_blog limit=\"6\" columns=\"2\" include_wp_posts=\"true\"]<\/code> pattern that merges native WordPress posts and Launchmind articles into one date-sorted grid with built-in pagination. The Shortcode Options table also documents include_wp_posts<\/code> and offset<\/code> parameters that were previously only discoverable via reading the source. Recommended for sites built with Breakdance \/ Elementor \/ Bricks \/ Oxygen where the native Post Loop widget renders Launchmind cards without images or pills (the builders fetch post meta via raw SQL that bypasses the WordPress filter API our virtual posts depend on). One shortcode line replaces the broken builder integration.<\/li>\n<\/ul>\n\n5.1.10<\/h4>\n\n\n- Two new routes for page-builder Post Loop coverage.<\/strong> Cards in Breakdance Post Loop \/ Elementor Pro Posts \/ Bricks Query Loop \/ Oxygen Repeater were rendering with title, date, and link but missing the cover image and category pill, even though our 5.1.6+ filter chain on
get_post_metadata<\/code>, image_downsize<\/code>, wp_get_object_terms<\/code>, and friends should have intercepted those calls. Two additions in 5.1.10: (1) the launchmind_article<\/code> CPT now declares category<\/code> and post_tag<\/code> as supported taxonomies, so page builders that gate term-fetching on the CPT's declared taxonomy support no longer skip our posts; (2) when virtual posts are injected via the_posts<\/code>, the WordPress object cache is now prewarmed with _thumbnail_id<\/code> meta for each post, so builders that consult wp_cache_get<\/code> before falling back to raw SQL still find the correct sentinel ID. Strictly additive \u2014 installs that already render fine on 5.1.6\/5.1.7\/5.1.8\/5.1.9 keep working unchanged.<\/li>\n<\/ul>\n\n5.1.9<\/h4>\n\n\n- Topbar contrast fix for builder-managed \"sticky on scroll\" headers.<\/strong> The 5.1.5\/5.1.7 sticky-offset + brand-colour backdrop only fired for headers whose CSS
position<\/code> was already fixed<\/code> or sticky<\/code> on first paint. Many Breakdance, Elementor Pro, and Divi sites build their topbar as position: absolute<\/code> over a transparent hero and only switch it to position: fixed<\/code> after<\/em> the visitor scrolls \u2014 those builders use class names like bde-header-builder--sticky-scroll-<\/code>, elementor-sticky<\/code>, et_pb_sticky_module<\/code>. Until 5.1.9 our detector skipped them, so the article-page sticky-offset was never reserved and the topbar text would clash with the article body's contrast as soon as the visitor scrolled. 5.1.9 extends the detector to also accept absolute\/relative headers whose class names match these builder-sticky patterns (or that carry a data-sticky<\/code> attribute), so the offset and the brand-colour backdrop both apply. No-op on installs that don't use any sticky-on-scroll header.<\/li>\n<\/ul>\n\n5.1.8<\/h4>\n\n\n- Page-builder pill cleanup + extra term-resolution coverage.<\/strong> Two fixes for builders that join multiple category names into a single concatenated pill string (Breakdance Post Loop is the canonical example): (1) the virtual
category<\/code> \/ post_tag<\/code> terms emitted for Launchmind cards are now capped at 2 tags max<\/strong>, with 2 words max per tag<\/strong>, so long-tail Launchmind keywords (\"data science bureau\", \"AI oplossingen bedrijf\") never collide into an unreadable run-on label; the caps are filterable via launchmind_blog_card_max_tags<\/code> \/ launchmind_blog_card_max_words<\/code> for themes that do render multi-pill cards. (2) Term injection now also hooks the lower-level wp_get_object_terms<\/code> filter as a backup path \u2014 some builder configurations resolve term relationships via direct calls that bypass get_the_terms<\/code>, which would leave virtual cards with empty pills despite our get_the_terms<\/code> filter being in place. No breaking changes; existing sites that already render fine on 5.1.6\/5.1.7 keep their current pill layout (just with the tighter caps applied).<\/li>\n<\/ul>\n\n5.1.7<\/h4>\n\n\n- Auto-detect brand colour for the article-page topbar backdrop.<\/strong> 5.1.5 added a contrast-safe but neutral backdrop (#101418 \/ #f5f5f5) behind the topbar on single-article pages whenever the host theme's topbar text was about to disappear against the article body. 5.1.7 makes the backdrop brand-aware<\/strong> by sampling the topbar's actual background colour on the homepage and using that on the article page. Mechanism: the sticky-detect script loads
\/<\/code> in a hidden same-origin iframe during browser idle time, runs the same topbar detector inside that document, walks the topbar's ancestor chain to find the first non-transparent background, and writes the resulting colour to localStorage with a 24-hour TTL. First visit shows the neutral fallback for ~1 second while sampling completes, then swaps to the brand colour with a smooth 220ms transition; every subsequent visit applies the cached brand colour instantly on first paint. Resolution order: theme-set --launchmind-article-topbar-bg<\/code> CSS variable wins, then cached brand colour, then neutral contrast fallback, then async homepage sample. Customers can still override with a single CSS line if the auto-detection picks the wrong region. The whole feature degrades silently \u2014 sites that block iframe-of-self via X-Frame-Options DENY<\/code>, themes without a sticky topbar, or homepages where the topbar genuinely is the article-body colour all stay on the neutral fallback (or no backdrop at all). No new options, no admin setup, no breaking changes for installs that don't have a topbar contrast collision.<\/li>\n<\/ul>\n\n5.1.6<\/h4>\n\n\n- Critical fix for 5.1.5 page-builder rendering.<\/strong> 5.1.5 introduced cover-image and category-pill rendering for Launchmind articles inside page-builder Post Loops, but on real Breakdance \/ Bricks \/ Oxygen sites the cards still rendered without an
<img><\/code> and with an empty pill. Root cause: the virtual_thumbnail_id<\/code>, virtual_thumbnail<\/code>, virtual_has_thumbnail<\/code>, and virtual_terms<\/code> filters all called get_post($virtual_id)<\/code> to resolve the article, but virtual Launchmind posts have no wp_posts<\/code> row \u2014 so on a cold object cache the call did a DB lookup, returned null, and the filters silently returned the original (empty) value. Page builders therefore got _thumbnail_id = 0<\/code> and an empty term list and skipped emitting the inline <style> background-image: url(...)<\/code> block + the pill text. The plugin now keeps a request-scoped post_id \u2192 API payload + slug<\/code> registry populated by Launchmind_Blog_Merge::to_wp_post()<\/code> (and Launchmind_CPT::build_virtual_post()<\/code> on the single-post path), and every CPT-aware filter resolves through the registry instead of through get_post()<\/code>. Confirmed on Twentynext: cover images and category pills now render on Launchmind cards alongside native posts.<\/li>\n<\/ul>\n\n5.1.5<\/h4>\n\n\n- Page-builder cards now render the cover image.<\/strong> 5.1.4 made Launchmind articles available to Breakdance Post Loop, Elementor Pro Posts, Bricks Query Loop and Oxygen Repeater queries, but those builders resolve featured images by passing the article's
_thumbnail_id<\/code> through wp_get_attachment_image_src()<\/code> \u2014 a path that hits the attachment row in wp_posts<\/code> and returned an empty <img><\/code> for our virtual posts. The plugin now intercepts image_downsize<\/code>, wp_get_attachment_url<\/code> and wp_get_attachment_image_src<\/code> for our sentinel attachment IDs and returns the article's cover URL directly, so the same card template that paints the customer's own posts paints Launchmind articles end-to-end. Cover URLs are pre-registered when the loop builds the virtual post (no race with builder code that resolves images before our _thumbnail_id<\/code> filter runs).<\/li>\n- Page-builder cards now render category \/ tag pills.<\/strong> Builders that loop
get_the_terms($post, 'category')<\/code> or get_the_terms($post, 'post_tag')<\/code> to paint the coloured pill on each card got an empty placeholder for Launchmind articles (our CPT uses its own taxonomies). The plugin now returns synthesized WP_Term<\/code> objects built from the article's API tags whenever a builder asks for category<\/code> or post_tag<\/code> on a launchmind_article<\/code> post \u2014 pills now show meaningful labels with no setup. Custom-named taxonomies (e.g. news_category<\/code> on bespoke themes) can opt in via the new launchmind_blog_card_taxonomies<\/code> filter. Term archive links resolve to #<\/code> since the synthesized terms have no real archive page.<\/li>\n- Topbar contrast auto-fix on single-article pages.<\/strong> Some themes (Twentynext-style agency themes, Wix imports, modern boutique designs) use a transparent
position: fixed<\/code> topbar with white logo + nav text, designed to overlay a dark hero on the homepage. On Launchmind single-article pages there's no hero, so that white text became invisible against the body's white background. The companion launchmind-sticky-detect.js<\/code> now samples the topbar's actual text colour and effective background colour, computes the contrast, and \u2014 only when there is a real contrast collision \u2014 sets --lm-topbar-backdrop<\/code> to a contrasting fixed band drawn behind the topbar. Light text on white pages now reads against #101418; dark text on dark pages reads against #f5f5f5. Customers can override the colour with one CSS line by setting --launchmind-article-topbar-bg<\/code> in their theme \u2014 the script reads that first and uses it verbatim. Pages where the existing topbar already has sufficient contrast see no change.<\/li>\n- Sticky-offset rules and detector now apply to CPT-mode (
single-launchmind_article<\/code>) too.<\/strong> The 5.0.1 detector + scoped CSS were originally written for the legacy single-post body class; CPT mode (default since 4.11) uses single-launchmind_article<\/code>, which the rules silently skipped. Both classes are now covered.<\/li>\n<\/ul>\n\n5.1.4<\/h4>\n\n\n- Page builder Post Loops now show Launchmind articles next to native posts.<\/strong> The
launchmind_article<\/code> custom post type registers as public<\/code> \/ publicly_queryable<\/code> \/ REST-visible so Breakdance Post Loop, Elementor Pro Posts, Bricks Query Loop, Oxygen Repeater and similar widgets surface it in their Post Types \/ Include picker. Crucially, the secondary WP_Query<\/code> that those widgets run is now intercepted<\/strong> \u2014 until 5.1.4 only the WP main blog query was hooked, so adding the CPT to a page-builder widget showed an empty loop because the articles aren't stored as real wp_posts<\/code> rows. The plugin now injects Launchmind virtual posts into any secondary query whose post_type<\/code> clause names launchmind_article<\/code>, sorts the combined feed by publish date, and rewrites found_posts<\/code> so pagination across the merged set is correct. End result: customers can pick Posts + Launchmind Articles in their existing card \/ loop widget and articles render with the host theme's existing card design \u2014 no shortcode, no manual styling. The CPT remains hidden from the WP admin menu, nav-menu picker and built-in search results; only the page-builder query sees it. Toggleable via Settings \u2192 Launchmind Blog \u2192 \"Page Builder Compatibility\" (default ON).<\/li>\n- Setup polish.<\/strong> The \"Where should your articles appear?\" welcome notice no longer appears after the setup wizard has already been completed. Previously, sites where the wizard ran to completion still saw the notice as a duplicate prompt. The notice now self-dismisses as soon as an API key is configured (the wizard already records the integration-mode choice), so admins see the question exactly once.<\/li>\n
- Documentation.<\/strong> Added a \"Page Builders (Breakdance, Elementor, Bricks, Oxygen)\" help section to Settings \u2192 Launchmind Blog with concrete steps for adding
Launchmind Articles<\/code> to a Post Loop \/ Query widget. The internal post-type slug (launchmind_article<\/code>) is documented for builders that ask for the slug rather than the human label.<\/li>\n<\/ul>\n\n5.1.3<\/h4>\n\n\n- Fixed: Setup wizard \"Open Settings & finish setup\" button and welcome-notice form\/redirect linked to a non-existent admin URL (
options-general.php?page=launchmind-blog<\/code> and admin.php?page=launchmind-blog<\/code>), which made WordPress show \"You do not have permission to view this page\" even for site administrators. Updated all four references to the correct registered admin page (admin.php?page=launchmind-dashboard<\/code>). After upgrading, the setup wizard's finish button and the welcome notice both land on the real Launchmind dashboard.<\/li>\n<\/ul>\n\n5.1.2<\/h4>\n\n\n- Server-side parity: the Launchmind dashboard now records article-level views and outbound clicks for every plugin install (previously only subscription-level totals incremented for plugin traffic). No plugin-side change is required \u2014 existing installs benefit on next pageview. Companion server-side fix to the
metadata.platform<\/code> filter ensures plugin-tracked customers correctly appear in the partner dashboard's per-article breakdown.<\/li>\n<\/ul>\n\n5.1.1<\/h4>\n\n\n- Fixed: Page-view + click analytics beacons silently never fired on sites running CPT rendering mode (the default since 4.11). The tracking script was wired into the legacy single-post renderer's template path, which CPT mode bypasses entirely \u2014 partner analytics dashboards therefore showed zero traffic for those installs even though the plugin and its content were rendering correctly. The script is now hooked on
wp_footer<\/code> with a self-guard that fires in both legacy and CPT modes, so click + page-view events flow into the dashboard for every Launchmind single-post pageview regardless of rendering mode. No PHP API, settings, shortcode, or rendering-mode change.<\/li>\n<\/ul>\n\n5.1.0<\/h4>\n\n\n- Resilience: stale-while-revalidate cache.<\/strong> API responses are now stored with a 24-hour stale envelope on top of the existing 10-minute fresh window. When the upstream Launchmind API is slow or unreachable, the plugin keeps serving the last-known-good content instead of failing the page. Visitors see no disruption during transient upstream issues. Fresh-window TTL is unchanged for the 99% case where the API is healthy \u2014 this is a graceful-degradation safety net, not a longer cache.<\/li>\n
- Resilience: bandwidth + latency win via ETag\/If-None-Match.<\/strong> The API client now persists ETags returned by the Launchmind API and sends them back as
If-None-Match<\/code> on the next request. When content hasn't changed, the upstream returns 304 Not Modified<\/code> with no body \u2014 we re-use the cached value without a fresh download. At fleet scale this cuts plugin \u2192 API bandwidth by roughly 80% during steady-state, and shaves response latency on cache-revalidations.<\/li>\n- Resilience: 8s API timeout (down from 30s).<\/strong> A degraded upstream can no longer pin a customer site's pageload for half a minute. Combined with the stale-while-revalidate fallback above, slow upstream responses now degrade gracefully (8s \u2192 fall back to cached content) instead of stalling the whole page.<\/li>\n
- Scale: jittered cache TTLs.<\/strong> Cache expiry is now scattered with \u00b160 seconds of randomness so customer sites don't all expire their caches in lockstep and stampede the upstream API. Spreads the refresh wave across a 2-minute window, dropping peak QPS by roughly an order of magnitude on high-traffic content.<\/li>\n
- Scale: object-cache promotion.<\/strong> The cache layer now uses WordPress's persistent object cache (Redis \/ Memcached when present) on top of transients, so high-traffic sites with a managed object cache see fewer options-table reads on cache hits.<\/li>\n
- Scale: chunked sitemap storage.<\/strong> Previously all sitemap posts were serialized into a single transient. On sites with 2000+ Launchmind posts that blob hit ~6 MB and was deserialized in full on every wp-sitemap.xml request. Storage is now chunked into 100-post pages, the count is read from a separate small transient for
get_max_num_pages()<\/code>, and partial fetch failures (page 3 fails) no longer wipe the chunks that did load. Sitemap XML output is byte-identical.<\/li>\n- Edge cache headers on single-post pages.<\/strong> Launchmind article responses now emit
Cache-Control: public, max-age=300, stale-while-revalidate=60<\/code> so CDN \/ page-cache layers (Cloudflare, WP Rocket, LiteSpeed) align with the upstream 5-minute cache instead of caching for hours and serving stale titles after edits, or caching for zero seconds and re-hitting upstream on every visit. Logged-in users are excluded so admins always see live content.<\/li>\n- Security: tracking script no longer ships the API key to the browser.<\/strong> The page-view + click beacons used to inline the customer's API key into the rendered HTML. The tracking endpoint already accepted the public-safe
subscription_id<\/code> on its own; the API key is now kept server-side only and the inline script ships nothing more sensitive than the subscription ID.<\/li>\n- Visibility: daily plugin-health beacon.<\/strong> The plugin now sends a once-a-day, fire-and-forget POST to
\/api\/plugin-health<\/code> reporting the plugin version, WordPress version, PHP version, post count, and rendering mode. This is how Launchmind operations answers \"which sites are still on a vulnerable plugin version?\" at fleet scale. Customers who don't want to send telemetry can opt out with add_filter('launchmind_disable_health_beacon', '__return_true');<\/code>.<\/li>\n- No PHP API, database, settings, shortcode or rendering-mode change. Drop-in upgrade for every existing 5.0.x install. Sites running the previous transient cache format are upgraded transparently the first time each cache key is read post-upgrade.<\/li>\n<\/ul>\n\n
5.0.1<\/h4>\n\n\n- Fixed: On host themes that pin a
position: fixed<\/code> topbar to the viewport without compensating the single-post template with matching padding, the article title sat under the topbar at first paint \u2014 the first line was hidden behind the bar and only the second line peeked out below. Reported on bwnext.com and identical to the symptom many premium agency themes exhibit when their blog template forgets the sticky-header offset.\n\n\n- Adds
public\/js\/launchmind-sticky-detect.js<\/code> (\u22481 KB), a vanilla detector that measures the actual height of any position: fixed<\/code> \/ position: sticky<\/code> element pinned at top: 0<\/code> and writes the result (plus a 16px buffer) to a new CSS variable --lm-sticky-offset<\/code> on <html><\/code>.<\/li>\n- Adds scoped CSS rules under
body.single-launchmind_post<\/code> that consume that variable on the article title (matching the common WordPress h1 classes: .entry-title<\/code>, .wp-block-post-title<\/code>, .post-title<\/code>, .article-title<\/code>, plus generic .entry-header h1<\/code> \/ article > header h1<\/code>) and on scroll-padding-top<\/code> so jump-links also land below the topbar.<\/li>\n- Default value of
--lm-sticky-offset<\/code> is 0px<\/code>. On installs without<\/em> a sticky topbar (the vast majority) the detector finds nothing, the variable stays at zero, and these rules are no-ops \u2014 existing layouts are byte-for-byte unchanged.<\/li>\n- The script is enqueued only on single Launchmind posts (
is_singular('launchmind_post')<\/code>) so non-article pages never load it. Loads in the footer so it sees every theme-injected sticky element. Re-runs on load<\/code> and on resize<\/code> to handle late-injected headers (Breakdance, Elementor Pro, Divi) and mobile\/desktop viewport changes. Filters out cookie banners and chat widgets by ignoring fixed elements narrower than 50% of the viewport or taller than 250 px.<\/li>\n<\/ul><\/li>\n- No PHP API, database, settings, shortcode or rendering-mode change. Drop-in upgrade for every existing 5.0.x install.<\/li>\n<\/ul>\n\n
5.0.0<\/h4>\n\n\n- Fixed: Blog listing card layout broke on themes that apply generic typographic rules to
<article><\/code>, <span><\/code>,