Title: Launchmind Blog
Author: launchmind
Published: <strong>2025年12月28日</strong>
Last modified: 2026年5月12日

---

プラグインを検索

![](https://ps.w.org/launchmind-blog/assets/banner-772x250.png?rev=3497445)

![](https://ps.w.org/launchmind-blog/assets/icon-256x256.png?rev=3497313)

# Launchmind Blog

 作者: [launchmind](https://profiles.wordpress.org/launchmind/)

[ダウンロード](https://downloads.wordpress.org/plugin/launchmind-blog.5.7.1.zip)

 * [詳細](https://ja.wordpress.org/plugins/launchmind-blog/#description)
 * [レビュー](https://ja.wordpress.org/plugins/launchmind-blog/#reviews)
 *  [インストール](https://ja.wordpress.org/plugins/launchmind-blog/#installation)
 * [開発](https://ja.wordpress.org/plugins/launchmind-blog/#developers)

 [サポート](https://wordpress.org/support/plugin/launchmind-blog/)

## 説明

Display AI-powered Launchmind blog content on your WordPress site.

### Testing

**For WordPress.org Reviewers:**

A demo API key is available for testing purposes:

    ```
    lm_test_demo1234567890
    ```

This key provides access to 6 sample blog articles for testing the plugin functionality.

**Test the connection:**

 1. Install and activate the plugin
 2. Go to **Launchmind** in the WordPress admin sidebar
 3. Click the **Settings** tab
 4. Enter the demo API key: `lm_test_demo1234567890`
 5. Click **Save Settings**
 6. Click **Test Connection** – should show “Connection successful”
 7. Go to the **Articles** tab to see 6 sample posts
 8. Add the Gutenberg block (`Launchmind Blog`) or use shortcode `[launchmind_blog]`
    on any page

**Sample articles included:**

 * 10 Tips to Boost Your E-commerce Conversion Rate
 * The Ultimate Guide to SEO for Online Stores
 * How to Create a Winning Product Description
 * Email Marketing Strategies That Actually Work
 * Social Media Marketing for Small Businesses
 * Customer Retention: How to Keep Customers Coming Back

**Getting your own API key:**

Sign up at [launchmind.io](https://launchmind.io) to get your personal API key for
production use.

### Privacy Policy

This plugin connects to external Launchmind.io servers to fetch blog content. By
using this plugin, you agree to Launchmind’s [Terms of Service](https://launchmind.io/terms)
and [Privacy Policy](https://launchmind.io/privacy).

**Data transmitted:**
 * Your Launchmind API key (for authentication) * Content 
requests (post slugs, language preferences)

**Data NOT transmitted:**
 * Personal data of your WordPress site visitors * WordPress
user information * Any other site data

All API communication uses HTTPS encryption.

## スクリーンショット

 * [[
 * Modern admin dashboard with article overview
 * [[
 * Gutenberg blog list block in the editor
 * [[
 * Single post block displaying article content

## ブロック

このプラグインは2個のブロックを提供します。

 *   Launchmind Blog
 *   Launchmind Single Post

## インストール

 1. Upload the plugin to `/wp-content/plugins/launchmind-blog`.
 2. Activate the plugin through the Plugins menu in WordPress.
 3. Navigate to the Launchmind menu item (left sidebar) and enter your API key.
 4. Add a Gutenberg block (`Launchmind Blog`) or use the shortcode `[launchmind_blog]`
    on any page.

## FAQ

### Where do I find my API key?

Log in to your [Launchmind Dashboard](https://launchmind.io/backlinks/dashboard)
and navigate to the “Webshop Plugins” tab. Your API key is displayed in the green
box.

### Can I use shortcodes instead of Gutenberg blocks?

Yes! Use `[launchmind_blog limit="6" columns="3"]` for a blog list or `[launchmind_post
slug="your-post-slug"]` for a single post.

### Does this plugin track my visitors?

No. This plugin only communicates with Launchmind servers to fetch your blog content.
No personal data from your site visitors is collected or transmitted.

### What data is sent to Launchmind?

Only 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.

### Is the “Powered by Launchmind” branding required?

No. The branding is disabled by default. You can optionally enable it in the block
settings or shortcode attributes if you wish to display it.

## 評価

![](https://secure.gravatar.com/avatar/7ef8a127a2a91ba373437755b9f92edef6ca2b943e2b7e147d0c1b35f3ffcf7b?
s=60&d=retro&r=g)

### 󠀁[Fijne WordPress-plugin voor SEO zonder gedoe](https://wordpress.org/support/topic/fijne-wordpress-plugin-voor-seo-zonder-gedoe/)󠁿

 [harrie07](https://profiles.wordpress.org/harrie07/) 2026年1月6日

Ik gebruik de Launchmind WordPress-plugin nu een tijdje en wat mij vooral aanspreekt
is hoe weinig tijd het kost. SEO stond altijd wel op mijn lijstje, maar eerlijk 
gezegd kwam het er vaak niet van omdat het zoveel handmatig werk is. Na de onboarding
was eigenlijk alles duidelijk. De blogs worden automatisch aangemaakt en ik krijg
ze per mail ter goedkeuring. Met één klik staat het artikel live op mijn site. Ik
hoef niet meer in WordPress te rommelen of teksten te kopiëren en plakken. Wat ik
prettig vind, is dat ik wel de controle houd. Als iets niet past, keur ik het gewoon
niet goed. De content sluit goed aan bij mijn website en is duidelijk geschreven
met zowel Google als AI-tools in gedachten. Voor de prijs die je betaalt is dit 
een fijne oplossing. Een SEO-specialist of marketeer kost al snel duizenden euro’s
per maand, terwijl dit veel werk uit handen neemt voor een fractie daarvan. Voor
mij werkt het vooral omdat het consistent doorgaat zonder dat ik er steeds bovenop
moet zitten. Al met al een handige plugin als je wel aan SEO wilt doen, maar geen
zin hebt in gedoe.

![](https://secure.gravatar.com/avatar/93ca26b8a91e1b017f3f34e6342b88adcef92c5b2c1454220080ebf5f25cbb9a?
s=60&d=retro&r=g)

### 󠀁[Already getting traffic](https://wordpress.org/support/topic/already-getting-traffic/)󠁿

 [voortkasumov](https://profiles.wordpress.org/voortkasumov/) 2025年12月29日

After just 3 weeks we are already getting visitors coming from various AI models.
Can not wait to see the results snowball even more. Next best thing.

![](https://secure.gravatar.com/avatar/8e11de7a9fa47ba255b598176ad12702f2168c703c3e2f9feb7d866d52554b40?
s=60&d=retro&r=g)

### 󠀁[Perfect for AI engines and SEO](https://wordpress.org/support/topic/perfect-for-ai-engines-and-seo/)󠁿

 [cormanders](https://profiles.wordpress.org/cormanders/) 2025年12月28日

Does exactly what it promises LaunchMind automatically creates and publishes GEO
and SEO optimized blogs that help my website appear in AI engines and AI answers.
It saves a lot of time and already brings in more qualified traffic. Highly recommended.

 [ 3件のレビューをすべて表示 ](https://wordpress.org/support/plugin/launchmind-blog/reviews/)

## 貢献者と開発者

Launchmind Blog はオープンソースソフトウェアです。以下の人々がこのプラグインに貢献
しています。

貢献者

 *   [ launchmind ](https://profiles.wordpress.org/launchmind/)

[“Launchmind Blog” をあなたの言語に翻訳しましょう。](https://translate.wordpress.org/projects/wp-plugins/launchmind-blog)

### 開発に興味がありますか ?

[コードを閲覧](https://plugins.trac.wordpress.org/browser/launchmind-blog/)するか、
[SVN リポジトリ](https://plugins.svn.wordpress.org/launchmind-blog/)をチェックする
か、[開発ログ](https://plugins.trac.wordpress.org/log/launchmind-blog/)を [RSS](https://plugins.trac.wordpress.org/log/launchmind-blog/?limit=100&mode=stop_on_copy&format=rss)
で購読してみてください。

## 変更履歴

#### 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 the plugin without trawling logs.
   Self-guards on the same `is_singular` check as the beacon — no-op on non-Launchmind
   pages.
 * **Click beacon labelled `source: "client"`** for symmetry with the new server-
   side flag. No behavior change — clicks remain JS-only because outbound link interception
   requires a browser-side DOM listener.
 * 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.

#### 5.1.11

 * **WhatsApp / Telegram / Signal link previews now show the cover image.** 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/` transformation endpoint with `width=1200&height=630&quality=80&resize
   =cover`. 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—
   they either auto-optimize or already serve appropriately sized files. No new 
   options.
 * **Settings tab now documents the unified-blog shortcode pattern.** The Shortcode
   and Examples sections now show the `[launchmind_blog limit="6" columns="2" include_wp_posts
   ="true"]` 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` and `offset` 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.

#### 5.1.10

 * **Two new routes for page-builder Post Loop coverage.** 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`, `image_downsize`, `wp_get_object_terms`,
   and friends should have intercepted those calls. Two additions in 5.1.10: (1)
   the `launchmind_article` CPT now declares `category` and `post_tag` 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`,
   the WordPress object cache is now prewarmed with `_thumbnail_id` meta for each
   post, so builders that consult `wp_cache_get` before falling back to raw SQL 
   still find the correct sentinel ID. Strictly additive — installs that already
   render fine on 5.1.6/5.1.7/5.1.8/5.1.9 keep working unchanged.

#### 5.1.9

 * **Topbar contrast fix for builder-managed “sticky on scroll” headers.** The 5.1.5/
   5.1.7 sticky-offset + brand-colour backdrop only fired for headers whose CSS `
   position` was already `fixed` or `sticky` on first paint. Many Breakdance, Elementor
   Pro, and Divi sites build their topbar as `position: absolute` over a transparent
   hero and only switch it to `position: fixed` _after_ the visitor scrolls — those
   builders use class names like `bde-header-builder--sticky-scroll-`, `elementor-
   sticky`, `et_pb_sticky_module`. 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` attribute), so the
   offset and the brand-colour backdrop both apply. No-op on installs that don’t
   use any sticky-on-scroll header.

#### 5.1.8

 * **Page-builder pill cleanup + extra term-resolution coverage.** 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` / `
   post_tag` terms emitted for Launchmind cards are now capped at **2 tags max**,
   with **2 words max per tag**, 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` / `launchmind_blog_card_max_words`
   for themes that do render multi-pill cards. (2) Term injection now also hooks
   the lower-level `wp_get_object_terms` filter as a backup path — some builder 
   configurations resolve term relationships via direct calls that bypass `get_the_terms`,
   which would leave virtual cards with empty pills despite our `get_the_terms` 
   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).

#### 5.1.7

 * **Auto-detect brand colour for the article-page topbar backdrop.** 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** by sampling
   the topbar’s actual background colour on the homepage and using that on the article
   page. Mechanism: the sticky-detect script loads `/` 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` 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 — sites that block iframe-of-self via `X-Frame-Options
   DENY`, 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.

#### 5.1.6

 * **Critical fix for 5.1.5 page-builder rendering.** 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>` and with an empty pill. Root cause: the `virtual_thumbnail_id`,`
   virtual_thumbnail`, `virtual_has_thumbnail`, and `virtual_terms` filters all 
   called `get_post($virtual_id)` to resolve the article, but virtual Launchmind
   posts have no `wp_posts` row — 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` and an empty term list and skipped
   emitting the inline `<style> background-image: url(...)` block + the pill text.
   The plugin now keeps a request-scoped `post_id  API payload + slug` registry 
   populated by `Launchmind_Blog_Merge::to_wp_post()` (and `Launchmind_CPT::build_virtual_post()`
   on the single-post path), and every CPT-aware filter resolves through the registry
   instead of through `get_post()`. Confirmed on Twentynext: cover images and category
   pills now render on Launchmind cards alongside native posts.

#### 5.1.5

 * **Page-builder cards now render the cover image.** 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` through `wp_get_attachment_image_src()` — a path
   that hits the attachment row in `wp_posts` and returned an empty `<img>` for 
   our virtual posts. The plugin now intercepts `image_downsize`, `wp_get_attachment_url`
   and `wp_get_attachment_image_src` 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` filter runs).
 * **Page-builder cards now render category / tag pills.** Builders that loop `get_the_terms(
   $post, 'category')` or `get_the_terms($post, 'post_tag')` 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` objects built
   from the article’s API tags whenever a builder asks for `category` or `post_tag`
   on a `launchmind_article` post — pills now show meaningful labels with no setup.
   Custom-named taxonomies (e.g. `news_category` on bespoke themes) can opt in via
   the new `launchmind_blog_card_taxonomies` filter. Term archive links resolve 
   to `#` since the synthesized terms have no real archive page.
 * **Topbar contrast auto-fix on single-article pages.** Some themes (Twentynext-
   style agency themes, Wix imports, modern boutique designs) use a transparent `
   position: fixed` 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` now samples the topbar’s actual text colour and 
   effective background colour, computes the contrast, and — only when there is 
   a real contrast collision — sets `--lm-topbar-backdrop` 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` in their theme —
   the script reads that first and uses it verbatim. Pages where the existing topbar
   already has sufficient contrast see no change.
 * **Sticky-offset rules and detector now apply to CPT-mode (`single-launchmind_article`)
   too.** 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`,
   which the rules silently skipped. Both classes are now covered.

#### 5.1.4

 * **Page builder Post Loops now show Launchmind articles next to native posts.**
   The `launchmind_article` custom post type registers as `public` / `publicly_queryable`/
   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` that those widgets run is now intercepted**—
   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` rows. The plugin now injects Launchmind virtual posts into any secondary
   query whose `post_type` clause names `launchmind_article`, sorts the combined
   feed by publish date, and rewrites `found_posts` 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 — 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  Launchmind Blog  “Page Builder Compatibility”(
   default ON).
 * **Setup polish.** 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.
 * **Documentation.** Added a “Page Builders (Breakdance, Elementor, Bricks, Oxygen)”
   help section to Settings  Launchmind Blog with concrete steps for adding `Launchmind
   Articles` to a Post Loop / Query widget. The internal post-type slug (`launchmind_article`)
   is documented for builders that ask for the slug rather than the human label.

#### 5.1.3

 * 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` and `admin.php?page=launchmind-blog`), 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`). After upgrading, the setup wizard’s finish button and the welcome
   notice both land on the real Launchmind dashboard.

#### 5.1.2

 * 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 — existing
   installs benefit on next pageview. Companion server-side fix to the `metadata.
   platform` filter ensures plugin-tracked customers correctly appear in the partner
   dashboard’s per-article breakdown.

#### 5.1.1

 * 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—
   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` 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.

#### 5.1.0

 * **Resilience: stale-while-revalidate cache.** 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 — this is a graceful-degradation safety net, not a longer
   cache.
 * **Resilience: bandwidth + latency win via ETag/If-None-Match.** The API client
   now persists ETags returned by the Launchmind API and sends them back as `If-
   None-Match` on the next request. When content hasn’t changed, the upstream returns`
   304 Not Modified` with no body — we re-use the cached value without a fresh download.
   At fleet scale this cuts plugin  API bandwidth by roughly 80% during steady-state,
   and shaves response latency on cache-revalidations.
 * **Resilience: 8s API timeout (down from 30s).** 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
   fall back to cached content) instead of stalling the whole page.
 * **Scale: jittered cache TTLs.** Cache expiry is now scattered with ±60 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.
 * **Scale: object-cache promotion.** 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.
 * **Scale: chunked sitemap storage.** 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()`, and partial fetch failures (page 3 fails) no longer
   wipe the chunks that did load. Sitemap XML output is byte-identical.
 * **Edge cache headers on single-post pages.** Launchmind article responses now
   emit `Cache-Control: public, max-age=300, stale-while-revalidate=60` 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.
 * **Security: tracking script no longer ships the API key to the browser.** 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`
   on its own; the API key is now kept server-side only and the inline script ships
   nothing more sensitive than the subscription ID.
 * **Visibility: daily plugin-health beacon.** The plugin now sends a once-a-day,
   fire-and-forget POST to `/api/plugin-health` 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');`.
 * 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.

#### 5.0.1

 * Fixed: On host themes that pin a `position: fixed` topbar to the viewport without
   compensating the single-post template with matching padding, the article title
   sat under the topbar at first paint — 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.
    - Adds `public/js/launchmind-sticky-detect.js` (≈1 KB), a vanilla detector that
      measures the actual height of any `position: fixed` / `position: sticky` element
      pinned at `top: 0` and writes the result (plus a 16px buffer) to a new CSS
      variable `--lm-sticky-offset` on `<html>`.
    - Adds scoped CSS rules under `body.single-launchmind_post` that consume that
      variable on the article title (matching the common WordPress h1 classes: `.
      entry-title`, `.wp-block-post-title`, `.post-title`, `.article-title`, plus
      generic `.entry-header h1` / `article > header h1`) and on `scroll-padding-
      top` so jump-links also land below the topbar.
    - Default value of `--lm-sticky-offset` is `0px`. On installs _without_ a sticky
      topbar (the vast majority) the detector finds nothing, the variable stays 
      at zero, and these rules are no-ops — existing layouts are byte-for-byte unchanged.
    - The script is enqueued only on single Launchmind posts (`is_singular('launchmind_post')`)
      so non-article pages never load it. Loads in the footer so it sees every theme-
      injected sticky element. Re-runs on `load` and on `resize` 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.
 * No PHP API, database, settings, shortcode or rendering-mode change. Drop-in upgrade
   for every existing 5.0.x install.

= 5.0.0 …

## メタ

 *  バージョン **5.7.1**
 *  最終更新日 **2週間前**
 *  有効インストール数 **10未満**
 *  WordPress バージョン ** 5.8またはそれ以降 **
 *  検証済み最新バージョン: **6.9.4**
 *  PHP バージョン ** 7.4またはそれ以降 **
 *  言語
 * [English (US)](https://wordpress.org/plugins/launchmind-blog/)
 * タグ
 * [AI](https://ja.wordpress.org/plugins/tags/ai/)[articles](https://ja.wordpress.org/plugins/tags/articles/)
   [blog](https://ja.wordpress.org/plugins/tags/blog/)[content](https://ja.wordpress.org/plugins/tags/content/)
   [seo](https://ja.wordpress.org/plugins/tags/seo/)
 *  [詳細を表示](https://ja.wordpress.org/plugins/launchmind-blog/advanced/)

## 評価

 5つ星中5つ星

 *  [  3 5-星レビュー     ](https://wordpress.org/support/plugin/launchmind-blog/reviews/?filter=5)
 *  [  0 4-星レビュー     ](https://wordpress.org/support/plugin/launchmind-blog/reviews/?filter=4)
 *  [  0 3-星レビュー     ](https://wordpress.org/support/plugin/launchmind-blog/reviews/?filter=3)
 *  [  0 2-星レビュー     ](https://wordpress.org/support/plugin/launchmind-blog/reviews/?filter=2)
 *  [  0 1-星レビュー     ](https://wordpress.org/support/plugin/launchmind-blog/reviews/?filter=1)

[Your review](https://wordpress.org/support/plugin/launchmind-blog/reviews/#new-post)

[すべてのレビューを見る](https://wordpress.org/support/plugin/launchmind-blog/reviews/)

## 貢献者

 *   [ launchmind ](https://profiles.wordpress.org/launchmind/)

## サポート

過去2ヶ月以内に解決した問題:

     1 / 1

 [サポートフォーラムを表示](https://wordpress.org/support/plugin/launchmind-blog/)