kongondo

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.

In my testing, outputting the menu is already fast enough. However, one other thing I need to experiment with is caching the menu templates or menu_items field and see if it can be even faster...

Thanks guys, Will look into it. Should be easy enough using $options. On my to do list: See $options. You can already do this: $options = array('menu_css_id' => 'main', 'menu_css_class' => 'navigation'); $menu = $modules->get('MarkupMenuBuilder')->render(1234, $options); Am I missing something? Will update docs later... Btw, one is not tied to using MarkupMenuBuilder -> you can easily json_decode($menuItemsJSON, true) the menu items JSON and recursively traverse the resultant array using a custom PHP function or even with javascript.

Update: Menu Builder Version 0.0.2 is now available. I'll update the original post later + post a new video. Main Changes: Beta status Menus stored as pages (note: just the menu, not the items!) Menu items stored as JSON in a field in the menu pages (empty values not stored) Add menu items from ProcessWire pages using page fields (option to choose between PageAutocomplete and AsmSelect [default]) or a Selector (e.g. template=basic-page, limit-20). For page fields, you can specify a selector to return only those specified pages for selection in the page field (i.e. asm and autocomplete) For page fields, now you can also add css classes and IDs as you add the items Menu settings for nestedSortable - e.g. maxLevels (limit nesting levels) Advanced features (e.g. add pages via selector, menu settings) currently permissible to superadmins only (may change to be permission-based) Delete single or all menu items without deleting the menu itself Lock down menus for editing Highly configurable MarkupMenuBuilder - e.g. can pass menu id, title, name or array to render(); Passing an array means you can conditionally manipulate it before rendering, e.g. make certain menu branches visible only to certain users [untested and the code is up to you!] More... Note: Some nestedSortable features not yet implemented/working (some are not really necessary actually). The module creates 3 fields (menu_items, menu_pages, menu_settings) and 1 template (menus). Menu pages are stored as children under the modules parent page (admin/setup/menu-builder/) - so not accessible in the frontend Issues: Drag and drop (ordering menu items) is some times finicky...something in the js I think or just my mouse.

Not sure you have seen this? Module: TextformatterTwitterReplace https://processwire.com/talk/topic/8868-module-textformattertwitterreplace/

Nice Nico, nice!

Sorted! (seems hackish but I don't really mind unless shown a better way ). Documenting this in case there is a better way.... Add a Hook after AsmSelect's output: wire('page')->addHookAfter("InputfieldAsmSelect::render", $this, "customAsm"); Slightly modify AsmSelect output in customAsm() $value = $event->return; $value = str_replace("\"multiple\"", "\"multipleMB\"", $value);//see why this below.. $event->return = $value; The reason for the str_replace is that in InputfieldAsmSelect.js you have this code: $(document).ready(function() { $(".InputfieldAsmSelect select[multiple=multiple]").each(function() {//note this var $t = $(this); if(typeof config === 'undefined') { var options = { sortable: true }; } else { var options = config[$t.attr('id')]; } $t.asmSelect(options);//note this }); }); We need to change the [multiple=multiple] to point to our custom selector multiple=multipleMB. We don't hack this but in our own .js file we have: $(".InputfieldAsmSelect select[multiple=multipleMB]").each(function() { /* blah blah */ $t.asmSelectMB(options);//this will be the name of our customised asmSelect function Final thing is just to include our customised jquery.asmselect.js, i.e. jquery.asmselect-mb.js. (config->scripts->add()) with the modified function $.fn.asmSelectMB = function(customOptions) { /* blah blah */ This way, I can still set my properties values (e.g. $menuAddPageItems->setAsmSelectOption('sortable', false); ) and Bob's your uncle. Downsides? AsmSelects native JS still gets loaded although I have no use for it. OK, back to coding...

OK, let me try again.... The AsmSelect or any other select field is for choosing the page that the user wants to add to a menu. That menu will be generated in the frontend (a navigational menu). With such HTML menus, usually, one adds CSS properties to the links - CSS ID, CSS Class as well as some other link attributes. So, I need the inputs to send data about these CSS and link attributes (nothing more than that). That info, will be stored elsewhere - hence, the inputs are really shells to temporarily hold data for POST. The pagefield I need for selecting the pages + their ID (from which I can do other stuff - e.g. know their URL, etc...). In essence, if you have had a look at the MenuBuilder thread, I want to mimick what I can already do with the custom menu items (see the table with inputs) - just to improve user experience. For the custom menu items, the user enters each link's title, link and (optionally) CSS details. The difference is that for PW pages, I don't need to enter a link (PW will generate that automatically for me on render) and the title I already have. Given the above. I have several choices. I can use my own js to mimick what AsmSelect does or slightly modify what AsmSelect does to suit my needs. I prefer using AsmSelect (or Autocomplete) just because they are convenient in many cases (as opposed to other page field selects). Currently, rather than reinvent the wheel, I am leaning toward using AsmSelect, just hooking into it and modifying it a bit. This is mainly because I am lazy and js is not my strong point... Thanks for your thoughts!