marcus

Generally: hidden prevents pages from being listed in menus, foreach loops and searches, but if you now the path to the page, you will be able to call it, even when being guest (meaning: not having permission to see unpublished pages). Unpublished means hidden in lists (like mentioned above) AND, for users that do not have the permission to see unpublished pages, inaccessible even via its path/URL. I assume you have that page reference construct built in the backend. There, unless actively changed, you are superuser. "Hidden" pages will appear in such a reference field, "unpublished" ones won't.

I think this will work $nav_sides = $pages->get('/')->nav_side; if ($nav_sides->has($page)) { //... }

Can you send me a screenshot of this? I chose Adobe's Source Sans Pro as main font and I expected it to be well crafted enough to render on Windows adequatly. But I'll check the @font-face implementation of the theme CSS. Edit: Tried in your setup in a virtual machine, that's the result:

Added target=_blank on the form some moments ago. Apertus will be visible in the Modules Directory shortly

I think, "companies" are in this case web agencies. And they tend to lean towards everything Mac and are the ones to convince. I'll try to namedrop and showcase ProcessWire from time to time when I'm working for my web agency customer

You can always simulate the production site domain situation, so you won't have to do fixes (Rewrite Base, etc.) for localhost/ProcessWire/project when you live domain is just yourwebsite.com. You can take that even further and simulate server capabilities, for example Apache module versions and so on with Vagrant

The readme doesn't state explicitly 2.4.0, so it's still valid since dev is currently 2.4.11. It's actually quite good that a not-for-production version of a software is relatively hard to find... But maybe it would be nice to have a short URL like http://dev.grab.pw directly pointing at the ZIP of the dev branch

The first way may be shorter, but it isn't correct if you want to redirect to the page that has the path /profile/. In this case, the redirect() method does not expect a "ProcessWire Page Path", but simply does what you ask it to do, redirecting to [root]/profile. As if you would create a link: <a href="/profile/">Foo</a>

Thanks for contributing! I totally forgot about these labels. Will add target=_blank on forum search as soon as I find the time to work on Apertus this week

Yes, as best practice interface examples. For Drupal, the menu module is a necessity, since all content is in a flat "pool". I guess the same thing goes for Joomla. Overall, my idea is nothing else that a wrapper for a fully native solution, a container for the "virtual tree" approach. But instead of having this subtree in the area editors can access, it's "hidden" sub-"Admin", to keep the tree clean(er). This is not a one-size-fits-all solution or proposition, just an extract of sone my experiences with customers

My, and a guess kongondos intention as well, of such a module would not be to replace or deny PW page tree approach (or even tricking someone), but providing an additional option to create a menu. Sometimes menus are needed which contain a wild bunch of references across the site, as well as some external links. The "virtual tree" approach is possible, but another interface solution would be better in some cases. That's just what motivated me to describe this approach (and I guess that motivated kongondo to write such a module in the first place, a year ago )

Ah, snap Haven't found it in the modules pool or by searching "menu editor" in the forums... "Builder", of course. Thanks for the kind words!

Update: Such a module already exists: kongondo's Module Menu Builder When you look at other CMS such as Wordpress or Drupal, no matter what you think of them, they share a feature that would suit ProcessWire very well: The seperation of menus and content structure via backend. While this is kind of possible programmatically, in the template via MarkupSimpleNavigation, both Drupal and Wordpress have their take on a “Menu Creator” in their backends, where editors could compose their menus, consisting of references to pages or external links: While not part of these screenshots, both visual editors provide the option to nest menu items. As you maybe have noticed, I’m kind of experimenting with modules right now And I’m eager to learn more about module creation and the inner architecture of PW. But: the longer I thought about this “Visual Menu Module” idea the more I noticed it’s still far ahead of my abilities. In the following I’ll write down how I would approach such a module. It would be really helpful for my understanding of modules and programming itself if you can give me feedback… concerning if such a module worthwhile - or I’m misjudging the demand if it’s possible the way it is described if there are some quirks or factors I haven’t thought of Thanks in advance! And here we go: The module itself would establish a process, let’s call it ProcessCustomMenus. During module installation, the plugin would create a subpage of “Setup” within the admin branch of ProcessWire backend main navigation, “Custom Menus”. Navigating on “Custom Menus”, there would be a possibility to list, create and edit the custom menus. Technically, all custom menus would be child pages of said new “Custom Menus” page. Then, three new templates would be necessary: customMenu, customMenu_pageReference and customMenu_externalReference. customMenu is used for direct children of “Custom Menu”, while the other to templates will serve as items on a particular menu. Phew, hard to describe. Here’s a screenshot: For starters, customMenu_pageReference and customMenu_externalReference could have only two fields each: title and pageArray (for internal references), or title and text (for external references). Later one could try to save the menu item nesting state in an additional field. On the template side, a named custom menu could be output as easy as: $modules->get(“MarkupCustomMenus”)->renderCustomMenu(“named_menu”, $options) …where $options could be an array full of further markup config. Of course, the content of “Custom Menus” in backend should be as easy as in the Drupal and Wordpress examples above, and appareled with all the interface magic jQuery UI has to offer, and also maybe ASM select (though I’m not sure how to achieve nesting with ASM) or other ProcessWire backend concepts. So, what do you think?