Launchmind Blog

Change log

5.12.1

• The readability dot is filled in as well now. 5.12.0 deliberately left it grey, because the only figure we had was a raw reading-ease score that measures something different from what Yoast shows: it penalises long Dutch compound words while ignoring what actually makes a text readable. Launchmind now runs the same set of checks Yoast does (sentence length, paragraph length, subheadings, sentence beginnings, transition words, passive voice) and reports the share that pass, which is directly comparable to the figure in your editor.

5.12.0

• Tags are now the article’s own keyword, not the whole list. Every article carried the same ten tags, because the plugin received the keyword set of the entire cluster rather than the keyword this particular article targets. Articles now get their own keyword, which is what a tag is meant to be.
• Q&A articles get a category. They come from an interview and belong to no content pillar, so they were left without any category at all. They now get their own “Q&A” category.
• The SEO dot in the article list is no longer grey. Yoast only runs its analysis inside the editor, and a synced article never passes through it. The plugin now fills in the score Launchmind already determined. Note this is Launchmind’s assessment shown in Yoast’s colours; opening the article in the editor makes Yoast calculate its own. The readability dot is deliberately left alone, because we do not measure that reliably enough to colour it.

5.11.9

• The sharing image is now exactly 1200×630 on every article. That is the size Facebook, LinkedIn, X, WhatsApp and Slack all expect. Previously the plugin could only crop down, so an article whose cover was smaller ended up below the recommended width and networks fell back to a small card. The image is cropped from the centre and saved as a JPEG, which also keeps heavy PNG covers from bloating the preview.

5.11.8

• Fix: the plugin now sets the sharing image tags itself on Yoast sites. Three earlier attempts to get Yoast to pick the prepared image each failed at a different point in its pipeline, most recently by quietly swapping the address back to the original file. Rather than keep guessing at its internals, the plugin now removes only Yoast’s two image tags and writes them itself. Everything else Yoast does, titles, descriptions, canonicals and schema, is untouched.

5.11.7

• Fix: the sharing image is now its own image, so nothing can override it. Cropping inside the original image was not enough: Yoast takes the URL, looks up the image it belongs to, and then falls back to the full-size original. The page ended up stating the cropped size above the uncropped file. The prepared sharing image is now stored as an image in its own right, so its full size is the crop and no SEO plugin can reach past it. This also makes it work identically on Rank Math, SEOPress, All in One SEO and on sites with no SEO plugin at all.
• Added the name="image" tag that LinkedIn asks for in its own Post Inspector, alongside the standard tags.

5.11.6

• Fix: the sharing image really is applied now. The code added in 5.11.5 ran but changed nothing, because of a faulty check on our side. Verified on a live site: the prepared image was ready and the page still pointed at the original. No re-sync is needed after this update, the change takes effect on the next page view.

5.11.5

• Fix: the sharing image now actually reaches Facebook and LinkedIn. 5.11.4 prepared a correctly cropped sharing image but never got it onto the page, because recent versions of Yoast decide the sharing image in a way the previous approach could not reach. The plugin now writes it into the SEO plugin’s own field during the sync, where it is also visible to you under the article, and enforces it on the page itself.
• Works without an SEO plugin, and with the other ones. Yoast, Rank Math, SEOPress and The SEO Framework each get the image in their own field. Sites running no SEO plugin at all, and sites on All in One SEO, get the tag straight from this plugin instead. Whichever setup you are on, the sharing image is the prepared one and its stated size matches the file.

5.11.4

• Fix: articles now have a real sharing image. Until now the plugin handed the article’s cover image to Facebook and LinkedIn exactly as it was. A cover is not a sharing image: one article’s cover was a tall 1024×1536 portrait, which does not fit the wide card those networks show, and another was a 2.9 MB image whose real size disagreed with what the page claimed. Both are reasons a network quietly falls back to no image at all. The plugin now prepares a proper 1200×630 sharing image during the sync and hands that over instead, with its true dimensions. Existing articles get one on the next sync, without needing an edit.

5.11.3

