ProcessWire Module Generator

[Soma]

"How to create a page while installation with a non-process module?"

Would now be in module config

public static function getModuleInfo() {
    return array(
        'title' => 'MyModule',
        'version' => 1,
        'author' => 'John',
        'summary' => 'My summary',
        'href' => '',
        'singular' => false,
        'autoload' => false,
        'icon' => false,
        'permission' => 'my-permission',
        'page' => array( // optionally install/uninstall a page for this process automatically
            'name' => 'my-super-processmodule',  // name of page to create
            'parent' => '',    // parent name (under admin) or omit or blank to assume admin root
            'title' => 'Super Duper ProcessModule',     // title of page, or omit to use the title already specified above
            )
        );
}

Icon is also missing.

[LostKobrakai]

@Soma

The headline talks specifically about "non-process" modules. The page config option is already used for Process modules. But sometimes a module needs a page e. g. for storing some files and for such things you still need to generate the page manually.

[Soma]

Ah. Hmm Then why is the code in there 

// tell the page what process to use (default to $this)

 $page->process = $this; 

[LostKobrakai]

Yeah, the example should probably be adjusted to not lure people to think it's needed for process pages.

[Nico Knoll]

@Soma: Thanks for finding. I removed the $this->process line and made the "non-" a little big bolder

[LostKobrakai]

I think it's not intended, that I can already choose 2.5.28 as required version.

Edit: And there are some issues with quotes in the module's info.json

[Nico Knoll]

@LostKobrakai: Fixed the \" bug. And 2.5.28 will be available tomorrow I guess so I'll leave it

[marcus]

@marcus: Of course! Let me know if [...] you want the source code

That would be great!

[Martijn Geerts]

Just here to say: I like your tool Nico!

[LostKobrakai]

A nice addition for the external config would be if one could choose the inputfield, which you're including automatically for the getDefault() values.

[teppo]

Nico, I'm having an issue you might want to take a look at: if the summary contains non-ASCII characters (in this case "ä" and "ö"), they seem to get stripped from the final file. Doesn't seem intentional.

Another thing I noticed, and this is more a gotcha than a real bug, is the optional "implements" setting. It's true that "implements Module" can be disregarded if you're extending something that already implements Module or ConfigurableModule, but leaving it out unintentionally will result in weird errors, and currently the UI seems to suggest that this would be optional in all cases. This could be confusing, especially to beginners.

Your default configuration options "+" UI made me wonder whether it would make sense to allow creating and bundling multiple module files at once? Most of my modules seem to actually consist of more than one module – a Process module for UI or API, another module for hooks, perhaps a third one for optional features, etc. This could be a border-case and would require some sensible server-side limits either way, so perhaps not worth the effort though.

I'm also wondering if the source code for this tool is something you'd like to share and/or open-source. Not sure what your long-term plans here are, but I'd be happier if I could see how this thing works, perhaps report bugs and send PR's via GitHub, and just overall be sure that if something goes wrong I can have another copy of this very useful tool online (or installed locally for cases where I'm not connected to the Internet at all).

.. and finally, I can't select ProcessWire 2.6 as "min. required PW version" yet

For the record, I'm currently writing a paper that'll discuss module development in detail, and I'm very happy to be able to suggest this tool as the preferred method of setting things up. Of course I'll mention the "old-school" method of duplicating another module as a starting point (and even starting from the scratch), but IMHO your module generator has made other approaches obsolete in many cases

[LostKobrakai]

Your default configuration options "+" UI made me wonder is whether it would make sense to allow creating and bundling multiple module files at once? Most of my modules seem to actually consist of more than one module – a Process module for UI or API, another module for hooks, perhaps a third one for optional features, etc.

Fieldtype + Inputfield is also kinda common.

[teppo]

Some additional observations:

• The way a version number is appended to module name in the docblock at the top of the file feels weird. It's a small thing and I can always remove it manually, but if the purpose is to mention the version of the module, I'd suggest using @version tag instead. (A question with both approaches is whether module authors will remember to keep this up to date with the module version recognised by ProcessWire, though.)
• Seems like basic docblocks for methods such as getModuleConfig() would make sense too, otherwise they'll have to be added manually for every new module (or worse, they'll be left out altogether).
• It would be awesome if the generator could make it easy to choose and include a license, preferably as a combination of @license tag + LICENSE file. A few common license types would suffice for starters; GPL, LGPL, BSD, MIT, and perhaps something like WTFPL too. I've seen many modules lately that haven't specified a license, and to me this is a huge red flag, as it literally means that I can't know how, where, and for what I can legally use said module.
• I was a bit surprised to see that implementing ConfigurableModule didn't enforce "include configuration page", as it seems like an obvious choice. Part of the confusion was that "configuration page" made me think it would add an actual page somewhere to contain configuration settings, which is why I left it unchecked in the first place..

