|Propsal: Add option to exclude pages from URL generation.||Ulrich Petri||1/30/11 6:36 AM|
Currently all the slugs of a specific page's ancestors are used to generate the URL / path to that page (except when using CMS_FLAT_URLS of course).
This is undesirable in a number of cases the most common IMHO being "meta" and "footer" menus where the URLs to all pages below those "container" pages will contain something like "/meta/" or similar.
There are (at least) two possible solutions:
What do you guys think?
|Re: Propsal: Add option to exclude pages from URL generation.||Martin||1/30/11 6:42 AM|
2 sounds cool to me...
|Re: Propsal: Add option to exclude pages from URL generation.||Jonas Obrist||1/30/11 9:57 AM|
Why not use the 'overwrite_url' field on page? Yes it is a bit annoying to do it per-page, but then again, what's so bad with having /meta/ in a URL?
I'm strongly voting -1 on this, since it makes the already very complex menu code a lot more complex for very little gain and for something that can already be achieved.
|Re: Propsal: Add option to exclude pages from URL generation.||benzkji||1/30/11 11:43 PM|
the so called "speaking urls": /footer/contact/ should really be /contact/ to "speak" for itself - easier to read, easier to remember and f. e. used to send in an e-mail. From a technical point of view, I fully agree with Jonas ;)
+1 for the page types:
- the redirect page type would be very welcome, simplify things
- don't know if the system should automatically decide "it's excluded from the url if it's a container" - this could not shine through to the user. so maybe -1 for the "page type with auto-exclude form url".
+1 for "exclude":
- you check "exclude", your users don't have to enter the "overwrite_url" field for all subpages
- I would almost vote for "drop CMS_FLAT_URLS" - with the "exclude" field, one could achieve the same with more flexibility ?
- this is a common practice I've seen in use many times
BUT: for me, the problem seems not urgent, django-cms can handle all cases as it is right now. So I really understand the -1.
|Re: Propsal: Add option to exclude pages from URL generation.||Ulrich Petri||1/31/11 7:12 AM|
Exactly because it's a bloody pain in the neck and quite difficult to
teach to editors / "non technical content entering persons"
3 words: Project Managers, Clients and SEO Zealots
I can appreciate this view from a programmers perspective but the fact
remains that at the moment django-cms is harder to use for "average"
people than some other CMSs out there - and this leads to questions
why such a CMS is being used (and I'd rather not have to answer
I will take a stab at creating a patch for this - maybe it will be
easier to discuss with some code to look at.
|Re: Propsal: Add option to exclude pages from URL generation.||Jonas Obrist||1/31/11 7:30 AM|
Well another question one might ask:
Do we really make it easier for users if we add more functionality (or rather: duplicate functionality that is already there)?
|Re: Propsal: Add option to exclude pages from URL generation.||Ulrich Petri||1/31/11 7:36 AM|
The difference would be that this new functionality would not have to
be used / understood by "end-users".
|Re: Propsal: Add option to exclude pages from URL generation.||Kevin Renskers||2/1/11 12:39 PM|
As a user of Django-CMS I'd really like a redirect type of page too. A container on the other hand seems too difficult to explain to my clients.
However, Mezzanine has a nice option: besides a "show in menu" flag, they also have a "show in footer" flag. This would be welcome, seems easy to do, and could solve Ulrich's problem?
|Re: Propsal: Add option to exclude pages from URL generation.||Jonas Obrist||2/1/11 12:41 PM|
I don't like the 'show in footer' flag since it's too restrictive. Because if we do that, people will also want a "show in header" flag, and at the end of the day we'll have a dozen flags. So a more general solution would be favorable in my opinion.
|Re: Propsal: Add option to exclude pages from URL generation.||Kevin Renskers||2/1/11 12:45 PM|
On the one hand, I do agree with you. Once you have the one flag.... you know the rest :)
On the other hand, with one extra flag you can already show 2 different menu's. In my life I've made probably over 100 sites. I can't for the life of me think of one where this is not enough.
Maybe don't call it "show in footer" but "show in secondary menu" or something like that.
My 2 cents.
|Re: Propsal: Add option to exclude pages from URL generation.||Ulrich Petri||2/1/11 3:56 PM|
Sorry to rain on your parade ;)
About 40 - 50% of the sites I've built (and have been built at my
place of work by other people) have 3 or more menus.
I think that a flag like this is entirely to "magical". What exactly
constitutes a "secondary" (or tertiary) menu? With some kind of
"exclude from URL" functionality combined with the existing
show_menu_below_id tag OTOH you can have as many or few "navigation
namespaces" as needed.
|Re: Propsal: Add option to exclude pages from URL generation.||Kevin Renskers||2/2/11 12:48 AM|
Really? Three separate menu's, not just primary menu at the top, its submenu at the side and something in the footer? Well, lucky me with my easy clients then :D
Well, not really. What if I have a Contact page that I want to show both in the primary menu and the footer? With the current functionality it's not possible. With a new "exclude from URL" option you could create a "container page" for the footer, but how will the page show up in the primary menu? It's now a submenu after all. This will get really complicated for clients, as there is no 1-on-1 mapping from tree in backend to menu's on site.
|Re: Propsal: Add option to exclude pages from URL generation.||Ulrich Petri||2/3/11 6:53 AM|
Yeah, usually though this is for the bigger clients that have multiple divisions / operate in multiple countries etc.
What I usually do in cases like this (in other CMSs) is to add a "dummy" page to the sub-tree where the additional link should appear and make it a redirection to the "original" page.