Content manager: custom url not really customizable

[antibart]

Hi,

This is a continuation of my topic on LISE and the custom URL feature. The problem I have is similar to that.
viewtopic.php?t=84696

I'm struggling a little bit with the meanig of "custom".

Summary: For a migration from another system to CMSMS, I need to preserve all URLs to avoid jeopardizing the website's good ranking. Problem: the old url structure is a little bit unusual. Not invalid, just unusual.

The custom URL feature would be perfect for this. But it seems that the content manager wants to impose its own idea of ​​a custom URL.


URLs are case sensitive. domain.com/SITE.html is different from domain.com/site.html. The content manager overwrites uppercase characters with lowercase characters automatically. This is a problem for SEO if you want to keep established URLs consistent. Even if lowercase is of course more elegant.

So my question is: If there's a special feature to create a custom, non-automated URL, why does it let me do just that?


----

[antibart]

Note: When I am talking about "custom url feature", I mean the "Page Url" field under the navigation tab that allows to specify an alternatve URL instead of using the page alias.

[karpel]

“@antibart Totally get your frustration. I’ve run into the same thing where CMSMS forces lowercase in the Page URL field. As far as I know, it’s baked into how CMSMS sanitizes URLs for consistency. Maybe a core dev or someone with a custom module workaround can chime in, but I don’t think there’s an easy toggle for preserving uppercase. It’s annoying if you’re trying to maintain legacy URLs.”

[tomphantoo]

Yes, a supplied URL will be sanitised and validated, the former including lower-case conversion.

However such URL is intended to represent a 'pretty-url' for the page and is only useful when such URLs are enabled. (Check the popup help for the url field when editing a page.)

There's no support for an arbitrary actual-full-URL which can be used to access a site-page.

Which is not to imply that such support could not be implemented at some stage. You might like to lodge a Forge feature-request or GitHub issue-report.

[antibart]

Which is not to imply that such support could not be implemented at some stage.

In my opinion, the URL field should provide exactly this support.

For common URL structures, the page alias method is perfectly adequate. by the way:, the alias field supports uppercase letters.

This makes it all the more difficult to understand why a field for a alternative URL doesn't.

I submitted a feature request.