Path in editor not using slug

[bajesus]

The new editor seems to be working correctly, but when I add a link it is using the contenttype/id as the path instead of the slug. So when I add, for example, my contact page to the menu, instead of "page/contact" or "contact" it enters "page/3".

Bolt fixes it on the front end, so it still functions correctly, but using the id is a little confusing when editing the menu. Since the main point of having a "menu editor" is so less tech savvy users can make edits, having it show the actual address the link will go to seems important.

[bacbos]

I can see that this is somewhat confusing, but the id is the attribute that uniquely identifies a given page (contenttype), even when the slug changes later on.

We could think of parsing the id's to show the actual URI instead of the id of the resources - what do you think @SahAssar ?

I'm unsure though if that would always reflect the correct URL, given that the routing scheme doesn't necessarily have to follow the default of /contenttype/{slug}...

[SvanteRichter]

Well, the first issue with this would be that if an editor changes the slug the menuitem would be broken (but I assume both of you know that). The second would be that the contenttypeslug/slug combination often does not actually reflect the final url, since the routing can be (and often is) modified (as @bacbos said).

I'd love for it to have some sort of helper text that showed where the link will be routed to, but that would also need to fetch all the records in the menu, which could get pretty cumbersome on larger menus.

Perhaps adding a permission option on who can modify the paths would make sense, and for those that can't we can show a helper text that explains that the path is not the final url (beside the disabled path field)? If someone does not understand paths then they probably shouldn't be modifying them, right?

Another option is to actually fetch the proper links, but have an option to turn it off on sites that grow too large for it to be a viable option.

@bajesus, @bacbos any preferences among those or other ideas on how to handle it? I think the default should be to use the id, but I'm definitely open to other ways or having alternatives as an option.

[bajesus]

The previous version of the menu editor used the contenttype/slug combination which worked pretty well for me. The "Permalink" field in the page editor uses that format as well, I just put in a postfix note that says that the "/page/" portion of the value will be overwritten on the front end. My clients don't seem to have an issue with any of that and I can explain to them that it will be the same in the menu editor. Having to explain 3 different urls for the same page is a good deal more confusing.

Having the menu not update to match changes in the slugs is a minor annoyance but I think it is easier to explain to users that they need to edit the menu manually if they change a permalink than it is to explain why the path doesn't match the permalink they entered.

If it is a simple change maybe just add a "useslugpaths" flag to the config and let users decide if they want to use the contenttype/id or contenttype/slug paths.

[SvanteRichter]

@bajesus Well, I'd be okay with an option to force all menuitems to use the real links instead of paths, but putting them in the contenttype/slug format just gives us the worst of both worlds (non-elastic slugs and not reflecting the actual url) which is also why bolt/bolt#4767 is still open and will hopefully be fixed at some point. As I see it we should have two choices in the config:

use: links or something like that which actually puts the generated link into the link field of the menuitem

or

use: paths or something like that which puts the path into the menuitem and should probably be the default

Would you be okay with that?

[bajesus]

I think that would work great. I just assumed there was a reason for the bolt/bolt#4767 issue and that it might be a lot more work to just get the actual correct url than the contenttype/slug. If getting the correct route is possible that would be the best option.

[SvanteRichter]

Closing, if anyone is actively working on this let me know and we'll work on merging.