Problem
I have my Macbook Screenshot App configured to save screenshots to disk.
I attempted to upload a saved-to-disk screenshot image to WordPress and found that WordPress shows a broken image icon and the Browser returns a 404 when attempting to GET and display the file that has just been uploaded.
The WordPress install has a database which has been running since 2006

Cause
A NARROW NO-BREAK-SPACE is embedded in Screenshot datetime stamp filename and being saved to database as question mark
From the Developer Tools Console you can see the character that the Browser is choking on. It is shown as a question mark between 22 and am in the following image. I believe this was a NARROW NO-BREAK SPACE which has been converted to a question mark when saved to the database. When the image is served back to the Browser the URL has a question mark (which to the Browser thinks is a Query String). Not what we want at all.

Resolution - Fix the database default CHARSET for the postmeta and other tables
Following is a snippet of the WordPress SQL backup file. Note in this CREATE TABLE statement the WordPress database has latin1
charset. This CHARSET couldn't save the NARROW NO-BREAK SPACE to the database properly (instead it substituted it for a ?)
1 2 3 4 5 6 7 8 9 | CREATE TABLE `wp_postmeta` ( `meta_id` bigint unsigned NOT NULL AUTO_INCREMENT, `post_id` bigint unsigned NOT NULL DEFAULT '0' , `meta_key` varchar (255) DEFAULT NULL , `meta_value` longtext, PRIMARY KEY (`meta_id`), KEY `post_id` (`post_id`), KEY `meta_key` (`meta_key`(191)) ) ENGINE=MyISAM AUTO_INCREMENT=45678 DEFAULT CHARSET=latin1; |
Update the postmeta
table and meta_value
column to use utf8mb4
1 2 3 4 | USE mywpdb; ALTER TABLE wp_postmeta DEFAULT CHARACTER SET utf8mb4, MODIFY meta_value LONGTEXT CHARACTER SET utf8mb4; |
Also while you are at it you will probably need to change the CHARACTER SET for other WordPress content tables as they will exhibit the same problem with special characters. Here is an example for changing the CHARACTER SET for the posts table:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | ALTER TABLE `wp_posts` DEFAULT CHARACTER SET utf8mb4, modify `post_content` LONGTEXT CHARACTER SET utf8mb4 NOT NULL , modify `post_title` text CHARACTER SET utf8mb4 NOT NULL , modify `post_excerpt` text CHARACTER SET utf8mb4 NOT NULL , modify `post_status` VARCHAR (20) CHARACTER SET utf8mb4 NOT NULL DEFAULT 'publish' , modify `comment_status` VARCHAR (20) CHARACTER SET utf8mb4 NOT NULL DEFAULT 'open' , modify `ping_status` VARCHAR (20) CHARACTER SET utf8mb4 NOT NULL DEFAULT 'open' , modify `post_password` VARCHAR (255) CHARACTER SET utf8mb4 NOT NULL DEFAULT '' , modify `post_name` VARCHAR (200) CHARACTER SET utf8mb4 NOT NULL DEFAULT '' , modify `to_ping` text CHARACTER SET utf8mb4 NOT NULL , modify `pinged` text CHARACTER SET utf8mb4 NOT NULL , modify `post_content_filtered` LONGTEXT CHARACTER SET utf8mb4 NOT NULL , modify `guid` VARCHAR (255) CHARACTER SET utf8mb4 NOT NULL DEFAULT '' , modify `post_type` VARCHAR (20) CHARACTER SET utf8mb4 NOT NULL DEFAULT 'post' , modify `post_mime_type` VARCHAR (100) CHARACTER SET utf8mb4 NOT NULL DEFAULT '' ; |
After logging into MySQL and running the above the problem was fixed
File system cleanup
If you have uploaded a number of images to test the problem you now have many entries in the WordPress Media Library that are just blank squares (because they point to a filename with a ? in it while the file on disk has a NNBSP)
So delete any records in the Media Library that just show a blank square.
Before you delete each entry take a copy of the URL and then take the file name and edit it to include a NARROW NON-BREAK SPACE as shown in the next code window.
Change to the upload folder and remove those files from disk so you don't have on disk orphan files that don't have a database record pointing to them.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | # modify the filename to remove the ? and add a NNBSP '2025/05/Screenshot-2025-05-23-at-8.35.22?am.png' '2025/05/Screenshot-2025-05-23-at-8.35.22 am.png' # then delete the old file as there is no database record pointing to it cd /path/to/wordpress/wp-content/uploads/2025/05/ rm 'Screenshot-2025-05-23-at-8.23.06 am-6.png' rm 'Screenshot-2025-05-23-at-8.23.06 am-5.png' rm 'Screenshot-2025-05-23-at-8.23.06 am-4.png' rm 'Screenshot-2025-05-23-at-8.23.06 am-3.png' rm 'Screenshot-2025-05-23-at-8.37.54 am-scaled.png' rm 'Screenshot-2025-05-23-at-8.23.06 am-2.png' rm 'Screenshot-2025-05-23-at-8.23.06 am-1.png' rm 'Screenshot-2025-05-23-at-8.35.22 am.png' rm 'Screenshot-2025-05-23-at-8.23.06 am.png' rm 'Screenshot-2025-05-23-at-8.11.01 am-scaled.png' rm 'Screenshot-2025-05-23-at-7.57.11 am-2.png' rm 'Screenshot-2025-05-23-at-7.57.11 am-1.png' |
Work-A-Round
Here are two work-a-rounds so you can continue posting until you resolve the CHARSET problem.
- Configure your MacOS screenshot application to save screenshots to the clipboard and paste the image into the editor instead of uploading it
- Rename the screenshot that was sent straight to disk to remove the narrow no-break space character
For work-a-round 1. press Command + Shift + 5 to bring up your screenshot toolbar and change the output to clipboard

For work-a-round 2. remove the NNBSP by renaming the file before uploading it to WordPress
In the following screenshot the 2nd image has had the offending character removed and it will be able to successfully upload to WordPress and then display in the WordPress default post editor

0 Comments