Thoughts about modules that create their own fields, templates and pages vs. module config data

[Jonathan Lahijani]

What are the general thoughts around a module that creates its own fields, templates and/or pages that the module depends on?

For example, let's say an ecommerce module is developed and it needs a coupon feature like other ecommerce systems (each coupon has a code, fixed vs. percent discount, products it applies to, etc.).  Is it more 'proper' for the module to create the necessary fields/templates/pages in the page tree, or is this something that should be done in a module config?  Where is the line drawn?

SnipWire for instance stores its tax settings in module config and it looks like some non-trivial work went into getting that to work nicely, when the fields/templates/pages approach could have been used.

With the fields/templates/pages approach, I feel you have a lot of flexibility and it's nice to be able to query the data with $pages.  But on the flip-side, you then have to potentially inundate a ProcessWire setup with your own set of fields/templates/pages and conflicts can occur (although this can be worked around which I have successfully done).  Then there's the scenario of what you do if the module were to be uninstalled: do you removed the custom fields/templates/pages that the module relies on or should the user do that manually? (or should there be a separate uninstallation / cleanup module?)

[rick]

I draw the line at what is necessary for the module to begin functioning and what is produced during the normal functioning of the module. I put the former in the config while the latter is generated during runtime.

[apeisa]

I generally prefer modules not to "pollute" anything with fields and templates. I believe it is also quite a rare need for modules to really to create pages, templates and fields.

Of course you generally don't get "turnkey solutions" this way, but more lower level modules and building blocks. For simple example: any modules related to event calendars are just tools to help you build event calendars (render helpers, fieldtypes etc) until they actually create templates and fields for you.

[bernhard]

9 hours ago, apeisa said:

I believe it is also quite a rare need for modules to really to create pages, templates and fields.

Almost all of my modules I build nowadays do exactly that. That's why my RockMigrations module takes a different route than Lostkobrakai's -> you can ship migrations with your modules and your module basically just needs to implement one migrate() method:

class MyModule extends WireData implements Module {
  ...
  public function migrate($rm) {
    $rm->migrate([
      'fields' => ...
      'templates' => ...
    ]);
    $rm->createPage(...);
  }
}

It looks like overkill on first sight, but it is of so much help once you need to revert back, fix bugs, change things, push to a live system while the live system can't be shut off for development or finally: Reuse your work to not build everything again on the next project...

At the moment I fire those migrations on every modules::refresh - that works but is not ideal. Having migrations for every version (001.php, 002.php, etc) on the other hand makes things less easy to understand. You end up with template/field setups split up in many different files whereas if you have everything in one migrate function you see the setup on one glance.

Maybe I should just add a RockMigrations::fire method that can be hooked instead of the Modules::refresh...

[Macrura]

I think it is an important and valid question, discussion topic.

One option is to let the admin set, within the module config, which template(s) to be used for X purpose, which page root, and so on. (This is how it is done in various modules).

Another option is to include JSON files for field, template and page creation with the module and let the admin install them.

Or have the option to install the fields, templates and pages, or not (using a checkbox in mod config), like in the AdminHelp module. This means that anyone who downloads the module will be able to make their own decision about if they want to install all of those things.