Leaderboard

I tend to run all my posts through an online spell checker, just to catch any silly mistakes before they go online. Usually it does a decent job, but sometimes it doesn't quite get the context right. Today's suggestions included – among other more-or-less sensible options – "Wiretap" (for WireHttp), and "Bodybuilder" (for FormBuilder). Then again: since we already have "Admin on Steroids", perhaps a Pro-module called Bodybuilder is just the next logical step? ?

I've been working remotely this week and haven't had a good place to sit or very particularly reliable internet, so I've put my attention towards things that I could make progress with in small and inconsistent chunks of time. As a result, it worked well to focus on resolving issue reports this week. In addition to updates mentioned last week, 3.0.134 resolves 18+ issues and contains roughly 25 commits relative to 3.0.133. Since most of the commits since last week are focused on resolving issue reports, I don't have much to write here beyond what's in the commit log, but do want to thank everyone for their reports and hope that you have a great weekend!

On a slightly serious note though: There are CKEditor plugins for spellchecking. I think AOS has one of those (SCAYT) built-in. It's quite handy. Among other things, you can choose to ignore a suggestion, or add your own phrases to the dictionary. (Of course, this won't work with plain-text fields)

MarkupMenu is a markup module for generating menu trees. When provided a root page as a starting point, it generates a navigation tree (by default as a HTML "<ul>" element wrapped by a "<nav>" element) from that point onwards. If you've also provided it with current (active) page, the menu will be rendered accordingly, with current item highlighted and items rendered up to that item and its children (unless you disable the "collapsed" option, in which case the full page tree will be rendered instead). Modules directory: https://modules.processwire.com/modules/markup-menu/ GitHub repository: https://github.com/teppokoivula/MarkupMenu Usage As a markup module, MarkupMenu is intended for front-end use, but you can of course use it in a module as well. Typically you'll only need the render() method, which takes an array of options as its only argument: echo $modules->get('MarkupMenu')->render([ 'root_page' => $pages->get(1), 'current_page' => $page, ]); Note: if you omit root_page, site root page is used by default. If you omit current_page, the menu will be rendered, but current (active) page won't be highlighted etc. A slightly more complex example, based on what I'm using on one of my own sites to render a (single-level) top menu: echo $modules->get('MarkupMenu')->render([ 'current_page' => $page, 'templates' => [ 'nav' => '<nav class="{classes} menu--{menu_class_modifier}" aria-label="{aria_label}">%s</nav>', 'item_current' => '<a class="menu__item menu__item--current" href="{item.url}" tabindex="0" aria-label="Current page: {item.title}">{item.title}</a>', ], 'placeholders' => [ 'menu_class_modifier' => 'top', 'aria_label' => 'Main navigation', ], 'include' => [ 'root_page' => true, ], 'exclude' => [ 'level_greater_than' => 1, ], ]); Note: some things you see above may not be entirely sensible, such as the use of {menu_class_modifier} and {aria_label} placeholders. On the actual site the "nav" template is defined in site config, so I can define just these parts on a case-by-case basis while actual nav markup is maintained in one place. Please check out the README file for available render options. I'd very much prefer not to keep this list up to date in multiple places. Basically there are settings for defining "templates" for different parts of the menu (list, item, etc.), include array for defining rules for including in the menu and exclude array for the opposite effect, classes and placeholders arrays for overriding default classes and injecting custom placeholders, etc. ? MarkupMenu vs. MarkupSimpleNavigation TL;DR: this is another take on the same concept. There are many similarities, but also some differences – especially when it comes to the supported options and syntax. If you're currently using MarkupSimpleNavigation then there's probably no reason to switch over. I'd be surprised if someone didn't draw lines between this module and Soma's awesome MarkupSimpleNavigation. Simply put I've been using MSN (...) for years, and it's been great – but there are some issues with it, particularly in the markup generation area, and it also does some things in a way that doesn't quite work for me – the xtemplates thing being one of these. In some ways less about features, and more about style, I guess ? Anyhow, in MarkupMenu I've tried to correct those little hiccups, modernise the default markup, and allow for more flexibility with placeholder variables and additional / different options. MarkupMenu was built for ProcessWire 3.0.112+ and with PHP 7.1+ in mind, it's installable with Composer, and I have a few additional ideas (such as conditional placeholders) still on my todo list. One more small(ish) difference is that MarkupMenu supports overriding default options via $config->MarkupMenu. I find myself redefining the default markup for every site, which until now meant that each site had a wrapper function for MarkupSimpleNavigation (to avoid code / config repetition), and this way I've been able to leave that out ? Requirements ProcessWire >= 3.0.112 PHP >= 7.1.0 If you're working on an earlier version of ProcessWire or PHP, use MarkupSimpleNavigation instead.

