The `&` symbol becomes `amp` in the draft URL

[marcarmengou]

Description

When you type Ampersand & And as the title of an Post and save the Post as a draft, you will see that the URL becomes /ampersand-amp-and/. If you publish the Post, the URL becomes /ampersand-and/.

I was originally going to write this issue asking if it was necessary to add amp to the URL, because from an SEO point of view it makes no sense and just unnecessarily lengthens the URL. However, during initial testing, when publishing the Post, the URL became /ampersand-and/.

Now, I wonder if this may cause confusion to other people. If this is a bug or if it makes any sense for amp to appear in the URL, even if only in drafts. Also, it is not the same with %, $, #, @, or others. For example, if you write Ampersand & And % One # Two $ Three @ Four the URL of the draft will be /ampersand-amp-and-one-two-three-four/

Step-by-step reproduction instructions

1. Go to Settings > Permalinks and set Post name as a permalink structure.
2. Create a Post and type Ampersand & And as the Post title.
3. Save the Post as a Draft.
4. In the editor sidebar click on the URL to view the generated URL. It is this: /ampersand-amp-and/
5. Publish the Post.
6. Chceck URL of the Post. It is this: /ampersand-and/

Screenshots, screen recording, code snippet

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[Soean]

If I call wp.url.cleanForSlug('Ampersand & And'), it returns the correct value ampersand-and. But somewhere is is missing.

[t-hamano]

I'm not an expert on this kind of processing, but this slug is generated by the getEditedPostSlug selector:

gutenberg/packages/editor/src/store/selectors.js

Lines 977 to 983 in ee30a87

	export function getEditedPostSlug( state ) {
	return (
	getEditedPostAttribute( state, 'slug' ) ||
	cleanForSlug( getEditedPostAttribute( state, 'title' ) ) ||
	getCurrentPostId( state )
	);
	}

During this process, the string obtained by getEditedPostAttribute( state, 'title' ) seems to have its HTML entities encoded.

Therefore, this can be resolved by making the following changes, but I'm not sure how this will affect other processing.

diff --git a/packages/editor/src/store/selectors.js b/packages/editor/src/store/selectors.js
index 8b0dfd4b37..f7a990bd8b 100644
--- a/packages/editor/src/store/selectors.js
+++ b/packages/editor/src/store/selectors.js
@@ -16,6 +16,7 @@ import { layout } from '@wordpress/icons';
 import { store as blockEditorStore } from '@wordpress/block-editor';
 import { store as coreStore } from '@wordpress/core-data';
 import { store as preferencesStore } from '@wordpress/preferences';
+import { decodeEntities } from '@wordpress/html-entities';
 
 /**
  * Internal dependencies
@@ -977,7 +978,9 @@ export function getPermalink( state ) {
 export function getEditedPostSlug( state ) {
        return (
                getEditedPostAttribute( state, 'slug' ) ||
-               cleanForSlug( getEditedPostAttribute( state, 'title' ) ) ||
+               cleanForSlug(
+                       decodeEntities( getEditedPostAttribute( state, 'title' ) )
+               ) ||
                getCurrentPostId( state )
        );
 }

[2ndkauboy]

It's not just HTML entities, it's also umlauts. I was about to report the same issue, when I found this one. A post title Für dich & mich would become /fur-dich-amp-mich when instead it should be /fuer-dich-mich.

[APCgit]

Any news on this topic? I have noticed different behavior depending on the context.
When saving a post as a draft, the post slug shows incorrect german umlauts and characters, after publishing the post the slug contains the correct german umlauts and characters. When updating the published post slug, the slug isn't converted correctly:
expected replacement
ß => ss
ä => ae
ö => oe
ü => ue
Actual replacement:
ß => ß (no replacement)
ä => a
ö => o
ü => u
Is an update handled differently than an initial publication?
This problem only exists with Gutenberg, using the Classic Editor plugin, everything is working fine.

[annezazu]

Noting that I can replicate this with WordPress 6.8:

[Mamaduka]

Create a new PR (#70078), which should resolve most cases.

@2ndkauboy, it might be better to report that issue in remove-accents repository. It's a package used internally to handle language-specific accents.

[annezazu]

💥 thanks so much!