allow the user to show or hide folder pages in the menu

[fritzmg]

Imho it's better to let the user decide whether a folder page should be shown in the menu or not. See also #8 (comment)

However this way the user can 'accidentally' show an URL for a folder page in the front end, if the used navigation template is not based on the nav_default template of this commit.

I could add a generateFrontendUrl hook that simply creates \Contao\Environment::get('url') (i.e. scheme and host) for example. I am not sure that's worth it though.

[fritzmg]

@aschempp @Toflar any objections to this?

[Toflar]

I don't see why a folder page should ever be shown in the navigation. It's purpose is to explicitly not do that. /cc @qzminski

[fritzmg]

The purpose would be to create navigation items that aren't pages themselves, e.g. parents for dropdowns, without having to resort to doing that with CSS classes for example. The original m17folderpage extension followed the same logic.

[aschempp]

You should use the forward page for that. It offers exactly the same functionality as the folderpage, but you can define the target if the navigation (accidentally) is a link.

[qzminski]

Although it is not a part of the initial concept I think it does not harm to have it. However this pull request is a BC break I fear, so it should be improved.

@aschempp that does not help because some forward pages may be used as a non-link whereas some as regular link. Folder page type would explicitly always work as a non-link.

[fritzmg]

@aschempp no, because then you cannot have menu items that are an actual redirect, if you change your template for internal redirects to be <span> instead of <a>.

// @qzminski exactly :)

[fritzmg]

@qzminski it could be released as 3.0.0, unless you have specific plans for 2.x

But why do you think it's a BC break anyway? This would only affect newly created folder pages, not existing ones.

[aschempp]

@qzminski it would probably work because hide is already set on all existing pages (or at least it should be).

[aschempp]

However, we must not override the nav_default template. Can you rename that to nav_folderpage or thelike?

[fritzmg]

Sure. Also I think I should add the cssID field.

[qzminski]

@aschempp doesn't hide=1 mean that the page will not be shown in the navigation? If we take it down it in this PR, then suddenly all websites using this extension will get an extra navigation point.

[fritzmg]

@aschempp doesn't hide=1 mean that the page will not be shown in the navigation? If we take it down it in this PR, then suddenly all websites using this extension will get an extra navigation point.

No they won't because only the default value changes. This does not affect existing folder pages in your database.

[qzminski]

Ah sorry I didn't notice that it is done when the page is being updated 🙈 All good then!

[aschempp]

ping @fritzmg

[fritzmg]

Done. I have made the following changes:

• 959afe5: added the cssClass field to the palette, since the folder page could now be visible in the main menu and thus you might want to assign a CSS class for that menu item.
• 0c53aeb: if you create a regular page, save it with an alias and then change it to a folder page, the alias will remain. The existing save_callback will not fix this, since this callback is only executed if the field actually exists in the palette. May be this callback can be removed in general?
• 5ac5961: renamed the nav_default template to nav_folderpage.

[fritzmg]

Any further comments?

[qzminski]

RTM to me. @terminal42/pilots ?

[Toflar]

No idea, that's not my baby. Feel free if it's okay to you :D

[qzminski]

@aschempp your call then.