Currently it’s not possible to omit the dimension segment from uri for the default preset.
That has following consequences:
Language segment appears on all urls, even if 99% website visitors use just one language. That looks weird and affects SEO.
What’s even worse, it becomes almost impossible to add more dimensions to already launched project, without breaking all urls. That would hold off people from using dimensions to its full potential.
Using logic and common sense I see these possible solutions:
A) Multiple dimensions can have empty default segment, but segments should be unique across dimensions
B) Only one dimension can have empty segment, but segments don’t have to be unique
C) A+B at the same time with magic. Error is only thrown if configuration has multiple empty segments AND non-unique segment names.
D) A+B at the same time with configuration switch. Default to B as it’s not breaking.
E) A+current behavior (no empty segment possible) with configuration switch. A bit simpler than D.
I vote against B) as it doesn’t solve problem 2. for more than one dimension.
Robert votes against A) as it’s breaking and there are projects like anita.com that require non-unique segments.
So it’s C vs D. I like D as it’s easier/cleaner to implement and not many people would need to change it.
Ok, to me it looks consistent. And most people don’t even see the full URL anymore these days (mobile, URL shorteners, …). As for the SEO argument - is there any reliable background information on that? Because more often than not, “SEO” is used as killer argument but as soon you ask about it, the story crumbles…
I find the arguing about SEO and seeing urls quite unnecessary as clients simply want this kind of urls as it seems. Dmitri is not the first and only requesting that. For code I think it makes sense to be strict(er) but for “customer” facing things I guess reason is not always good enough.
You can’t build customer facing systems driven by linear programming logic. We have requirements and we have to fulfill them, in the most elegant way possible, BUT within the requirements.
E.g. Robert’s clients have requirement against A. I think the requirement is silly, but we have to match it because Neos is development to solve their needs and not our coding amusement.
For me problem 2) is way more dangerous than problem 1).
I will not expand more on problem 1) as it will lead discussion aside and I’m not a SEO expert.
@dimaip Thanks a lot for taking care of this. Independently from the SEO and broken links arguments it’s a matter of fact that you often have the requirement for certain URL patterns so IMO there’s no way around a new configuration option.
Now with option E I expected a new Setting that can be changed from 3rd party packages. A routing option makes this a bit harder. But if we go for the latter it should be a placeholder that is set from the main Routes.yaml (similar to the defaultUriSuffix placeholder) so that this can be changed without having to copy routes.
Goal reached. That’s what I mean, this argument is brought up again and again, but without background–also on the clients side.
As far as the requirement goes, of course clients want things. And sometimes they are forced into certain things (as is the case with Roberts client, forced by Magento). I am fine with anything in this regard, as long as it works. Still didn’t have time to check your suggestions (sorry!), but I voiced my concerns, you discussed it and I trust you to make it work. Thanks!
Hey all! I want to bring this topic to life, as I think it’s really important to get this change into 2.1.
There are still tests to be written, I know. I will take care of it, if none of you want to help out.
There is one more thing that needs to be decided if we go with option E: where to put the configuration switch, that would enable new behavior.
There are two options:
a. As Basti suggested, add supportEmptySegmentForDimensions placeholder (similar to the defaultUriSuffix placeholder), so that this can be changed without having to copy routes.
b. Add this feature flag to Settings.yaml of Neos package.
I strongly advocate for option b) for the following reason:
If we go the Routes placeholder way it would become a breaking change: you’d have to add this placeholder to your site distribution.
This is not really a configuration option, but more of a feature flag. The only time where you would want to have the old behaviour, is when your project requires to have identical uri segments across dimensions, which is an extremely rare requirement. For all other cases, this change would not be breaking and would not require any additional configuration.
Anyone objects to having a feature flag for this in Settings.yaml?
Well, everything(?) related to routing is confured in Routes.yaml, so now having something in Settings.yaml seems strange. Also, I’d say this is a configuration option, not a feature switch.
And (again): I’d be careful with deciding if one way or the other is “extremely rare” I for one would like my URLs to be consistent in any case…
@kdambekalns: nobody stops you from having consistent urls with new behavior – just don’t set uri segment to be empty.
So your suggestion is to go placeholder approach that @bwaidelich described above? The main downside is that it would be a breaking change then.
I still think about it as of a feature switch. Do you know of many other projects than Anita.com that require non-unique dimension presets?
Anyways, I’d agree upon anything the team decides here, for me it’s not so critical if this feature would require updating global Routes.yaml (though I still think it’s wrong to implement it this way).
Not necessarily: If we check for the supportEmptySegmentForDimensions strictly (isset($this->options['supportEmptySegmentForDimensions']) && $this->options['supportEmptySegmentForDimensions'] === TRUE) it would be b/c as a missing value in the main Routes.yaml would lead to the option being evaluated to ‘<supportEmptySegmentForDimensions>’.
But I guess we’d have to tweak the ConfigurationManager a little so that it allows placeholders in RoutePart options, too
@dimaip: I wonder why you think it’s suboptimal? To me it’s really a routing issue as it’s only (and only) related to the building and resolving of url’s. And I don’t think it would really make a difference from the integrators point of view if he has to configure this in Routes.yaml or Settings.yaml. So actually I tend to think it’s the most elegant solution to put it in the routing configuration.
@radmiraal Hey I’ve listed my arguments above (main one is that it’s not really a configuration but more of a feature flag), but they didn’t find support in the eyes of the core team, so I’ll humbly put it into routing : )
That’s what I mean, this argument is brought up again and again, but without background–also on the clients side.
I for one would like my URLs to be consistent in any case…