kongondo

Uh? Isn't the overlap the intended behaviour (just like the tabs in 'page edit mode') or I am not getting you? But I still don't understand why it is not working without use of a form. Btw, in my testing, your code does not even render as tabs - maybe am missing something in the JS...

Only seen that where the tabs are not added to a form instead...So don't know if it is because you are adding a wrapper to a wrapper?

Update: version 0.0.4 Added 7 permissions to control visibility/access to advanced settings by non-superusers as discussed above. Currently this is only available for testing in Menu Builder dev branch. Note that you have to create the permissions yourself and add them to a role. Please thoroughly read the updated README about how to use these permissions; depending on your situation, you may not have to create any of the permissions. In summary, these control: Locking/unlocking menus (menu-builder-lock) Trashing and deleting menus (menu-builder-delete) Use of selectors to add pages as menu items (menu-builder-selector) Use of markup/HTML in menu item titles/labels (menu-builder-markup) Specifying of PW pages that are selectable as menu items in the page fields AsmSelect and PageAutocomplete (menu-builder-selectable) Editing of nestedSortable settings, e.g. maxLevels (menu-builder-settings) Ability to change the page field (AsmSelect vs PageAutocomplete) to be used when selecting PW pages to add as menu items (menu-builder-page-field) Please test and let me know, thanks.

Of course, how silly of me not to ask first ...Thanks Wanze

By posts I'll assume you mean pages....What you want is to count the number of pages created by the specified author, hence you want to use created_users_id in your selector. Below author can be an object or an ID $cnt = $pages->find("template=foo, created_users_id=$author"); //find by current user $cnt = $pages->find("created_users_id=$user");//you can also get the user first... https://processwire.com/talk/topic/6423-all-items-from-member-on-member-page/ https://processwire.com/talk/topic/7403-module-blog/?p=85780

OK...on my TODO. I have expanded it to other features, not just the selectors. See this also. What are your thoughts about controlling ability to delete menus too? Any other controls I am missing? Thanks.

Not on this board, no

Until last week Hooks were mostly a mystery to me too...until I did this and this and got this

The argument names are the method arguments/parameters ..So, in your method foo(), there are two arguments...bar and baz....with 0 and 1 indices respectively..So, you can get with either e.g. event->arguments(0) is the same as event->arguments('bar') but the numeric index is faster (although less readable)... http://processwire.com/api/hooks/#read_arguments

Been planning to automate the process....either within or outside PW...e.g: https://github.com/apigen/apigen https://github.com/ApiGen/ApiGen/wiki/Generate-API-to-Github-pages-via-Travis

@Teppo, about ApiGen... I for one totally love it....but not the ProcessWire hosted one. I have rolled out my own locally hosted one, which I update regularly with the latest PW dev. It has been especially invaluable to me as a module developer and also as someone curious to find out how PW works and also just for learning to use PEAR . I can quickly and systematically go through PW cross-referenced code, reading Ryan's comments, finding out what extends what, inherited properties/methods, class properties and methods, etc. I have set it up to document not only .php files but also .module ones - so, the whole package. GitHub doesn't even come close IMHO - unless am missing something?. As stated previously elsewhere, my greatest influence as a developer has been through studying existing modules, notably by Ryan, Soma, Wanze, Pete, Antti and yours, and more recently others including Adrian. ApiGen has helped me 'decipher' Ryan's and Soma's advanced use of PW methods - quickly and efficiently (but I also use Grep a lot if I am looking for something specific). But I agree - this is something I would only recommend for advanced developers and has to be used with the full knowledge about 'Public vs Private API' as stated in the link to Ryan's comments... This has been written in a hurry so there could be mistakes

From previous experience (and have also just now quickly tested), as long as the subfield is a db column name, it should work...so.. $items = $pages->find("sort=parent.title, limit=50"); will not work...you will get an error about column not found...but... $items = $pages->find("sort=parent.name, limit=50"); will work...

Link?

Selector not appearing is by design (seems I added that to the ReaMe only and not the OP). Currently, it is only visible to superusers although was wondering whether to make that permission-based as well...could be user created permission that would be stored together with the menu's settings...

Yes, looks like a memory issue, but hard to tell what exactly is happening without seeing some code...

