Release v2.6.1

Full Changelog: v2.6.0...v2.6.1

Release v2.6.0

Full Changelog: v2.5.1...v2.6.0

Release v2.5.1

Thumbnail Size Display Fix

A follow-up to 2.5.0, fixing a long-standing display bug in the thumbnail size cards.

What was wrong

The cards showed no dimensions at all for the built-in 1536x1536 and 2048x2048 sizes, and Medium Large read 768 × 0.

WordPress registers those two sizes with add_image_size() on plugins_loaded and gives them no *_size_w / *_size_h options — but get_current_image_sizes() read the dimensions from exactly those non-existent options, so they came back empty.

What changed

• Dimensions now come from wp_get_registered_image_subsizes(), which is authoritative and covers every built-in size.
• Those two sizes are also the only built-in ones remove_image_size() can drop from the registry, which is what happens once you disable them here. The fixed dimensions core names them after are kept as a fallback for that case — otherwise a disabled size would lose its dimensions again, or disappear from the list entirely and become impossible to re-enable.
• An unconstrained axis now renders as auto instead of 0, so Medium Large reads 768 × auto. That size is 768px wide at whatever height preserves the aspect ratio.

This is a display-only change. Which thumbnails get generated, and the batch cleanup tool, are untouched.

Verification

Verified against WordPress 7.1: 15 checks covering both the registered and the disabled-and-unregistered path, stale known_sizes rows being corrected rather than preserved, and the legacy false values an older version could have stored. The 2.5.0 media regression suite still passes and Plugin Check is clean.

Screenshots have been retaken so they show the corrected grid.

Full Changelog: v2.5.0...v2.5.1

Release v2.5.0

WordPress 7.1 Compatibility Release

This release adapts the media modules to WordPress 7.1's new client-side media processing pipeline, where the browser uploads the original via REST, generates sub-sizes locally, and sideloads them through /wp/v2/media/{id}/sideload.

Image Resizing

• Keeps media processing server-side while the module is enabled (via the wp_client_side_media_processing_enabled filter). In the client-side flow, a server-side resize of the original either fails core's dimension validation with a 400 error or is silently replaced by the client's own 2560px scaled copy.
• As defense in depth, the resizer also refuses to touch files arriving on the sideload endpoint or on a media create with generate_sub_sizes=false.

File Renaming

• No longer renames files uploaded to the sub-size sideload endpoint. Those names must derive from the attachment's existing (already renamed) file name, otherwise core's naming workaround stops matching and every sub-size lands on a numeric-suffix name.
• The optional date prefix is now idempotent — a name already carrying one is never double-prefixed.

Thumbnail Disabling

• Disabled sizes are now also removed from wp_get_missing_image_subsizes(), which WordPress 7.1 uses to tell the browser which sub-sizes to generate client-side (and which the post-upload recovery has always used). Previously, disabled built-in sizes could quietly come back through those paths.

Thumbnail Cleanup

• Since WordPress 7.1, one physical file can be registered under several size names when sizes share dimensions. The batch cleanup now tracks which files are still referenced by kept sizes, the main file, and the new companion files (source_image, animated_video, animated_video_poster), and never deletes a file that a surviving entry still points to.

SEO Cleanup

• The emoji dns-prefetch removal no longer hardcodes the emoji CDN URL (flagged by Plugin Check) and now handles resource hint entries passed as arrays, which previously raised a PHP 8 TypeError. WordPress 7.1 itself no longer prints this hint; the filter remains for older supported versions.

Verification

Verified against WordPress 7.1 in Docker: 16 functional checks, sideload route toggling over real HTTP, and a clean official Plugin Check run on a packaged copy. Tested up to bumped to 7.1.

Full Changelog: v2.4.1...v2.5.0

Release v2.4.1

Bug fix — recommended for everyone using the file renaming module

The SEO-Friendly Upload File Renaming module was hooked to WordPress's global sanitize_file_name filter. That filter is not upload-specific: WordPress core, themes, and plugins run it over every string they treat as a file name, including generated CSS caches and temp files. The module therefore rewrote names it had no business touching:

passed in	returned before the fix
plugin_cache-layout-2728.css	plugin-cache-layout-2728.css
style_dynamic_theme.css	style-dynamic-theme.css
製品-カタログ.css	css

Any code that writes a cache file under its real name and then reads it back through sanitize_file_name() (or the reverse) silently missed. On a reported site this surfaced as the entire site header — logo and main menu included — rendering nothing at all, on every page, with no PHP error to point at the cause.

