kongondo

Nope...works with new topics as well. See my test here: https://processwire.com/talk/forum/11-pub/ https://processwire.com/talk/topic/9632-testing-forum-prefixes/ Edit Deleted test

Maybe...tried with Blog and now it works...

I've tried this before as well, and it didn't work...gave up quickly ...

Thx for this Kixe.Looks like a tutorial to me. Shall I move it there?

Quick heads-up I have been forgetting to mention. This discussion reminded me about it. There are cases where you need 'dummy links', 'divider menu items', 'non-clickable menu items', etc, You can easily achieve that by creating 'External Menu items' and assigning # as the URL.

You are right...would certainly make life easier....Just Create a 'dummy link' and bob's your uncle.... ...I could then focus on other pending modules

Currently this is possibly only with Custom Menu Item (external links) where you can provide # as a URL. At the moment, PW pages' URLs are non-editable but I can easily provide an option to make them editable if such a feature was requested (preferably via Github)..

Ryan has fixed above issue in this commit.

Is this what you are looking for? https://processwire.com/api/selectors/inputfield-dependencies/

Thanks Ipa, A recent commit to ProcessModule.module in PW dev branch is the cause. Otherwise Blog works fine with versions up to 2.5.24. I have notified Ryan. Basically what is happening is that after that commit, Blog's configuration data is not properly saved to the database so it thinks Blog is already fully installed and it tries to load the dashboard (bypassing the install process). The error about the date is that it is trying to load the archives dashboard, sorting posts by 'blog_date', which of course, at that point does not exist as install did not run...

There's a slight bug in the application of the current_class_level across non-native (included children) items, their natural parents and the Menu Builder parents of those natural parents. Filed an issue to remind me. To illustrate: Home About (not PW-naturally related to included children) Natural Parent Included Child 1 Included Grand Child 1 If we set 'current_class_level' to 4, it should be applied up to and including 'About'. Currently, it stops at 'Natural Parent' but it should include this item's Menu Builder parent, i.e. 'About'. A level of 5 should go all the way to 'Home' but it doesn't atm.

Update: version 0.0.8 Added an 'include_children' feature, thanks to ideas by @dazzyweb. Added sister options 'm_max_level' and 'b_max_level' that control how deep to fetch descendants if using 'include_children'. Default is 1 (i.e. only include immediate children); 2 means go up to grandchildren, etc. As part of ideas above, also added a 'current_class_level' that lets you specify how high up the ancestral tree to apply a 'current_class'. This is like an 'active parents' setting. The default setting is 1. A value of 2 means apply class to current item and its parent; 3 means apply to the item, its parent and grandparent, etc. Only applies to menus (not breadcrumbs). Added a permission 'menu-builder-include-children' in relation to above 'include_children' feature (this permission is required to set and use the feature). This is currently in the dev branch only. Please thoroughly read the updated docs about these new features (especially the first) before attempting to use them. Although covered in the docs, I would like to repeat this here: Use the 'include_children' feature with caution. You can end up unwittingly including hundreds of child pages in your menu! Currently there are no code-checks in place to prevent such a situation (difficult to impose an arbitrary figure) so we leave this to your better judgement. Also note that the setting cannot be applied to a menu item made up of your 'homepage'. If you enable the 'include_children' feature (it is off by default), your main settings, PageAutocomplete/AsmSelect and menu item advanced settings will change from this: to this: and your menu output to something like this...(from only two items in the visual Menu Builder) Please test and let me know if there are any issues. Thanks.

Nothing in particular....just WireTabs and yes, Fieldset tabs, ta...