For some reason I'm also getting blank array items in module config. Not sure if those are intentional or not, but they do look a bit strange:

            'requires' => array("PHP>=5.4.0", "ProcessWire>=2.5.3", ""),
            'installs' => array(""),

[LostKobrakai]

Having an empty install() method prevents the automatic installation of process modules, so there should either be a parent::install() in it or the selection should only allow either un/install methods or automatic page creation. Also the placeholder for page.parent config suggests "name=setup", while the field should only consist of the name itself.
 
 

I was a bit surprised to see that implementing ConfigurableModule didn't enforce "include configuration page", as it seems like an obvious choice. Part of the confusion was that "configuration page" made me think it would add an actual page somewhere to contain configuration settings, which is why I left it unchecked in the first place..

Implementing ConfigurableModule is only necessary if you're using the old static implementation. The "include configuration page" is a separate file, which does work no matter what the module implements.

[Mike Rockett]

I'm in the process of learning vue, webpack, etc, and thought this might be a good thing to work on. So I'm building a new generator. At the moment, I'm simply replicating the functionality that already exists, and I have an operational front-end working. As I dive into the back-end, I'll work on the changes mentioned above.

Quick question: Currently, selecting Process as the type of module enforces it to extend Process. Should I provide the ability to extend other Process modules?

[Mike Rockett]

Here's a screenie of the front end:

[szabesz]

Great to see that you pick up this project. Nice teaser too! I will definitely give it a try.

[kongondo]

16 hours ago, Mike Rockett said:

Currently, selecting Process as the type of module enforces it to extend Process. Should I provide the ability to extend other Process modules?

Yes, please. Some of my modules extend ProcessPageLister, for instance.

[Mike Rockett]

7 hours ago, kongondo said:

Yes, please. Some of my modules extend ProcessPageLister, for instance.

And done. Just need to add core modules to the shared modules list that the app uses to populate drop downs. Here's a gif: 

https://storage.rockett.pw/~pw/modgen-gif1.gif

(Edited: Inline gifs are cool, unless you can't start/stop them like in Twitter ?)

[szabesz]

2 hours ago, Mike Rockett said:

Edited: Inline gifs are cool,

GIF is good at "compressing stills" as it just stops for the period of time required so I normally start my GIF screen captures with a modest pause period and also take short breaks between actions so that the whole stuff is easy to follow.

[Mike Rockett]

4 hours ago, szabesz said:

GIF is good at "compressing stills" as it just stops for the period of time required so I normally start my GIF screen captures with a modest pause period and also take short breaks between actions so that the whole stuff is easy to follow.

Only thing is that it is still a user experience issue because the chances of someone scrolling into the gif and seeing it half way done are pretty high.

[Mike Rockett]

Working on some modifications with the front-end before I get to the back-end side of things. Part of the new front end has an informative process that helps you select a module license (super helpful for beginners). My question is this: Should I select MIT or ISC as the default license? They are functionally equivalent, however ISC removes redundant wording from the text, and so my inclination is to lean towards that. Thoughts?

[szabesz]

9 minutes ago, Mike Rockett said:

Should I select MIT or ISC as the default license?

+1 ISC. You might want to link to relevant choosealicense.com pages. Also, you could point out – in the UI – that ISC and MIT are "functionally equivalent".

Let's be progressive  

[Mike Rockett]

8 minutes ago, szabesz said:

+1 ISC. You might want to link to relevant choosealicense.com pages. Also, you could point out – in the UI – that ISC and MIT are "functionally equivalent".

Let's be progressive  

Thanks. Currently, the front end displays basic information about the selected license underneath its drop-down.

[szabesz]

Why not just link to choosealicense.com? Takes up less space (personally I always try not to use too much whitespace in the case of administrative GUIs). Also, they keep their database up-to date so no need to keep in sync should anything change (probably not, but one never knows...).