Automatic alias generation includes "/" from pagetitle, friendly_alias_restrict_chars_pattern doesn't replace?

I have many resources with pagetitles that contain a forward slash "/" character, and I'm hoping to have the automatic alias generation replace every / with a - like is done with the other characters like & ? etc. Its main problem is that it is visually incorrect, and might possibly confuse or irritate search engines.

So I added \/ (backslash, forward slash) to the end of the regex friendly_alias_restrict_chars_pattern so it now reads:



(I added the 3rd- and 2nd-to-last characters beyond what was there by default.)

It made no difference, meaning that my automatically generated aliases still contain the forward slash.

I use use_alias_path set to Yes, if that makes a difference (as in, some full friendly URLs contain a "/" when they are nested underneath container resources to show the nesting).

Of course I can go manually changing them all, but when my user will add new resources whose pagetitles contain the / character, they will come back.

Many thanks if anyone can help me figure out how to translate / to - in automatically generated friendly URL aliases.

watou

I believe what you really want is not to restrict that character, which can be done with a slightly modified version of your regex...

...but to have it as a friendly_alias_word_delimiters character so it gets replaced with the friendly_alias_word_delimiter, which is "-" by default.

Unfortunately, adding that character to that setting breaks the regex it is creating and returns an empty alias every time in current releases of MODX Revolution. This is a bug.

I have fixed this bug for 2.3 at https://github.com/modxcms/revolution/commit/ed2ac36764ed48ac6c5f9191e01428f89a0a8127 but you will not be able to do this in current releases of 2.2.x.

Thank you very much for such a thorough and concise reply. I will use your working regex to eliminate the "/" in the meantime, and later switch to the friendly_alias_word_delimiter solution, which as you suggest is the preferred approach, when available in 2.3. Many thanks for all your great work!