Propsal: Add option to exclude pages from URL generation.

[Ulrich Petri]

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:

1. Add an "Exclude from URL" page attribute
   
2. Introduce a concept of "page types" (i.e. "Normal", "Container", etc.) this would have the benefit of also allowing for future expansion (e.g. adding a more robust redirection system by adding a "redirect" page type).
   

What do you guys think?

Bye

Ulrich

[Martin]

2 sounds cool to me...

+1

[Jonas Obrist]

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.

Jonas

[benzkji]

in general:
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.

regards
ben

[Ulrich Petri]

Hi,

On Jan 30, 6:57 pm, Jonas Obrist <ojiido...@gmail.com> wrote:
> Why not use the 'overwrite_url' field on page? Yes it is a bit annoying to
> do it per-page,

Exactly because it's a bloody pain in the neck and quite difficult to
teach to editors / "non technical content entering persons"

> but then again, what's so bad with having /meta/ in a URL?

3 words: Project Managers, Clients and SEO Zealots

> 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.

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
those :))

I will take a stab at creating a patch for this - maybe it will be
easier to discuss with some code to look at.

Bye
Ulrich

[Jonas Obrist]

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)?

[Ulrich Petri]

> Do we really make it easier for users if we add more functionality (or
> rather: duplicate functionality that is already there)?

The difference would be that this new functionality would not have to
be used / understood by "end-users".

[Kevin Renskers]

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?

[Jonas Obrist]

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.

[Kevin Renskers]

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.

[Ulrich Petri]

On Tuesday, February 1, 2011 9:45:04 PM UTC+1, Kevin Renskers wrote:

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.

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.

Maybe don't call it "show in footer" but "show in secondary menu" or something like that.

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.

Bye

Ulrich

[Kevin Renskers]

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.

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

 

Maybe don't call it "show in footer" but "show in secondary menu" or something like that.

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.

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.

[Ulrich Petri]

On Wednesday, February 2, 2011 9:48:20 AM UTC+1, Kevin Renskers wrote:

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.

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

Yeah, usually though this is for the bigger clients that have multiple divisions / operate in multiple countries etc.

 

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.

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.