FAQ

A WordPress plugin that automatically generates the featured and social image for every post, rendered locally from your actual content — no design tool, no external API.

No. Every template is built visually in the Template Editor — dragging and positioning layers directly on a live preview. There’s no code or markup to write for any part of it.

No tool can guarantee exactly how a given platform renders a preview at any moment — caching and per-platform quirks are outside any plugin’s control. What ThumbnailWP guarantees is that the image itself is rendered at the exact size and ratio each platform expects, and offered directly to your SEO plugin’s own social image field.

An image existing isn’t the same as a platform actually displaying it — Facebook, LinkedIn, and Twitter each reject or badly crop images that don’t match their real minimum size and ratio. ThumbnailWP renders at those exact dimensions per aspect ratio family, not a single generic size.

Detection covers Bricks, Elementor, Divi, and Oxygen, alongside the native block editor — see Integrations. Detection here is informational: it confirms compatibility, but doesn’t change how an image is generated, since generation happens independently of whichever builder built the page.

Yes, both, as dynamic content sources for any Text or Image layer — a field on the post itself, or (for Image layers) an image field. See the Dynamic Tags Reference.

WooCommerce is detected on your site, informational for now — there’s no dedicated WooCommerce-specific dynamic tag yet (price, SKU, stock), though a product page can still use a template like any other post.

No — ThumbnailWP writes its generated image directly into Yoast SEO’s, RankMath’s, SEOPress’s, The SEO Framework’s, and Squirrly SEO’s own social image field, but only if that field is still empty. It never overwrites a value already set. AIOSEO isn’t directly wired in; it picks up the image through WordPress’s own featured image instead.

There’s no dedicated headless endpoint, but the generated image is a completely normal WordPress attachment — any headless frontend already reading your site’s featured image through the standard WordPress REST API gets ThumbnailWP’s generated image the same way, with nothing extra to set up.

There’s no site-wide status screen yet. The most direct way is checking a post’s own featured image after publishing, or using Check the real output while editing a template to confirm exactly what will render before it’s live.

No — an image is only ever generated once, at the moment a post is published, regenerated, or bulk-processed. From then on, it’s a normal static image file, served exactly like any other media in your library.

Deactivating stops automatic generation — nothing already generated is touched. On full removal, you choose beforehand under Settings → Privacy: keep everything, remove settings only, or remove settings and every image ThumbnailWP generated.

Any public WordPress content type that supports a featured image — posts, pages, and most custom post types (including WooCommerce products) out of the box, with no limit on how many you use it with.

No built-in limit on either.

Partial support exists (French and Spanish), currently covering the Dashboard, Integrations, and Settings screens — the Template Editor itself is still English-only, with full coverage planned.

No. GD is the only requirement — it’s included on virtually every WordPress host by default. Imagick is detected and used automatically when available (slightly better image quality on some operations), but ThumbnailWP renders identically either way. Nothing to configure, nothing that breaks if your host only has GD.

thumbnailwp_image_generated (action) — fires right after a generated image is set as a post’s featured image, with $post_id and $attachment_id as arguments. This is what Integrations\SeoImageInjector listens to internally to also offer the image to your SEO plugin — the same hook is available for your own custom code.

Not through the admin UI today — ThumbnailWP ships with 5 bundled font families (Fira Sans, Poppins, Oswald, Playfair Display, Caveat). The rendering engine itself accepts any local TTF file, so a developer could extend the plugin’s own font list in code, but there’s no upload feature for site owners yet.

No — none, anywhere in the codebase. Every image is rendered locally with GD or Imagick, using fonts and emoji bundled with the plugin. Nothing is sent to a third-party service at generation time.

It’s a standard WordPress admin-ajax.php action, gated by a nonce and a capability check — the same rendering pipeline used for real generation, returned as a base64 image instead of being saved. It only ever runs for a logged-in user with permission to manage ThumbnailWP.

Neither, in the usual sense — an image is generated once (on publish, on demand, or in bulk) and saved as a real WordPress attachment. From then on it’s served like any other static media file; there’s no per-request rendering or TTL-based cache to manage.

ThumbnailWP writes directly to each plugin’s own postmeta key, only when it’s empty: _yoast_wpseo_opengraph-image/-image-id for Yoast, rank_math_facebook_image/_id for RankMath, _seopress_social_fb_img for SEOPress, _social_image_url/_id for The SEO Framework, and _sq_fp_ogimage for Squirrly SEO. AIOSEO stores its data in its own database table rather than postmeta, so it isn’t covered directly — it picks up the image through the regular featured image instead.

Every attachment it creates gets a _thumbnailwp_generated postmeta flag at the moment it’s created. Cleanup — an old image being replaced, or a post being permanently deleted — only ever removes an attachment carrying that exact flag. An image you uploaded or picked yourself is never touched, no matter how similar its filename looks.

Depends on the choice made under Settings → Privacy: keep everything, remove the plugin’s own settings only, or remove settings and every image carrying the _thumbnailwp_generated flag. Deactivating alone removes nothing.

Yes — each regeneration creates a brand-new attachment with its own URL rather than overwriting the file in place. The previous one is then removed automatically via the orphaned-image cleanup described above, so it never lingers as an unused file.