You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Fixes the following bug when creating a template for a single post:
Create post with a long non-latin title: ΰΈ£ΰΈ΅ΰΈ§ΰΈ΄ΰΈ§ Secretlab MAGNUS Pro Lamborghini Edition: ΰΉΰΈ‘ΰΈ·ΰΉΰΈΰΉΰΈΰΉΰΈ°ΰΉΰΈΰΈ‘ΰΈ‘ΰΈ΄ΰΉΰΈΰΉΰΈ‘ΰΉΰΉΰΈΰΉΰΉΰΈΰΉΰΉΰΈΰΉΰΈ° ΰΉΰΈΰΉΰΈΰΈ·ΰΈ βSupercarβ ΰΉΰΈΰΈ«ΰΉΰΈΰΈΰΈΰΈΈΰΈ
Go to Site Editor, Templates, click "Add Template", choose "Single item: Post", for a specific post, and choose the new post with the long title as the post that the template applies to.
Creating the template will fail, the REST request will return a 500 internal server error and there will be a PHP fatal on the server.
What happened?
The post has a long title, and the database column for post slugs (wp_posts.post_name) is limited to 200 chars. The new post's slug will be longer than that, especially when urlencoded. But the PHP sanitize_title_with_dashes function in Core will correctly truncate it to 200 chars, carefully respecting boundaries of utf-8 multiple-byte characters and of urlencoded octets.
Things get worse when Gutenberg tries to create a template from this post, generating a slug with a prefix: single-post-${ postSlug }. Here we are acting on urlencoded postSlug and the urlencoded template slug (now longer than 200 chars) will be sent as payload of the REST request that creates the template.
Unfortunately sanitize_title_with_dashes is careful only when dealing with a string that's not urlencoded. It correctly truncates and encodes raw utf-8 characters. But an urlencoded string will be truncated bluntly, and we're left with a slug that's not a valid urlencoded string. It looks something like ...%b8%81%e.
Things will start going downhill. The create_item function of the templates controller will crash. Requests to DELETE the new template will be rejected by the Apache server itself, because the URL contains the wrongly encoded slug.
I'm fixing this by decoding the original post slug before appending the prefix. Then the REST request will contain a slug string with raw utf-8 characters, and sanitize_title_with_dashes will be able to truncate it nicely.
We should also do a companion Core patch that addresses the crashes. But this Gutenberg fix is good enough to get rid of the issue.
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.
If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.
I think that until very recently, REST API didn't support non-Latin chars in template names/slugs.
In the post slugs themselves, non-latin has been supported for 20 years, at least that's what git blame for the sanitize_title_with_dashes function tells me.
I believe there are additional areas where similar fixes may be necessary. One area is the Templates dropdown in the post editor.
This code (CreateNewTemplateModal) constructs the slug for the new template in a way that strips all non-latin characters. Not strictly wrong, but very suboptimal. After I fix this I get some further failures down the line, when trying to set the new template as the template for the post. This will need more work π
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the following bug when creating a template for a single post:
ΰΈ£ΰΈ΅ΰΈ§ΰΈ΄ΰΈ§ Secretlab MAGNUS Pro Lamborghini Edition: ΰΉΰΈ‘ΰΈ·ΰΉΰΈΰΉΰΈΰΉΰΈ°ΰΉΰΈΰΈ‘ΰΈ‘ΰΈ΄ΰΉΰΈΰΉΰΈ‘ΰΉΰΉΰΈΰΉΰΉΰΈΰΉΰΉΰΈΰΉΰΈ° ΰΉΰΈΰΉΰΈΰΈ·ΰΈ βSupercarβ ΰΉΰΈΰΈ«ΰΉΰΈΰΈΰΈΰΈΈΰΈ
What happened?
wp_posts.post_name
) is limited to 200 chars. The new post's slug will be longer than that, especially when urlencoded. But the PHPsanitize_title_with_dashes
function in Core will correctly truncate it to 200 chars, carefully respecting boundaries of utf-8 multiple-byte characters and of urlencoded octets.single-post-${ postSlug }
. Here we are acting on urlencodedpostSlug
and the urlencoded template slug (now longer than 200 chars) will be sent as payload of the REST request that creates the template.sanitize_title_with_dashes
is careful only when dealing with a string that's not urlencoded. It correctly truncates and encodes raw utf-8 characters. But an urlencoded string will be truncated bluntly, and we're left with a slug that's not a valid urlencoded string. It looks something like...%b8%81%e
.create_item
function of the templates controller will crash. Requests to DELETE the new template will be rejected by the Apache server itself, because the URL contains the wrongly encoded slug.I'm fixing this by decoding the original post slug before appending the prefix. Then the REST request will contain a slug string with raw utf-8 characters, and
sanitize_title_with_dashes
will be able to truncate it nicely.We should also do a companion Core patch that addresses the crashes. But this Gutenberg fix is good enough to get rid of the issue.