Releases: ivanusto/smart-file-renamer
Release list
Release v1.3.0
Release v1.2.3
Contributors
Assets 3
Release v1.2.2
Bug fix — please update
Renaming 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 plugin 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 one reported site this surfaced as the theme's entire header — logo and main menu included — rendering nothing at all, 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
- Existing media files are still never renamed
Verified on a live WordPress install: sanitize_file_name() now passes cache-style and non-Latin names through untouched, while Café Menü 2024.jpg still becomes cafe-menu-2024.jpg on both the upload and sideload paths, and the date prefix still yields 2026-08-06-my-photo-01.png.
The same fix ships in Omni Webmaster & SEO Suite 2.4.1, which shares this module's logic.
Full Changelog: v1.2.1...v1.2.2
Release v1.2.1
Full Changelog: v1.2.0...v1.2.1