The fix

Renaming now runs on wp_handle_upload_prefilter and wp_handle_sideload_prefilter, so only files that are genuinely being uploaded or sideloaded are touched. Nothing else changes:

• The renaming rules are identical (accents transliterated, spaces and underscores to hyphens, non-ASCII stripped, lowercased)
• The date prefix option behaves the same
• The standalone-plugin conflict detection is unchanged
• Existing media files are still never renamed

If you turned the file renaming module off to work around a theme rendering incorrectly, it is safe to turn it back on after updating.

Verified

On a live WordPress 7.0 / PHP 8.2 install: sanitize_file_name() now passes cache-style names with underscores and non-Latin names through untouched, while Café Menü 2024.jpg still becomes cafe-menu-2024.jpg on both the upload and sideload paths, My Photo_01.PNG becomes my-photo-01.png, and the date prefix still yields 2026-08-06-cafe-menu-2024.jpg. PHP 7.4 and 8.2 lint clean; Plugin Check reports no code-level issues.

The same fix ships in the standalone Smart File Renamer 1.2.2, which shares this module's logic.

Full Changelog: v2.4.0...v2.4.1

Release v2.4.0

Highlights

The Meta Tags module now covers single posts and pages, not just the homepage. Both scopes are independent switches, so you can run either one on its own.

New

• Open Graph tags on single posts and pages (Settings > Omni Webmaster > SEO & Optimization, off by default): og:type=article, og:title, og:description, og:url, og:image with width / height / alt text, article:published_time, article:modified_time, plus the Twitter Card tags.
• Article structured data (on by default once the switch above is enabled): BlogPosting / WebPage JSON-LD carrying the headline, publication and modification dates, author, and image, with a self-contained Organization publisher node so the reference resolves without the homepage output.
• Share image fallback chain: featured image → first image in the post content → the site-wide default share image. A content image is resolved back to its attachment (size suffixes such as -1024x768 are stripped first) so full-size dimensions can be emitted; that lookup is cached in a transient keyed by the post's modified time, so editing a post invalidates it.
• Descriptions use the manual excerpt when set, otherwise the first 160 characters of the content, with shortcodes and non-excerpt blocks stripped. Latin text backs off to the last whole word; CJK text is cut at the character limit.

Behaviour notes

• Single-post output is off by default and carries an in-panel warning: most themes already print their own OG tags, and duplicates make social platforms pick the wrong title or image. Check a post's page source for og:title before enabling.
• Password-protected posts never expose their content or content images — only the site-wide default share image is used.
• A static front page always takes the homepage branch, so it never receives article markup.
• The existing SEO plugin detection (Yoast SEO, Rank Math, All in One SEO, SEOPress, The SEO Framework) and the omni_meta_tags_enabled filter suppress both output paths.

New filters

Filter	Default	Purpose
omni_og_type	article (website for pages)	Override the Open Graph object type
omni_og_description_length	160	Maximum generated description length
omni_og_image_size	full	Registered image size used for the share image
omni_og_image_cache_expiration	DAY_IN_SECONDS	Lifetime of the resolved content-image cache

Also in this release

• Bundled Traditional Chinese (zh_TW) translation and the .pot template updated for the new strings.
• README, README.zh-TW, and readme.txt updated; the settings section is now titled "Meta Tags & Structured Data".

Verified

PHP 7.4 and 8.2 lint, plus a live WordPress 7.0 / PHP 8.2 install covering every fallback branch (featured image, content image, default image, password-protected, page, static front page, archives), both switch combinations, the SEO plugin conflict path, and the transient cache — no PHP notices on any request. Plugin Check reports no code-level issues.

Full Changelog: v2.3.0...v2.4.0

Release v2.3.0

Full Changelog: v2.2.0...v2.3.0

Release v2.2.0

Full Changelog: v2.1.2...v2.2.0

Release v2.1.2

What's Changed in 2.1.2

• Plugin Check compliance: Admin-page strings containing markup are now output through wp_kses_post() instead of _e(), and dynamic notices are properly escaped.
• i18n Translation: Added missing translators comment for the custom image size label.
• Package Cleanup: GitHub release packages no longer bundle internal/locale markdown files.

Installation

Download omni-webmaster-seo-suite-v2.1.2.zip below and upload via Plugins > Add New > Upload Plugin in WordPress.