• Fix: link previews on Facebook, LinkedIn and WhatsApp. In sync mode the article is a real WordPress post, so your SEO plugin already publishes a preview image and the plugin published a second one on top of it. The two disagreed about the image size, and scrapers that trust the first one reported no image at all. The plugin now leaves the preview image to your SEO plugin on synced posts.
• Fix: the preview image size is no longer guessed. The plugin declared every preview image as 1200×630 pixels without ever measuring it. That was wrong for practically every article, which is what made social networks re-fetch or skip the image. The real size is now read from the media library, and when it cannot be determined the plugin says nothing and lets the network measure the file itself.
• Fix: articles are filed under their real author. Synced articles were owned by the administrator account, so the REST API, oEmbed and the articles list in wp-admin all showed “admin” while the article page itself showed the correct byline. Each writer now gets their own author record. These records have no role and no usable password, so they cannot sign in; they exist only so WordPress knows who wrote the article. To keep everything on the administrator account instead, add add_filter('launchmind_create_author_users', '__return_false'); to your theme.

5.11.2

• Fix: existing articles now get their category and SEO fields too. The pillar category and the SEO plugin fields introduced in 5.11.0 were only written when an article’s content had changed, so articles already on your site kept their empty category and empty focus keyphrase and the feature looked broken. Those fields are now kept current on every run, whether the text changed or not.

5.11.1

• Fix: clicking Launchmind opens the dashboard again. Adding the articles list under the Launchmind menu in 5.11.0 pushed it to the top, and WordPress sends a click on a parent menu to whatever sits first. That made the settings unreachable. Dashboard is back on top, with Articles below it.

5.11.0

• Fix: you can now actually edit a synced article. Opening one in the WordPress editor was blocked by a permission setting left over from when these articles were not real posts yet. Even an administrator could not edit them. They behave like any other post now.
• New: articles are filed under their content pillar as a category. Your articles are already grouped into topical clusters on the Launchmind side, but that grouping never reached WordPress, so the category column sat empty. Each article now joins the category for its pillar, which gives you real archive pages and breadcrumbs. A category you assigned yourself is never removed.
• New: your SEO plugin’s fields are filled in. The focus keyphrase, meta description and SEO title are written to Yoast and Rank Math from what we already know, so you stop seeing a red dot on every article for a field that was simply empty. Anything you filled in by hand is left alone.
• Keyword tag archives are kept out of search results. The tags on your articles are search terms rather than a real taxonomy, and each article carries most of the same ones, so those archive pages end up nearly identical and compete with your actual articles. Tag archives that contain only Launchmind articles are now marked noindex (links are still followed). Tags you also use on your own posts are untouched, and category archives stay indexable.

5.10.0

• In Sync mode your blog overview now comes from your own database too. Until now the listing was fetched from Launchmind on every page load, even in Sync mode. That meant the overview could show articles that had not been imported yet (clicking one gave a 404), the links carried a language parameter that no longer did anything, and the overview stopped working if the connection to Launchmind ever went away. Now the listing and the articles come from the same place: yours. That also means your blog overview joins WordPress search, categories and theme loops, which it could not before.
• New: an Articles list in the admin. In Sync mode your imported articles now appear under Launchmind as a normal WordPress list, with filters, quick edit and bulk actions. So you can set one or a hundred of them to draft whenever you want. The sync respects that: a post you set to draft yourself is flagged and never republished.
• Safety rail on reconciliation. The sync drafts articles that disappeared on the platform. It will now refuse to do that when a run reports zero articles while your site holds many, because “I saw nothing” is never a good enough reason to unpublish a whole blog.
• Trade-off worth knowing: a brand new article appears in the listing once the hourly sync has picked it up, rather than instantly.
• Fix: Q&A articles are recognised again in Sync mode, so “show only Q&A” and “hide Q&A from the main listing” work as they should.
• Fix: an article whose FAQ or summary changed now re-syncs. Those fields were not part of the change check, so an edit that touched only them was skipped and the page kept showing the old answer in its structured data.

5.9.6

• Fix: Sync mode articles now get our reading styles. Article typography (heading sizes, line height, spacing around paragraphs and lists) is applied through a wrapper that Live mode added but Sync mode did not, so synced articles fell back to whatever heading sizes the theme uses. On builder themes that meant oversized headings pulling the article apart. Same reading experience in both modes now.
• The Sync list is paginated at 10 articles per page, so the screen stays readable once you have a hundred of them, and the counter shows your real total instead of the number on screen.

