kongondo

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...

Is it a case of: Or...? If you are able to fetch (i.e. $my_array is NOT empty) but not display, then, as suggested, check the template file. If you cannot access (i.e. returns nothing), then check access controls, e.g. are the pages hidden? For instance, 'find' will not retrieve hidden pages although 'get' will...

@tpr, Thanks. They are all part of the admin themes that natively ship with PW. In the first couple of screenshots, that's AdminThemeReno, followed by AdminThemeDefault using the color set 'Futura' and last screen the color set 'Warm'.

I haven't seen any. You have at least two choices: 1. Create a Fieldtype module that you can attach to a page and use that to input your data. The page would mainly be a container for your input fields, although you would have to think about how to retrieve your stored data in which case the page ID might be handy. Behind the scenes, Fieldtype modules directly interact with the db - saving -> sleepValue() and retrieving -> wakeupValue(). This assumes that you will create a table only once for holding your data (when you create fields that use the Fieldtype) after which you will just be adding/modifying/removing db rows in THAT table. You would also be able to use raw MySQL if you wanted to. If you choose that, I highly recommend you use prepared statements for both security and future compatibility with ProcessWire. Have a look at the module matrix for ideas if you wish. 2. Create a ProcessModule with input fields to send/display your data. In this case you would have to use raw SQL to CRUD your data. Again use prepared statements and strict validation. Here too I assume you want to create only one table before hand (e.g. on install of the module - see changelog module for instance) and use that to store your data. There could be better ways of approaching this.....but I would create the tables once before-hand (on install of your module).

Update: version 0.0.5 Fixed markup errors reported above in MarkupMenuBuilder Merged version to master (updated in modules directory as well)

Thanks, fixed. Committing shortly...

Thanks, will fix soon. As for the <li>, it works fine for me...are you seeing that extra space (as in your code above...)?

Aaah, ye that's it. It works fine in dev branch. Please test and let me know? Thanks. I tested thoroughly with different combinations of multiple classes. I want to merge to master later today.

I'm all for clean and valid HTML too...What I meant is that I forgot to put back a space when I went from this <ul to this <$wTag.....bundling a third-party PHP class just to deal with that seems like an overkill

Hmm, interesting thought. Technically, it is not impossible - just a recursive function that only grabs one branch...I'll have think...

We'll that's strange...I thought I had dealt with this.....Old code must have crept in. I'll look into it, thanks for reporting. No need for the HTML builder ....for the <ul, it's just a missing space I forgot to put back after switching to configurable menu wrapper and for the <li> just a space to trim...I'll update tonight...

I have used this in the past: http://sewmyheadon.com/2009/mysql-search-replace-tool/ It might need updating though....

Naah, I don't see how it could be...

This is case where Martijn didn't have a use for forms ....Otherwise (see post #2 and #3), it would have worked with ....$form = $this->modules->get('InputfieldForm');

I feel you

Did the above (see #8 and 10) solve the mystery for you?

In addition to what I said in post #8 The line is this border: .Inputfields .InputfieldHeader, .Inputfields .InputfieldWrapper>.description { background: none; border: 1px solid #d7e2e6; border-bottom: none; color: #2F4248; } For the label <label class="InputfieldHeader InputfieldStateToggle" for="">Label One<i class="toggle-icon fa fa-angle-down" data-to="fa-angle-down fa-angle-right"></i></label> I am guessing the Wrappers were designed (CSS) with 'forms' in mind? So, if you render in a form, it works...

This is where it is coming from - the markup label: $markup->label = $this->_('Label ') . ' ' . $number; To test, comment that out (in your original code) and the white line disappears but the overlap is still present. So, nothing you can't solve using CSS I suppose Edit: See post #10 below for the CSS/HTML

Ye, that's strange...