After forgetting the class name of the wonderful AdminPageFieldEditLinks module for what feels like the 100th time I decided I needed to give my failing memory a helping hand... Autocomplete Module Class Name Provides class name autocomplete suggestions for the "Add Module From Directory" and "Add Module From URL" fields at Modules > New. Requires ProcessWire >= v3.0.16. Screencast Installation Install the Autocomplete Module Class Name module. Configuration Add Module From Directory Choose the type of autocomplete suggestions list: "Module class names from directory" or "Custom list of module class names". The latter could be useful if you regularly install some modules and would prefer a shorter list of autocomplete suggestions. The list of class names in the modules directory is generated when the Autocomplete Module Class Name module is installed. It doesn't update automatically (because the retrieval of the class names is quite slow), but you can use the button underneath when you want to retrieve an updated list of class names from the directory. Add Module From URL If you want to see autocomplete suggestions for the "Add Module From URL" field then enter them in the following format: [autocomplete suggestion] > [module ZIP url] Example: RepeaterImages > https://github.com/Toutouwai/RepeaterImages/archive/master.zip Awesomplete options The "fuzzy search" option uses custom filter and item functions for Awesomplete so that the characters you type just have to exist in the autocomplete suggestion item and occur after preceding matches but do not need to be contiguous. Uncheck this option if you prefer the standard Awesomplete matching. Custom settings for Awesomplete can be entered in the "Awesomplete options" field if needed. See the Awesomplete documentation for more information. https://github.com/Toutouwai/AutocompleteModuleClassName https://modules.processwire.com/modules/autocomplete-module-class-name/

@apeisa Would you consider merging this PR? https://github.com/apeisa/ProcessRedirects/pull/17

@horst, I have implemented your request in v0.1.1 as a separate autocomplete on the "Add Module From URL" field. See the updated readme for details.

Great, thank you ? Would be great if you could add an option to set markup of some popular css frameworks easily on your todo list as well ? eg $config->MarkupMenu = 'UIkit3'; // $config->MarkupMenu = 'Bootstrap4'; // ...

Looks really good! Many thanks! Can‘t wait to arrive into my office and setup my list and add all to my starter profile. Really great! ?

Enjoy your weekend too!

A recent answer to a similar question:

Imho, This functionality really should be in the core Gideon

Works great, thanks.

There already is one, the textarea selector is "textarea:not(.noAutosize)". I haven't checked it yet but in theory it should work. Otherwise you could apply a max-height with CSS that could also help, or perhaps setting the height with !important.

@tpr, would you consider adding an exclude class to the "Autosize textareas according to content" feature? Generally I like this feature but I have some modules with textareas in their config that contain a lot of content and would like to be able to exclude these from being autosized. So I was thinking there could be some special class that can be applied to textareas (e.g. "no-autosize") and the AOS feature when enabled would apply to all textareas without this class. What do you think?

OK, but before that, since another user has experienced some issues with the Utility Class, I think I'll just move the class to its own file and require it. We'll try that first to see if it solves your issue. Thanks.

It wouldn't be safe to exclude pages without template files from most find()s as that would be making the assumption that all find()s are for presenting navigation or search results to a user. PW makes no assumptions about what you are using the data for, so couldn't safely exclude pages based on that factor. If we were to implement something for this in the core in the future, we'd probably do it with a new selector option like "template_file_exists=1" or something along those lines. But if you've got pages without template files showing up in your search results, it might also be good to look at whether your search might need to be made more specific, or if your pages with no template file should be excluded with an access controlled parent. But I'll keep marinating on this template_file_exists option for selectors, as it may be a worthwhile addition.