5.9.5

• Fix: hourly Sync updates were failing every time. The timestamp Sync sends to ask “what changed since last time” contained a character that a web address reads differently, so the platform rejected every incremental run with “Invalid updated_since timestamp” and the sync stalled after three attempts. Only full runs got through. Fixed on both sides, so existing installs are already working again before they update.

5.9.4

• Accent colours now pick up Elementor themes too. Our accents look for your theme’s primary colour, but the list of places we looked did not include Elementor, which is one of the most common builders there is. On those sites the accents fell back to plain text colour instead of your brand colour. Added, along with a couple of other common theme conventions.

5.9.3

• Translations now use their own proper URL. 5.9.2 gave every translation the Dutch slug with a language code appended. Launchmind already writes a real slug per language, so a German article now lives at its German address instead of a Dutch one with “-de” stuck on the end. Better to read, and better to rank. When no localised slug exists the language suffix is still used as a fallback.

5.9.2

• Sync mode now keeps all your languages. Until now Sync stored one post per article, in your site language only, and a ?lang= link quietly served the site language instead. Articles that exist in several languages are now stored as a post per language: your site language keeps its current address (/blog/my-article/) and every other language gets its own (/blog/my-article-en/). No existing URL moves, so nothing you already rank for is affected.
• Old ?lang= links redirect to the right language page instead of silently showing the wrong one, so links you shared earlier keep working.
• hreflang points at the real pages in Sync mode, which is what tells Google these are translations of each other rather than duplicates.
• From the Sync list you can now reach both sides of an article: the title opens the WordPress editor so you can change anything you want, and the address below it opens the live page in a new tab. Translations are labelled with their language.
• The Sync sitemap is built from your own database, so it lists every language and no longer advertises articles that have not been synced yet.

5.9.1

• Fix: switching to Sync mode no longer breaks your article URLs. After enabling Sync, /blog/{slug}/ could serve your theme’s archive template (or a 404) instead of the article, because WordPress was still routing on the old rules. The only way out was to open Settings, Permalinks and press Save, which is not something you should ever have to know. The plugin now refreshes those rules by itself on the first page view after a mode switch, front-end or admin.
• Fix: FAQ schema now also works in Sync mode. In Sync mode the article is served from your own database, so there is no live call to fetch the question-and-answer pairs from. Those are now stored alongside the post, which means synced articles emit the same FAQPage structured data that 5.9.0 introduced for Live mode. The same goes for the author role, bio and word count.

5.9.0

• New: FAQ schema on every article. Each Launchmind article carries five question-and-answer pairs. Until now they were plain headings on the page: search engines and AI assistants had no way to recognise them as a FAQ. The plugin now emits proper FAQPage structured data alongside the existing Article schema, so those answers become eligible for rich results and are far easier for ChatGPT, Claude and Perplexity to quote.
• New: breadcrumb structured data, so your article shows its place in the site hierarchy in search results instead of a bare URL.
• Richer article schema. Author role, bio and photo are now part of the Person block when your profile has them, plus word count and an explicit marker on the article’s direct-answer opening. All of it feeds the same goal: making it unambiguous who wrote this and which passage answers the question.
• New setting: AI search engine access (Settings, under “Search and AI visibility”, on by default). Adds explicit allow rules to robots.txt for the crawlers behind ChatGPT, Claude, Perplexity and Google AI Overviews. If those crawlers cannot read your pages, no assistant can cite you, however good the article is. The settings screen also warns you when a robots.txt file in your web root overrides WordPress, or when a CDN may be blocking the crawler before it ever reaches your site.
• IndexNow fix: refreshed articles are resubmitted, and the blog path is respected. Two bugs in the existing IndexNow support. It submitted /blog/{slug} regardless of the Base Path you configured, so anyone using a different path was pinging URLs that do not exist. And once a URL had been submitted it was never submitted again, which meant the platform’s content-refresh engine rewrote articles without search engines ever hearing about it. The plugin now tracks the article version and resubmits on change. Existing installs migrate automatically on the first run.
• Existing installs keep working unchanged: articles from an older platform response simply skip the new schema blocks.

