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.13.0<\/h4>\n\n\n- Changes now arrive within seconds instead of within an hour.<\/strong> The plugin used to check for new articles once an hour, so a freshly approved article could sit and wait, and an article you took offline could stay on your site for another hour. Launchmind now notifies your site the moment something is published, updated or taken offline, and the site fetches it straight away. The hourly run stays in place as the safety net.<\/li>\n
- Your blog page is set up properly on install.<\/strong> The plugin created a bare \/blog page with nothing else on it: no SEO title, no meta description, no menu item, and nothing at all in Sync mode. It now sets the page up completely, in the language of your site, adds it to your main menu if there is no link to it yet, and fills in the SEO fields of Yoast, Rank Math, SEOPress or The SEO Framework. Existing pages are left exactly as they are.<\/li>\n
- Multilingual sites get a blog page per language.<\/strong> On Polylang and WPML the plugin creates one page for each language that your site speaks and that Launchmind delivers, and links them together so the language switcher works.<\/li>\n
- Sync is the new default for fresh installs.<\/strong> Real WordPress posts in your own database, images in your own media library, and content that keeps working even without a Launchmind connection. That last argument for Live mode, being instantly up to date, is gone now that changes are pushed through. Sites that already made a choice keep it.<\/li>\n
- The article count no longer stops at 50.<\/strong> The dashboard counted how many articles it had fetched rather than how many there are, so every customer with a larger library saw the same number. Paging through the list works properly now too.<\/li>\n
- A tidier admin screen.<\/strong> The Analytics tab is gone: it repeated the counters already at the top and had no figures of its own. Settings has moved to its own menu item next to Dashboard and Articles, so what you look at daily and what you set once are no longer mixed together.<\/li>\n<\/ul>\n\n
5.12.1<\/h4>\n\n\n- The readability dot is filled in as well now.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.12.0<\/h4>\n\n\n- Tags are now the article's own keyword, not the whole list.<\/strong> 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.<\/li>\n
- Q&A articles get a category.<\/strong> 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.<\/li>\n
- The SEO dot in the article list is no longer grey.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.9<\/h4>\n\n\n- The sharing image is now exactly 1200x630 on every article.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.8<\/h4>\n\n\n- Fix: the plugin now sets the sharing image tags itself on Yoast sites.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.7<\/h4>\n\n\n- Fix: the sharing image is now its own image, so nothing can override it.<\/strong> 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<\/em> 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.<\/li>\n
- Added the
name=\"image\"<\/code> tag that LinkedIn asks for in its own Post Inspector, alongside the standard tags.<\/li>\n<\/ul>\n\n5.11.6<\/h4>\n\n\n- Fix: the sharing image really is applied now.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.5<\/h4>\n\n\n- Fix: the sharing image now actually reaches Facebook and LinkedIn.<\/strong> 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.<\/li>\n
- Works without an SEO plugin, and with the other ones.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.4<\/h4>\n\n\n- Fix: articles now have a real sharing image.<\/strong> 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 1024x1536 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 1200x630 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.<\/li>\n<\/ul>\n\n
5.11.3<\/h4>\n\n\n- Fix: link previews on Facebook, LinkedIn and WhatsApp.<\/strong> 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.<\/li>\n
- Fix: the preview image size is no longer guessed.<\/strong> The plugin declared every preview image as 1200x630 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.<\/li>\n
- Fix: articles are filed under their real author.<\/strong> 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');<\/code> to your theme.<\/li>\n<\/ul>\n\n5.11.2<\/h4>\n\n\n- Fix: existing articles now get their category and SEO fields too.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.1<\/h4>\n\n\n- Fix: clicking Launchmind opens the dashboard again.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.11.0<\/h4>\n\n\n- Fix: you can now actually edit a synced article.<\/strong> 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.<\/li>\n
- New: articles are filed under their content pillar as a category.<\/strong> 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.<\/li>\n
- New: your SEO plugin's fields are filled in.<\/strong> 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.<\/li>\n
- Keyword tag archives are kept out of search results.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.10.0<\/h4>\n\n\n- In Sync mode your blog overview now comes from your own database too.<\/strong> 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.<\/li>\n
- New: an Articles list in the admin.<\/strong> 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.<\/li>\n
- Safety rail on reconciliation.<\/strong> 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.<\/li>\n
- Trade-off worth knowing: a brand new article appears in the listing once the hourly sync has picked it up, rather than instantly.<\/li>\n
- Fix: Q&A articles are recognised again in Sync mode<\/strong>, so \"show only Q&A\" and \"hide Q&A from the main listing\" work as they should.<\/li>\n
- Fix: an article whose FAQ or summary changed now re-syncs.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.9.6<\/h4>\n\n\n- Fix: Sync mode articles now get our reading styles.<\/strong> 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.<\/li>\n
- The Sync list is paginated at 10 articles per page<\/strong>, 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.<\/li>\n<\/ul>\n\n
5.9.5<\/h4>\n\n\n- Fix: hourly Sync updates were failing every time.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.9.4<\/h4>\n\n\n- Accent colours now pick up Elementor themes too.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.9.3<\/h4>\n\n\n- Translations now use their own proper URL.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.9.2<\/h4>\n\n\n- Sync mode now keeps all your languages.<\/strong> Until now Sync stored one post per article, in your site language only, and a
?lang=<\/code> 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\/<\/code>) and every other language gets its own (\/blog\/my-article-en\/<\/code>). No existing URL moves, so nothing you already rank for is affected.<\/li>\n- Old
?lang=<\/code> links redirect<\/strong> to the right language page instead of silently showing the wrong one, so links you shared earlier keep working.<\/li>\n- hreflang points at the real pages<\/strong> in Sync mode, which is what tells Google these are translations of each other rather than duplicates.<\/li>\n
- From the Sync list you can now reach both sides of an article<\/strong>: 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.<\/li>\n
- The Sync sitemap is built from your own database<\/strong>, so it lists every language and no longer advertises articles that have not been synced yet.<\/li>\n<\/ul>\n\n
5.9.1<\/h4>\n\n\n- Fix: switching to Sync mode no longer breaks your article URLs.<\/strong> After enabling Sync,
\/blog\/{slug}\/<\/code> 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.<\/li>\n- Fix: FAQ schema now also works in Sync mode.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.9.0<\/h4>\n\n\n- New: FAQ schema on every article.<\/strong> 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.<\/li>\n
- New: breadcrumb structured data<\/strong>, so your article shows its place in the site hierarchy in search results instead of a bare URL.<\/li>\n
- Richer article schema.<\/strong> 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.<\/li>\n
- New setting: AI search engine access<\/strong> (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.<\/li>\n
- IndexNow fix: refreshed articles are resubmitted, and the blog path is respected.<\/strong> Two bugs in the existing IndexNow support. It submitted
\/blog\/{slug}<\/code> 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.<\/li>\n- Existing installs keep working unchanged: articles from an older platform response simply skip the new schema blocks.<\/li>\n<\/ul>\n\n
5.8.0<\/h4>\n\n\n- New: Sync content mode \u2014 your articles as real WordPress posts, in your own database.<\/strong> Next to the existing Live mode (articles load straight from Launchmind), you can now choose Sync under Settings \u2192 Content Mode or in the setup wizard. Sync imports every article as a genuine
launchmind_article<\/code> 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}\/<\/code>), so switching modes never moves a page for SEO.<\/li>\n- Why this matters.<\/strong> 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.<\/li>\n
- Safety rails built in.<\/strong> 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 \u2014 nothing is ever hard-deleted. A flaky connection can never mass-draft your library: reconciliation only runs after a complete, error-free pass.<\/li>\n
- New Sync tab<\/strong> on the Launchmind dashboard: last\/next run, progress bar during imports, per-article status list, and a \"Sync now\" button.<\/li>\n
- Server delta support.<\/strong> Incremental runs use the new
updated_since<\/code>\/deleted_since<\/code> API parameters when available and fall back to full hash-based comparison on older servers.<\/li>\n- 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.<\/li>\n<\/ul>\n\n
5.7.1<\/h4>\n\n\n- New:
intro=\"\"<\/code> attribute on [launchmind_blog]<\/code> for a per-page custom welcome line.<\/strong> Replaces the auto-generated \"Welcome to {site name}'s blog\u2026\" copy with whatever the customer types, without forcing show_intro=\"false\"<\/code> + 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.\"]<\/code>.<\/li>\n- Settings page: Shortcode Reference card rewritten as a copy-paste cookbook.<\/strong> Adds clearly-labeled examples for the 5.7.0
wp_post_types<\/code> merge, the new intro=\"\"<\/code> 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.<\/li>\n<\/ul>\n\n5.7.0<\/h4>\n\n\n- New:
[launchmind_blog]<\/code> shortcode merges any post type, not just native post<\/code>.<\/strong> Adds a wp_post_types<\/code> 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\"]<\/code>. Default stays wp_post_types=\"post\"<\/code> so existing installs are unaffected. Sanitized with sanitize_key()<\/code> per slug; empty\/garbled values fall back to post<\/code>. Solves the page-builder edge case where Elementor Pro's Posts widget can't easily merge two post types in one query \u2014 drop the shortcode into an HTML\/Shortcode widget instead and the merge happens server-side.<\/li>\n- Why this matters.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.3.6<\/h4>\n\n\n- Fix:
launchmind_article<\/code> CPT now passes Elementor Pro's second visibility gate (show_in_nav_menus<\/code>).<\/strong> v5.3.5 set show_ui=true<\/code> 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])<\/code> \u2014 the standard WP convention for \"linkable content types\". Our CPT had show_in_nav_menus=false<\/code> 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<\/code> to track page_builder_compat<\/code> so both gates open together. JetEngine was unaffected by either gate; this only matters for Elementor Pro \/ Loop Grid \/ similar.<\/li>\n- Side effect: \"Launchmind Articles\" now appears in Appearance \u2192 Menus.<\/strong> 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.<\/li>\n<\/ul>\n\n
5.3.5<\/h4>\n\n\n- Fix:
launchmind_article<\/code> CPT now visible to Elementor Pro + other page-builder Post widgets.<\/strong> The CPT registration hardcoded show_ui=false<\/code> 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<\/code>, 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<\/code> now tracks page_builder_compat<\/code> (same as public<\/code>, publicly_queryable<\/code>, and show_in_rest<\/code> already did). Admin sidebar suppression is independently controlled by show_in_menu=false<\/code> 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.<\/li>\n- No customer action needed.<\/strong> Existing JetEngine \/ Bricks \/ Breakdance integrations continue to work unchanged.<\/li>\n<\/ul>\n\n
5.3.4<\/h4>\n\n\n- Fix: legacy
lm_<slug>_<random><\/code> API keys couldn't auto-resolve subscription_id.<\/strong> v5.3.3's auto-heal path only matched the modern lm_<uuid>_<random><\/code> key format. Customers who signed up before the UUID switch have keys shaped like lm_broadwick_f7670e70...<\/code> \u2014 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<\/code> (already authenticated via api_key) and reads subscription.id<\/code> 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<\/code> in its response shape \u2014 read by 5.3.4+ plugins, ignored by older ones.<\/li>\n