TASK: reset default replacements for special characters in URI path segment

[PRGfx]

The library slugifying the URI path segment comes with some default replacements. This may cause problems with localization (see #3127).

What I did Everything defined as default replacement is reset to be replaced with an empty string. To provide an option to have this configurable, these replacements can now be provided as a replaceCharacters option to the UriPathSegmentEditor. The configured options are run through the translator, however this probably would only "work well" for editors working in a sensibly localized UI for a corresponding part of the website, i.e. the translator would use the editors language instead of the current documents language afaik.

How I did it The default replacements (as exported by the slugify library) are all reset to empty strings. While some of these may be sensible, I don't trust that there will be more non-localized default-replacements added at some point. The current approach leverages these exports instead of a maybe more generic approach of relying on the editor-options and replacing the default replacements there – after all the UriPathSegmentEditor is only used "once".

How to verify it

• Enter a document title like "a & b" and click the "regenerate" button on the URI path segment editor. It will generate the path "a-b" instead of "a-and-b" as before.
• Define replacements in a NodeTypes configuration like

  'Neos.Neos:Document':
    properties:
      uriPathSegment:
        ui:
          inspector:
            editorOptions:
              replaceCharacters:
                🦄: unicorn
                💾: Neos.Neos:Main:save
  

  Use these replacements in the document title and see the (localized) text getting into the generated path.

I'm not sure about the branch to target. Arguably the current behavior is not intended, however the change might be breaking for people relying on this replacement (which would be odd, especially given the disparity between backend and UI as mentioned in #3127).

[markusguenther]

Hello,

thanks for the PR. The Neos 8.1 is already branched, and we had feature freeze some days ago. I would say this is a feature as we add new configuration, and therefore we need to target 8.2.

Will look into it soonish.

[PRGfx]

We already had multiple projects where this behavior was criticized, so as you plan this function for newer versions only, I implemented this behavior in a separate package. I'll leave that here, in case someone else is interested.

[Sebobo]

@PRGfx, thx for the change.

But do I see correctly that you also changed the current behaviour? I personally don't want and or or or whatever gone from by slugs by default.

[PRGfx]

That's right. However when creating a new document, the backend slugifies the title and does so - in my tests with Neos 5.3 to 7.3 - without these conjunctions. So after all the change only affects slugs regenerated in the UI, making the behavior more consistent with the backend imo. That the freshly created page without changes offers to update the path segment to something different seems odd to me. See the original issue #3127

Plus it currently only replaces &, ♥️ and 🦄 more or less as some kind of example.

I would be fine if the editor was configured to the current default values if really necessary but this being hardcoded is an issue.

[Sebobo]

@PRGfx I just tested this in Neos 7.3 and when I create a new page A and B the slug is a-and-b. Did you change anything in your project?

[PRGfx]

@Sebobo it's about A & B (the three aforementioned symbols; see reproduction steps in the issue). Words stay words. I haven't tested how the UI dependency replaces things, i.e. if it would be possible to replace complete words..

[Sebobo]

@PRGfx, sorry misread. Of course you are correct and it makes sense to adjust the behaviour to be the same. The problem is only that your new setting now only affects updates in the ui and not in the backend, for which we then have no setting currently, correct?

[PRGfx]

Correct. As far as I know the backend has additional handling for other alphabets etc. so I doubt that we can (easily) replicate this consistently in the UI. Imo the better solution would be an API endpoint that can transliterate a given text with the same logic. However this exceeds the scope of a small "bugfix". I can of course close this in favor of a different implementation and install my bugfix package for now. If preferred I can look into a backend API as described.

[Sebobo]

I think having a backend API for this would be best. I recently also had to create a custom version of the UriPathSegment editor as some special rules need to be applied. With an API endpoint it would have been much easier to achieve the same ruleset for both initial creation and later changes which is quite hard with JS and PHP to behave the same.

And I assume this should be a global rule and not document nodetype specific.