5.8.0

• New: Sync content mode — your articles as real WordPress posts, in your own database. Next to the existing Live mode (articles load straight from Launchmind), you can now choose Sync under Settings → Content Mode or in the setup wizard. Sync imports every article as a genuine launchmind_article post, copies the cover + inline images into your media library, and keeps everything up to date automatically (hourly incremental check, daily full reconciliation). URLs stay byte-identical (/blog/{slug}/), so switching modes never moves a page for SEO.
• Why this matters. With Sync, your content is genuinely yours: it keeps rendering from your own database even if the connection to Launchmind is ever interrupted. Deactivating or uninstalling the plugin never deletes a single post or image.
• Safety rails built in. Posts you edit yourself in WordPress are detected and skipped (flagged on the new Sync tab, with a per-post “overwrite on next sync” action). Articles removed on the platform become drafts here — nothing is ever hard-deleted. A flaky connection can never mass-draft your library: reconciliation only runs after a complete, error-free pass.
• New Sync tab on the Launchmind dashboard: last/next run, progress bar during imports, per-article status list, and a “Sync now” button.
• Server delta support. Incremental runs use the new updated_since/deleted_since API parameters when available and fall back to full hash-based comparison on older servers.
• Multisite is untested with Sync mode in this release; everything is per-site (options, cron, media), but network setups should stay on Live mode for now.

5.7.1

• New: intro="" attribute on [launchmind_blog] for a per-page custom welcome line. Replaces the auto-generated “Welcome to {site name}’s blog…” copy with whatever the customer types, without forcing show_intro="false" + a separate text block above the shortcode. Plain text only (HTML is escaped) so the markup stays predictable across themes. Empty value falls back to the language-default welcome. Example: [launchmind_blog intro="Welkom op de blog van Whoon. Hier vind je interieurinspiratie."].
• Settings page: Shortcode Reference card rewritten as a copy-paste cookbook. Adds clearly-labeled examples for the 5.7.0 wp_post_types merge, the new intro="" attribute, common tweaks (columns, limit, show_excerpt / tags), multilingual usage, Q&A-only, and the single-post shortcode. Each example sits under its own H4 so customers can scan instead of decoding an attribute list. No behavior changes for the existing options.

5.7.0

• New: [launchmind_blog] shortcode merges any post type, not just native post. Adds a wp_post_types attribute (comma-separated) so customers whose own articles live on a custom post type (e.g. Whoon’s “algemene-posts”, a news site’s “news”, a magazine’s “stories”) can mix them into the Launchmind listing alongside their content. Example: [launchmind_blog wp_post_types="post,algemene-posts" columns="3" limit="12"]. Default stays wp_post_types="post" so existing installs are unaffected. Sanitized with sanitize_key() per slug; empty/garbled values fall back to post. Solves the page-builder edge case where Elementor Pro’s Posts widget can’t easily merge two post types in one query — drop the shortcode into an HTML/Shortcode widget instead and the merge happens server-side.
• Why this matters. Until now, customers on a custom CPT had to either accept two separate listing widgets (one for their CPT, one for Launchmind) or set up a custom Elementor query ID with PHP. The shortcode now does the merge + chronological sort in one call, no PHP snippet required.

5.3.6

• Fix: launchmind_article CPT now passes Elementor Pro’s second visibility gate (show_in_nav_menus). v5.3.5 set show_ui=true to make our CPT visible to page-builder Source dropdowns, but Elementor Pro filters its post-type list with get_post_types(['public' => true, 'show_in_nav_menus' => true]) — the standard WP convention for “linkable content types”. Our CPT had show_in_nav_menus=false so we passed the first gate (show_ui) but failed the second. Customers still saw no “Launchmind Articles” in Elementor Pro Posts widget after 5.3.5. This release flips show_in_nav_menus to track page_builder_compat so both gates open together. JetEngine was unaffected by either gate; this only matters for Elementor Pro / Loop Grid / similar.
• Side effect: “Launchmind Articles” now appears in Appearance → Menus. Customers can technically pick a virtual post for a nav menu item, but the picker shows 0 items (we have no real wp_posts rows), so this is a UI no-op rather than a footgun.

5.3.5

