I need the community opinion on this GIT Push request

[Edric Navarro (enav)]

https://github.com/joomla/joomla-platform/pull/352#issuecomment-3822504

thanks for participate 

[Ofer Cohen]

I think you first require to put more info like why we need this feature in the core with some background (perhaps there is other solution for this problem). In addition, describe the solution in this stage (module helper), what send for the trigger and why, etc.

Let's start with this and let's keep going.

Ofer Cohen
Joomlics Anonymous Group

On 02/09/2012 05:53 PM, Edric Navarro (enav) wrote:

https://github.com/joomla/joomla-platform/pull/352#issuecomment-3822504

thanks for participate 

--
You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
To view this discussion on the web, visit https://groups.google.com/d/msg/joomla-dev-cms/-/GrwlGJF2bqMJ.
To post to this group, send an email to joomla-...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.

[Rune V. Sjøen]

One of the primary reasons this would be great to have is to allow
system plugins to modify and "marshal" the array of modules to be
displayed on the page based on other criterias than just menu item id.

An example use case is a gallery component which has an accompanying
module. While initially we would like to display said module on all
pages included in the gallery component, we only want to do it if some
criterias are met. These criterias could be anything, X minimum number
of pictures, X days since last update, etc.

While the module theoretically could handle this itself and not spit
out any output in those cases, it will still end up being counted by
countModules() and in the various template frameworks out there that
means that the module position it is in will be shown along with the
chrome of that module. So if that module is the only one in that
position we will get empty areas on the template.

As I see it, this pull request implements only flexibility and there
are no real drawbacks. I agree with Andrew that the event should be
called onModulesBeforeLoad()

Cheers,
Rune

[Stephen Brandon]

Hi Rune,

there are at least 2 components out there, plus at least one template framework, using an override for the module helper class that adds some triggers to allow plugins to alter the contents of the module array.

The components are MetaMod Pro, and Advanced Module Manager. The JA T3 template framework has been using the same override, at least until recently (we haven't all talked about it for a while).

I had some discussion with the Andrew Eddie at the time of Joomla 1.6 to see if we could get our (minimal) changes into J1.6 but the discussions stalled.

In our version of the module helper class we have added 3 consecutive triggers in the _load method:

onPrepareModuleList

onAlterModuleList

onPostProcessModuleList

1 in renderModule:

onRenderModule

1 in getLayoutPath:

onGetLayoutPath

The reason for having 3 in _load is that Peter (Advanced Module Manager) and I (MetaMod Pro) found that there are a number of different types of operations that our extensions needed to do with the module list, and they generally needed to be in a specific order.

- onPrepareModuleList is for plugins that have a brand new way of generating the module list, e.g. from an external source, or joining extra database tables.

- onAlterModuleList is for plugins that want to shuffle/add/remove items from that list

- onPostProccessModuleList is for plugins that want to alter the parameters of the final set of modules, and don't want to add or subtract any modules.

The order is important because, for example, Advanced Module Manager generates the list of modules in a completely new way, MetaMod Pro then "expands" some of the modules to possibly include new modules or delete other ones from the list, then MetaMod Pro can also change the parameters of any existing modules in the list. It did not (and does not) seem right to force the user/admin to manually shuffle the order of plugins in order to enforce this ordering, if we can build this into the logic of the plugin system by using 3 separate trigger points. It just makes sense.

I'd like to put in a plea to use the system that Peter and I have already worked on, even if it gets tweaked some more - that's fine.

Since he and I both have very widely used extensions using this system, we have had a lot of experience in working with module lists, and this is an extremely workable system that allows our extensions, plus T3, to work together with no conflicts, and no need for admins to shuffle plugin order in order for them to work together.

I'll be happy to supply the override we're using - or you can get a copy from Advanced Module Manager.

Rune, I like your use-case. MetaMod Pro has hundreds of users who are doing exactly this sort of module selection criteria to control their modules, and they love it. There is a demonstrable need for this.

Best regards,

Stephen Brandon

metamodpro.com

[Peter van Westen]

Yep, like Stephen ha stated, adding the extra module event triggers would be very welcome (necessary).

There is also an extra onCreateModuleQuery that will pass the query to grab the module list to the plugin.

This is a standard array holding the different query parts. The plugin can then add/change/remove stuff in that query array and pass it back.

From that array a true query object is built and used to get the modules list.

My version of the ModuleHelper is attached.

[Ofer Cohen]

Why should it be triggered for the array of modules and not for each module?

Ofer Cohen
Joomlics Anonymous Group

[Peter van Westen]

Please read reply by Stephen Brandon.