Just adding this for completeness in relation to my post above...I went ahead and finished the Menu Builder module.

Aah...how could I miss that , thanks. As for prepared statements, here's a couple of posts. https://processwire.com/talk/topic/3515-processwire-24-compatibility-for-modules/ https://processwire.com/talk/topic/5842-pointers-for-using-pdo/ https://processwire.com/talk/topic/4691-can-i-use-my-own-database-table-in-processwire/ You can also grep 'prepare' in core files to see how Ryan does it. You can also have a look in my Matrix module.

Hi, Thanks for this... Do you have the project somewhere on Github? Just an observation: In your $db query, Although you are properly escaping and sanitizing values, maybe you should consider using prepared statements too?

Sorry for the delay. #1: Am not sure how to do that. It is really a Comments Module question. Maybe Ryan could help there #2: Yes Seem you really have some cool setup there. Would like to see a screen if possible. Cheers, /k

I don't know if you can do 'name' only but you can hide the settings tab as discussed here: https://processwire.com/talk/topic/8724-hide-settings-tab-in-page-edition/ https://processwire.com/talk/topic/3159-hide-settings-tab-in-page-edition/ https://github.com/ryancramerdesign/ProcessWire/issues/847

@Qurus On that line you are only calling one image....specifically the first one. If you want to output several images you would have to loop through them. Have a read here. something like $out = ''; foreach($post->blog_images as $img) { $out .= '<img src="' . $img->url . '" alt="img">'; } //then output $out later on down...within your <div class="img"....... @creativejay...get back to you later.....

Update: version 0.0.3 Updated original post. Now in modules directory: Option to allow Markup in menu items as per this request (superusers only) [note: although values are sanitized via HTML Purifier, it is your responsibility to ensure correct HTML input; also, if you previously allowed HTML markup but the menu was subsequently edited by non-superusers, your HTML will be stripped off] Added more options to MarkupMenuBuilder render() method - first, last classes, etc.(see Read Me) and... Added/enhanced wrapper_list_type and list_type options. The former allows you to specify menu items outer wrapper tag, e.g. <ol>, <div>, <nav>, etc....The latter allows you to specify alternatives to <li>, e.g. <span>. Note, if no list_type is specified and you override the default by 'list_type' => '' in your options, then menu items css classes/IDs are applied to the <a> tag instead. Updated code to ensure menu settings saved by superusers remain even for non-superusers (e.g. menu maxLevels, selectable pages, etc.) Note: Had an extra jquery.asmselect-mb.js in the root folder. I have deleted this in the repository. Note, it seems PageAutocomplete will not allow non-superusers to select pages unless they have a page-edit permission as well. Could somebody confirm/clarify? Thanks.

What Martijn said... You can wrap you whole menu with <nav> like this: $options = array('menu_css_id' => 'main', 'menu_css_class' => 'navigation'); $menu = $modules->get('MarkupMenuBuilder'); $out = '<nav>' . $menu->render(1234, $options) . '</nav>'; In that case, the menu will use the specified list type, <ul> default or <ol> However, if in $options you specify: 'wrapper_list_type' => 'nav', then, in order to output correct markup, MB will not wrap menu items in <li> but only <a> unless you also specified in $options some other tag other than <li>, e.g. 'list_type' => 'span'. What do you guys think?

@Mike, Could you clarify the sort of HTML structure you envisage? With <nav> only, how do you show sub-menus? i.e. <nav> <a href="link-1">Link One</a> <a href="link-2">Link Two</a> <a href="link-3">Link Three</a> <a href="link-4">Link Four</a> </nav>

That's because at the moment, when you change the menu 'Title', only the title gets changed and not the name (i.e. on the PW page). In rendering using a title or name, it looks for the name. In that case, your new title would be first converted to a name and the module would look for a menu page with that name, which would obviously not exist (since name was not changed). Rendering by ID would still work though. But, I see no reason why I should not change this behaviour. I will make it change the name to match the title as well to be foolproof. Since menu pages are not visible in the frontend and are not really for querying, there is no harm in that. Thanks for the suggestion. ps: If possible, could you file feature requests at the project page in Github? I won't have time to work on this today and might forget some things, thanks.