• Fix: launchmind_article CPT now visible to Elementor Pro + other page-builder Post widgets. The CPT registration hardcoded show_ui=false to keep “Launchmind Articles” out of the WordPress admin sidebar. Side effect we hadn’t anticipated: Elementor Pro’s Posts widget and Loop Grid filter their Source dropdown by show_ui, so our CPT was invisible to them even with Page Builder Compatibility enabled. JetEngine used a looser filter and surfaced our CPT either way, masking the issue for sites that primarily used JetEngine. Fix: show_ui now tracks page_builder_compat (same as public, publicly_queryable, and show_in_rest already did). Admin sidebar suppression is independently controlled by show_in_menu=false so the admin UI stays clean. Customers with Page Builder Compatibility ON will see “Launchmind Articles” in every builder’s Source dropdown after this update.
• No customer action needed. Existing JetEngine / Bricks / Breakdance integrations continue to work unchanged.

5.3.4

• Fix: legacy lm_<slug>_<random> API keys couldn’t auto-resolve subscription_id. v5.3.3’s auto-heal path only matched the modern lm_<uuid>_<random> key format. Customers who signed up before the UUID switch have keys shaped like lm_broadwick_f7670e70... — the slug isn’t parseable into a subscription UUID locally, so the regex returned empty and tracking stayed off even after v5.3.3 shipped. Adds a server-side fallback: when the regex doesn’t match, the plugin calls /blog/customer (already authenticated via api_key) and reads subscription.id from the response. Result is cached via transient (12h TTL) so it costs at most one API call per half-day. Server endpoint now returns subscription.id in its response shape — read by 5.3.4+ plugins, ignored by older ones.
• Backward compatible. Existing UUID-format installs skip the network call entirely (regex hits first). Sites where neither path resolves (no api_key set) still surface the admin notice from 5.3.3.

5.3.3

• Fix: tracking beacons silently dropped on installs where subscription_id was wiped (typically after a plugin re-install). Pre-5.3.3, the JS beacon, server-side PHP beacon, and diagnostic meta tag all read the subscription_id plugin option directly and bailed out when empty — even though the api_key (which stays put across re-installs) embeds the subscription UUID in its lm_<uuid>_<random> format. New helper resolve_subscription_id() returns the option when set, parses the UUID from api_key when not, and persists the derived value back into the option so subsequent calls skip the regex. Affected installs auto-heal on the next page-load — no customer action needed.
• Always-on analytics tracking — enable_analytics UI toggle removed. The “Enable analytics tracking” checkbox in plugin settings is gone. Tracking is mandatory: partner dashboards exist precisely to show traffic, so a hidden off-switch was a footgun (the most common path was a customer flipping it off while testing then forgetting). Sites that have legitimate reasons to suppress server-side beacons can use the launchmind_disable_server_pageview filter (PHP) — that path stays. The launchmind_blog_enable_analytics option in the database is now ignored; cleaning it up is a no-op.
• Admin notice when subscription_id can’t be resolved. When BOTH the option is empty AND the api_key is missing/malformed (the only state where tracking is genuinely impossible), an amber warning surfaces in WP admin pointing the customer at the settings page. Previously these installs sent zero traffic with no UI signal — partners assumed their site had no visitors when actually the plugin couldn’t beacon anything.
• JS beacon detection widened. inject_tracking_script_on_footer no longer gates on $GLOBALS['launchmind_blog_post_data'] alone — it now uses the same three-path detection (CPT singular | query var | post object) the PHP beacon got in 5.3.2. Sites where the global wasn’t populated for the active render path (CPT-singular templates served without the legacy slug interceptor) still get JS beacons.

5.3.2

