Soma

You lost me somewhere in between. Keep it simple maybe with code example.

I don't think you can use the user pages to use access control for front end. User pages are special pages and I think not meant to be used as viewable pages on the front end anyway. Since you're speaking of front end users, you just get the users the members "can view" according to some "virtual" rules and use API to list their profiles using a dedicated page/template. I.e. /users/profile/xyz and use urlSegments to control the listing. On front end you're free to check for access and do what is needed to show or hide stuff. You member role would also be just a guest role with only view access since they won't need or have admin access. So it's up to you to control that in your templates. Just a dummy example. if($user->hasRole("member")) { $members = $users->find("roles=member"); .... } else { echo "Sorry, you're not allowed to view."; }

But they have hooks!

That means $pa = $pages->find("template=basic-page"); foreach($pa as $p){ $p->price_total = $p->amount * $p->price; } foreach($pa->find("sort=price_total") as $p){ echo "<p>$p->title $p->price_total</p>"; }

And what is wrong with your code, why must there be a better way? I just think you may not do it in template but after saving the page, it's also not kind of validation but a cleaning. So you wouldn't end with selectors being "false" saved to DB. ProcessWire hasn't some other way to do what you want/doing here, possibly also because of performance - it doesn't attempt to check for each selector if it's really valid/field exists. Technically there's also a way to add a runtime value to a pages that is used in selector on page arrays.

I'm not sure I understand. Does this mean you can enter a wrong selector and it still works?

Another option would be to browse this the page and copy the link, Or use the admin search and copy the link from the results.

Not the right thread but I hear you.

Just pushed some updates. Module is now v1.3.0 Form readme: Changes in 1.3.0 Changed module setting singular to false. This enables you load the module as a new instance with $nav = $modules->MarkupSimpleNavigation. This changes behavior for hooks attached to such an instance as it will only be called for this instance. This allows you to create multiple instances of the module to create different navigations with separate hooks. Added support for Page::listable. So you can exclude listing of pages in runtime by modifying this page permission. This can be done using a system hook on Page::listable and set the hook event to return false. Added new option date_format for created and modified native page properties. Added new option code_formatting, to enable or disable code formatting (indentation and newlines) of output markup. Added new option debug that will output rendertime and selector infos as commented inline html. Added support for Page::listable Usually you won't need this, but I needed it in a project so thought it wouldn't hurt. Usually you can hide pages from rendering in a list/navigation by setting the page to hidden in the admin. So this additional check in the module itself, allows you to make pages not listed on runtime. This can be used to check for logged in users that only should see the page listed when logged in. Example hook inside template just before calling render(): wire()->addHookAfter("Page::listable", null, "hookPageListable"); function hookPageListable($event){ $page = $event->object; if($page->template == "internal-page") { $event->return = false; // set listable to false if template "internal-page" } } Added new option debug If set to true this option will add an inline <!-- [MarkupSimpleNavigation Rendertime: 0.0171] --> after the markup output to show rendertime, and <!-- [Selector Level1: limit=3] --> on each item to see selector being used. This new version should still be compatible with older versions. But there could be instances where it could behave different when you have multiple navigations and using hooks. But chances are very small you run into this. If you have questions to the above just ask.

Kongondo is right. "parent_class" => "parent" is to set the class for parents of the current page. You don't have to do anything to make it work it just works, all parent list items will have a class="parent".

Just to make it complete with a working example (now at desktop): $treeMenu = $modules->get("MarkupSimpleNavigation"); $rootPage = $page; $options = array( 'current_class' => 'current-menu-item', 'has_children_class' => '', 'max_levels' => 2, 'outer_tpl' => '<ul class="dl-menu">||</ul>', 'inner_tpl' => '<ul class="dl-submenu">||</ul>', 'item_tpl' => '<a href="{url}">{title}</a>', 'item_current_tpl' => '<a href="{url}">{title}</a>', ); echo $treeMenu->render($options, null, $rootPage);

I completely see and agree, but I think i wasn't too clear with what the current behavior is wrong. There's no difference from redirecting from "/" to "/en/" than from "/en/" to "/". But currently I can't redirect from "/" to "/default/" as that would give me a endless re-redirect. I think it should be to the developer to decide whether he want the one or the other. (This of course would be when there's a "home" page name for default language defined.) Sorry if I completely missed the point

What diogo said. I have also, without going away, a lot of trouble keeping up with the pace. Times to change something.

You have the rootPage as second argument. Insert null as second, this is to overwrite current page active.

If you read the manual you'll find that the last argument you can specify the root parent page... that would be simply the current $page.

A good reference would be the HelloWorld.module that comes with PW in /site/modules/. Or here is some great summary write up by the great teppo http://www.flamingruby.com/blog/using-hooks-to-alter-default-behavior-of-processwire/ wire()->addHookProperty("Page::itemCode", null, "itemCodeHook"); When a hook is added in template code we use wire(), as this is the base class of PW that contains the hook methods. addHookProperty() adds a new property to the object specified with "Page", so "Page::itemCode" adds a itemCode to page objects. $page->itemCode would return the code returned by the hook. "null" is usually the context for the hook, but doesn't need one in template code. Last argument is the function name of the callback that is used for this hook.

Glad to have you back!

I just committed suic.. ehrm an update to ColorPicker. As of 2.0.0 you can enable output formatting of the field in the details settings. When enabled it will format value directly from AADDEE to "#AADDEE" and "transp" to "transparent".So you can now simply write: echo "background-color: " . $page->color; // outputs // background-color: #AEADEA added converting "0" settings to "000000", just in case This update should be save to update and backward compatible, but as always you should first test on a development server if you have a chance. In case something went wrong just ask here in the forums and I'm sure it will be solved within short time. Thanks

I see and kinda agree. But maybe rather add formatting to the field than change current 6 chars. Remember you could do that yourself with formatValue hook or property instead of local tpl logic.

I see. Hmm changing it to # would work in this case but break compatibility. So not positive to change it for something that is broken in PW. A string is a string not a number.

No. to be more clear it happens with all textfields in settings of fields or modules. Except title, names or labels. I enter for example 000 and get 0 after saving. Ok happens also for labels but only on alternative language. I have multilanguage installed, but otherwise I have no idea, nothing else I can think of. And it also happens to others as reported multiple times.