Hi en4ce, Welcome to PW and the forums. Pro Cache has its own private support forum for users like yourself. Once you've bought the product, Ryan would activate your membership to that forum. I'll remind him to do that (being a holiday he's probably away, hence the delay) but feel free to send him an email as well

$mr = wire('user')->user_mr; return $pages->find("has_parent=$mr"); Your code works for me as is...maybe you have a typo somewhere?

Thx for this Adrian. Would it be able to work with custom tabs?

Similar here, for info https://processwire.com/talk/topic/6196-easy-search-on-pw-forums-with-google/ My favourite though: https://cse.google.com/cse/publicurl?cx=014789015761400632609:fxrf0rj4wr4

I can assure you that the recent updates have nothing to do with security ....they are all to do with improvements to performance, added functionality and bug fixing. Some people prefer to use the dev branch of ProcessWire whilst others even stick to older versions

What Soma said... Probably a dynamic IP issue....(I would have thought at work you have static IPs?) https://processwire.com/talk/topic/1621-sudden-death/ https://processwire.com/talk/topic/979-logging-in-creates-a-new-session-good-or-bad/ https://processwire.com/talk/topic/1687-session-login-problem-on-appfog/ https://processwire.com/talk/topic/5383-being-kick-from-backend-within-a-few-seconds-of-idling/

Nice one. I use this http://www.generatedata.com/. Installed locally, totally free, no row limit (check the About tab to download the script)

@arvixeuser You need to go here: ProcessWire Support Forums → My control panel → Settings → Display Name Welcome to the forums

Double wow! @Helder, welcome to the forums

Update: version 0.0.7 Merged changes from last version in dev to master MenuBuilder now fully speaks your language, thanks to this post by @bbeer. Added multilingual capabilities and options to both the process and markup modules. In relation to above, added option 'default_title' to MarkupMenuBuilder. This option allows you to control whether to display MB saved menu item titles/labels in your navigation versus the actual/current titles of the pages listed in the navigation. The default => 0 means display the saved values (e.g. useful when you've altered the labels/titles). However, in some cases, e.g. in multilingual environments, you may want your navigation labels to change depending on the chosen/user language. In such a case, users will be presented with labels that match their language (assuming of course your pages have titles for different languages). To use the option specify 'default_title' => 1. Works for both menus and breadcrumbs Any issues, please let me know, thanks. IMPORTANT I forgot to add that currently, for multilingual sites, you can only pass an array | id | page to render() and renderBreadcrumbs() but NOT a not a menu page name | title (will throw an error for superusers and display nothing for all others). This is because there is no way MarkupMenuBuilder can know whether the string you are passing to it is the name of the menu page in English, Dutch or Arabic, etc. It cannot fall back on the current user language as well since the front-end of your site can be surfed in several languages. Neither can it fall back on the default language since a menu could have been created in a different language from the default. Hence, the only foolproof way to get and render menus in such environments is by array of menu items or menu id or menu page. Unless somebody shows me a workaround, its going to stay this way. I hope this is not too much of an inconvenience to ML devs

@bbeer, No, it's not multi-lingual in that sense. The reason you see an array is because the various titles (in the different languages you have installed) are held in an array. When saving, since I have not implemented ML support, PW does not know what to save. That is what I am assuming. I have never worked in a ML site before so this is new to me too. I am looking into it. I'll ask in the forums (Soma probably will pick it up ). So far my searches have come empty, i.e. how to save a field (in this case a page title) in a ML environment. Hopefully I'll find an answer here: https://processwire.com/api/multi-language-support/multi-language-fields/

OK, we should have these separate...I need to reiterate that MB will not control the number of such children to show at any level.....although I want to leave that to the developer (or editor?), I may need to limit maximum number of pages returned in that 'find'. I imagine a situation where an editor working on some other part of the site inadvertently adds tens of child pages (e.g. under CARs and under Jaguar, etc...)...Coupled with a levels of say 3, you suddenly end up with 3 x XX number of pages to find for one or more menu items! Can easily chock memory...Not sure how to implement this at the moment...maybe make it configurable at developer (template file) level...something like max_children at each level... Exactly...would save you a few clicks... Edit: Below is how I envisage the order of priority of $options (API/template file) setting vs. admin-level settings. There's 4 possible admin-level settings for each menu item in respect of whether to show its natural children. Show in: (1) Menu (2) Breadcrumbs (3) Both (4) Never. In addition there's the number of levels to show in respects of choices 1-3. Desc order of priority for final display $options = array('include_children' => 0)//overrides everything set at admin level. No natural children displayed anywhere Any explicit admin-level setting: 1- 4//Natural children displayed/not displayed as per choices 1-4 FOR ONLY THIS menu item irrespective of what is set in $options (apart from a '0' setting as shown in point #1 above) $options = array('include_children' => 1|2|3)//overrides ONLY EMPTY admin-level settings: Show natural children of all items without an admin-level setting ONLY in menu [1] (render()) OR breadcrumb (renderBreadcrumbs()) [2] OR both [3] Empty admin-level setting: no natural children displayed anywhere