• Fix: PHP server-side pageview beacon never fired on legacy slug-rendering sites. v5.2 introduced a server-side PHP beacon that was supposed to count pageviews even when the JS beacon got stripped (cache plugins, ad-blockers). In practice it was hooked to template_redirect priority 20, which fires before the content/template filters that populate $GLOBALS['launchmind_blog_post_data'] under the legacy slug-interception render path. Result: on every site using legacy rendering (which is most of them), the is_singular('launchmind_post') || get_query_var('launchmind_post') gate failed, register_shutdown_function was never registered, and the beacon silently never fired — observed across all 4 active WP installs over the 14 days following the v5.2 release. Hook moved to wp_footer priority 999 (the same hook the JS beacon already uses), and the gate now reads $GLOBALS['launchmind_blog_post_data'] like the JS beacon does. Coverage now matches the JS beacon: any render mode that produces a Launchmind article — CPT singular, virtual query, or legacy slug interception — sends one server beacon per render. Bot UA filter, opt-out filter, and the existing 30s dedup window with the JS beacon are all unchanged.
• Plugin version added to beacon body. Both PHP and JS beacons now ship plugin_version in the request body, persisted to event metadata. Lets the backend monitor plugin adoption per customer and verify that fixes like this one are landing on installed sites.

5.3.1

• Fix: PHP error on ACF fields that don’t return a string. The 5.3.0 ACF compatibility hook included a catch-all add_filter('acf/format_value', 'do_shortcode', 10); that fired for every ACF field type, including ones that return arrays, integers or booleans (image, gallery, repeater, true/false, number, relationship, etc.) — and do_shortcode() expects a string. On sites with non-string ACF fields the result was a PHP warning per render, plus the field returning an empty string instead of its actual value. The catch-all has been replaced with a type=text scoped filter, matching the existing type=textarea and type=wysiwyg filters. Net effect: shortcodes still work in text, textarea and wysiwyg ACF fields, but other field types return their native value untouched. Reported by @pippijn on the WordPress.org support forum.

5.3.0

• Q&A articles get their own filter path — three flavours. Articles produced by the new Voice Engine cycle now arrive with is_voice_article: true and an auto-injected “Q&A” tag. Three independent ways for customers to put them on a separate page without writing a line of code: (1) native taxonomy — WordPress automatically maps the “Q&A” tag into a category/post_tag term, so /category/q-and-a (or whatever slug the host theme generates) lists Q&A articles out of the box; (2) shortcode [launchmind_voice limit="6" columns="3"] — drop on any WP page, behaves exactly like [launchmind_blog] but pre-filters to Q&A articles only; (3) block toggle — the existing “Launchmind Blog” Gutenberg block gains a “Show only Q&A articles” toggle in the Filter panel. All three live alongside each other; pick the one that matches your editing workflow.
• Optional “Hide Q&A from main listing” setting. New toggle under Settings → Voice Engine. OFF by default (existing sites keep current behaviour: Q&A articles appear in the main blog listing). Enable it on sites that want a clean separation — Q&A articles only render on the dedicated [launchmind_voice] shortcode, the “Show only Q&A articles” block, or /category/q-and-a. Recommended OFF for most sites; flip it ON when you want a dedicated /qa page that stays distinct from the main blog flow.
• Backward-compatible API gate. is_voice_article is read with a graceful fallback: when the upstream Launchmind API hasn’t yet shipped the field on an older deploy, the plugin re-checks the article’s tags array for “Q&A”. So sites running 5.3.0 against an older API still get correct filtering. No breaking change for any existing shortcode, block, or template — adding 5.3.0 to a 5.2.x site that doesn’t use Q&A articles is a silent no-op.

5.2.0

• Server-side pageview beacon. The plugin now POSTs a pageview from PHP on every actual Launchmind article render — independent of JavaScript, cache plugins, or render-mode globals. Until 5.2 every pageview was tracked client-side via navigator.sendBeacon, 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'] 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 as a tracker domain. Affected sites showed zero traffic in their partner dashboards despite real visitors. The PHP-side beacon fires from template_redirect (deferred to register_shutdown_function so it never blocks the response), resolves the article slug via three independent paths (CPT global → query var → post object), filters out common bot User-Agents, and POSTs the same {subscription_id, article_slug, platform, event_type, source: "server"} payload the JS beacon already sends. Customers who want PHP tracking off can opt out with add_filter('launchmind_disable_server_pageview', '__return_true'); (the JS beacon stays under the existing enable_analytics setting).
• Backend dedup window keeps partner counts honest. 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) 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 — 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.
• Diagnostic meta tag in wp_head. Adds <meta name="launchmind-article" content="<sub>:<slug>:<plugin_version>"> on Launchmind article pages so support / debugging tools can verify a page is actually rendered by …