Pieter Beulque

Yes, that was some legacy code, probably because the class is copied from a Core Module. I published a new release that allows removal. Thanks!

Well, that makes sense. To be honest I didn't think of that. However, this gives you the choice of what to install and what not. It's a small difference. Thanks!

MultiPage Editor is a module that takes any valid ProcessWire selector and shows you all matching pages. You can edit all fields from one page, thus being perfect for bulk editing things like product pages or lists. It works best when selecting on template, because all pages will have the same fields. How to install: Download from: https://github.com/weworkweplay/ProcessMultiPageEditor Place the file ProcessMultiPageEditor.module in your /site/modules/ directory. In ProcessWire admin, click to 'Modules' and 'Check for new modules'. Click 'install' next to the 'MultiPage Editor' module (under heading 'Process'). Following that, you'll see a new menu option for this module on your Admin > Setup menu. Please note that the module currently only shows FieldtypeText-fields. This is something that probably needs some work.

JSON Installer is a module that allows you to define installer scripts in JSON. The module has proven its use when either setting up a big website for a client (it's easier to type all pages in a JSON-file than to create them all with the click-heavy ProcessWire admin) or doing repeated tasks. At We Work We Play we always do the same kind of setup (create a configuration page, add SEO & sharing fields, an 'Under Construction'-toggle) so this module automates this for us. Huge timesaver. How to install: Download from: https://github.com/weworkweplay/ProcessJSONInstaller Place the file ProcessJSONInstaller.module in your /site/modules/ directory. In ProcessWire admin, click to 'Modules' and 'Check for new modules'. Click 'install' next to the 'JSON Installer' module (under heading 'Process'). Following that, you'll see a new menu option for this module on your Admin > Setup menu.

Willy, you are right that I could indeed prefix my own modules with 'Other' if I really want to have them grouped together. I did not consider that before

Ryan, thank you. I figured out the naming scheme, but I'm thinking in this case it might be better checking for known prefixes (Process, Markup, …) and bundle all others under a section called 'Other'? Because, in this case, there is no way to account for a good sectioning. Naming my module 'WeWorkWePlayMailer' won't throw an error but groups it under 'We'. That's stupid. 'WwwpMailer' groups it under 'Wwwp', which is okay but an abbreviation should be all caps… In my opinion, it'd be better to have an 'Other'-section, allowing developers to group their modules using a property in getModuleInfo(); I might be biased.

Hello, I'm not sure if this is a known bug or not. I found a bug within the naming conventions of a ProcessWire-module. I am aware of the prefixes commonly used like Process and Fieldtype. However, when building a module that doesn't fit within any of the predefined categories, you are allowed to just work at root level 'ModuleName.module'. Correct me if I'm wrong. At work, we prefix our own modules with the company abbreviation (WWWP - Short for We Work We Play). With my previous module, a Process-type module, there was no problem. It was named ProcessWWWPInstaller (like the conventions say it should be named). However, I'm now building a hook-module so I don't think there's any prefix that I should use. I named my module WWWPMailer, and ProcessWire throws an error (showing WWWPMailer in an error field in /admin/module/). Everything still works but it doesn't look professional towards clients. Renaming my module WeWorkWePlayMailer.module works, and sorts it in the admin under 'We'. Is there anything to do about the plugin naming conventions?