kongondo

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

Ah, I see (see also my edited posts above). Your yes/no is targeted at editors whereas my include_children with its options is targeted at developers. Giving editors the choice makes more sense and I'll adapt that instead. So, just to make sure we are on the same page: Editors control inclusion of natural children (default is exclude - this setting is not saved) Editors control whether natural children are shown in menu or breadcrumbs or both (This can a set of 3 radio buttons - any selection also implies include children; no selection implies don't include - or I could add a fourth button but it's already crowded in that menu setting as it is!! if one wants to edit the setting. No, better yet, I'll use a drop-down with 3 options - 'menu', 'breadcrumbs', 'both'. No selection = default and means 'don't include natural children') Editors control this per menu item (i.e. per PW page) What do you think about my levels question though? Sticking to immediate children is pretty straightforward. Do you see a need for grand-children? This is more relevant for breadcrumbs, e.g. if you wanted Home / Cars / Jaguar / Model X where both 'Jaguar' and 'Model X' were not part of a MB menu...

I think your 'another thought' is a better approach since it allows for more granularity, i.e. it targets individual menu items rather than the first approach which targets the whole menu in terms of including natural child pages. I don't think there is a need for the second option 'yes/no' though unless am not getting it? By using the 'include natural children' option, you imply that you want them to be displayed. The way I think I'll do it: 'include_children' => 0//default = no 'include_children' => 1//yes, but only in menu, i.e. render() 'include_children' => 2//yes, but only in breadcrumbs, i.e. renderBreadcrumbs() 'include_children' => 3//yes, in both //number of child nesting levels to show IF include_children > 0 //include_children_levels => 1//default, i.e. show only immediate children [or child in case of breadcrumbs] //include_children_levels => 2//etc....show up to grandchildren/grandchild, etc.. The include_children can be tricky though....One might end-up with lots of sub-menus! But this is is optional, so up to the developer really. Apart from some coding issues I may not have thought of yet, the visual MB aspect has to be considered. Those natural child pages will not be included in the saved menu items, hence will not be displayed in the menu tree in the back-end (ProcessMenuBuilder). They will only be included in the front-end output during runtime. That may confuse your editors, but nothing you can't educate them about, and this is optional anyway. Edit: Or...in the spirit of flexibility and granularity....in MB admin, also add an include_children_levels text (int) box next to an include_children checkbox. Then in the front-end, render() and renderBreadcrumbs() will be guided by: if the setting include_children_levels is empty AND you have an $options = array ('include_children' => xx, 'include_children_levels' => zz), the level set in $options takes precedence and is applied overall except for menu items where the setting include_children_levels is NOT empty; an explicit level set at menu item level will override any $options setting. Would such a workflow work for you?

@dazzyweb, OK, I might have found a way to achieve both of these. Although I think it is possible to include intermediate natural parents (i.e. PW parentage) that are also not in the breadcrumbs, I think I will stick to immediate parent only. Same goes for the 'current' class. What I mean is this....let's say your 'jaguar's had child pages as well, maybe 'model A', 'model B', etc., that are also NOT part of the MB menu, following your request, you would something like this: Home / cars / Jaguar / Model A. The problem I foresee is what if an intermediate parent was part of the MB menu but not in a 'natural' position? I we were to include it in the breadcrumbs, it could end up in the wrong position (from the breadcrumbs point of view). I hope this makes sense and maybe this is an edge case. Anyway, unless convinced otherwise, I am limiting this to the immediate parent, e.g. Home / cars / Jaguar /. Thoughts? Edit: No, scratch that. I'll make the depth to which one wants to display non MB items that are natural children of the current MB item configurable, e.g. append_child => 0//default - no child appended = Home / Cars append_child => 1// append the immediate child = Home / Cars / Jaguar append_child => 2// append immediate child and grandchild etc... Beyond that...how you structure your menus is up to you

You don't add the HTML manually...that is automatically done for you. In a hurry, but have a look at how it is done in various modules, e.g. Batcher and Menu Builder, or in PW pages, e.g. /wire/modules/Process/ProcessPageEdit/ProcessPageEdit.module The key is to include; $this->modules->get('JqueryWireTabs') in your module, most likely in your init() method and create tabs like shown in Batcher/Menu Builder. You also need to add some short js in your module.js file...Again, see the above modules...Sorry, you will get other answers if this is not clear....

Hey, he liveth!

Update: version 0.0.6 In dev branch for now As per this idea, thanks @dazzyweb, added a renderBreadcrumbs() method to render, uh..., breadcrumbs. See documentation in Read Me for how to use For both render() and renderBreadcrumbs(), you can also pass a Page object as the first parameter. This is in addition to the already available ways, i.e. you can also pass a menu page's title, name or id or an array of menu items built from a menu page's menu_items field. Please test and let me know, especially playing around with the options you can pass renderBreadcrumbs(). See Read Me, including comments in the code. These options can be shared between the above two methods. Same goes for the first parameters - e.g. get a menu page and pass that once to both render() and renderBreadcrumbs(). Also added the option to prepend 'Homepage' as topmost breadcrumb item even when it is not ancestrally part of the breadcrumb. Note If you call renderBreadcrumbs() in a page that is not part of the menu items you will get an error if logged in as superadmin but nothing returned for all other users. E.g., say you have the following menu items: Home About Us Products Services Contact Us renderBreadcrumbs() would only work (duh!) if called from the template file of AND viewing one of those pages. This is because the method works by first matching the 'pages_id' of a menu item with the $page->id (current page) and builds the breadcrumb from that. External menu items can be part of the breadcrumb as long as they are not the current item (of course) - which they can never be anyway since clicking on them will load external URLs

/wire/core/Database.php This is pretty high level stuff that you won't find in the (current) API documentation which (the documentation) is aimed at everyday PW use rather than module dev.... The class Database is available everywhere...