New module group "Config" or similar.

[raiwa]

I'm using for several of my Addons an own kind of modules which I called "Store" and which are revamped header tag modules.
These modules were born to allow to hold several things and avoid core changes before the actual extended hook system was available.
Meanwhile I migrated many features into hooks, but these modules are still very useful and I use them for the following:

• hold database install and uninstall scripts.
• hold configuration settings.
• hold language definitions which are used sitewide.
• some still do things in the execute functions.

The modules are loaded like header tags, but resorting the ht modules to ensure my modules are loaded first.

I wanted now to suggest to add a new core module group to allow similar things in core. The main purpose would be to offer the above mentioned things as a support for hooks.
This could be for example useful for the existing MATC hook (main status switch, page selection, holding language definitions) and of course for any third party Addon which need only hooks, but no other installable module which could hold the additional things.
These new module group should load preferably at startApplication before any other module.

Gary @gburton , Matt @ecartz do you think this would be useful.

[BrockleyJohn]

I have just been using ht modules with an empty execute for this but it would make sense to separate them. In effect it's a master plugin module and might be a good way of keeping function and presentation apart.

At the same time, a common approach to dealing with template settings might be a good idea. I'm doing the obvious and adding a configuration group so the template has its own page off the settings menu but if someone has a better idea...

[ecartz]

Note that it is easy to add a new module group. You just need to make a cfgm_ file and there it is. Burt made at least two as Pro code. And of course loading it in the startApplication is as easy as adding a hook file. So two files as a base, and then you could add any modules to those two files. I.e. you can get what you want without actually adding it to core.

Try that. Play around with it to get the effect that you want. Build a separate branch with it added to core and we can look at it. Because right now, I don't really understand what you need. So I can't tell you that it would be easier to do that by ...

Alternately, you could try to better explain what your requirements are, perhaps with examples. But it might be easier to simply code it.

I've also been thinking about how to redo some of the configuration as hooks. For example, we have a check stock configuration. So there's a code segment that basically says, if (CHECK_STOCK) check_stock();. What if instead, we registered it as a hook when it was supposed to run and just left it out when it wasn't. I don't know if that approach helps with what you are trying to do or not.

In terms of the MATC hook, I would prefer to make the create_account part a customer data module. Combined with a way to express configuration decisions as database hooks, I think that would cover the current two use cases for MATC.

[raiwa]

You just need to make a cfgm_ file and there it is.

That's what I'm doing already.

Please have a look at this branch which has several of my existing "store" modules added. I'll see to add the separate loading hook in the next update round.
https://github.com/raiwa/CE-Phoenix/tree/store-config-module-group

My suggestion is to have a predefined group in core which offers addon makers a common module group to be used for their hook based addons. Instead to add each addon maker his own group or use the ht group like Joh is already doing. It could be used in core if useful. The MATC hook is just an example to illustrate that it COULD be used for core hooks.

You can see in my branch for what I'm using it (/includes/modules/store/).
The base use is for things which can't be done in hooks:

• hold database install and uninstall scripts.
• hold configuration settings.

and if we have already a module, they can replace additional hook language files:

• hold language definitions which are used sitewide.

and maybe avoid some additional hooks:

• do things in the execute functions.
  Or maybe that they do not need the execute finction at all

Another use like John mentioned, could be for templates holding template specific configuration values.

Maybe @BrockleyJohn can give also some examples from his ht modules he is using in the same way.