Moodle Community Sites

Hi Matt,

The requirement field options are currently as follows:

Any version of Moodle
Moodle 1.2
Moodle 1.2 or later
Moodle 1.3
Moodle 1.3 or later
Moodle 1.4
Moodle 1.4 or later
Moodle 1.5
Moodle 1.5 or later
Moodle 1.5.4 or later
Moodle 1.6
Moodle 1.6 or later
Moodle 1.7
Moodle 1.7 or later
Moodle 1.8
Moodle 1.8 or later
Moodle 1.9
Moodle 1.9 or later
Moodle 2.0
Moodle 2.0 or later

Are you suggesting we add further options? For example

Moodle 1.7 and 1.8
Moodle 1.7, 1.8 and 1.9

Hi Helen,

What I mean is that the 'or higher' ones are no use because the major changes in code between versions means that often a plugin tagged as '1.5 or higher' will be useless in 1.9. I think a better system would be to have only major versions i.e.

Moodle 1.7
Moodle 1.8
Moodle 1.9
Moodle 2.0
etc

and let people specify as many as necessary, so that its clear that if 1.9 is not on the list, it won't work in 1.9, rather than leaving it open ended. I realise this may mean re-tagging quite a few entries, but looking through the list now, I don't want to even try installing something that says 1.5 or higher because I expect it to fail on 1.9 and not be worth the effort. Major loss of function for me and probably far more frustrating for a novice who tries it and learns the hard way.

More specifically, I think multiple select is better than adding the options you suggested as the number of new options that need to be put into the dropdown (is it a dropdown?) will be larger every time a new version is released, whereas allowing multiple selections, means only adding one new option each time.

...I'm not sure that makes sense on second reading. Do you see what I'm getting at?

Hi Matt,

Would a multi-select menu or perhaps checkboxes (easier to use) be the best solution?

Either way, it will be a big challenge to change the requirement field in the modules and plugins database

I've added Anthony as a watcher for more thinking power on this issue.

Checkboxes, I think. Not sure why I didn't think of that earlier. End of half-term fuzziness probably.

Helen/Matt - Checkboxes would make sense to me.

When I have chance, I'm going to backup the modules and plugins database activity and have a play with it locally to determine which works best, a multi-select menu or checkboxes.

I'm also going to take the opportunity to change the wording of the status field from standard / third-party to core / contributed.

Are there any other changes needed?

I think some indication of whether its a plugin/module in the true sense of being in a single subdirectory, or whether its a collection of files that replace parts of core would be useful. Its a lot easier to undo somethng that doesn't mess with core. Also, if you maintain your site using CVS, you can get the folder from contrib and keep it updated automatically if its a plugin, whereas a change to core files messes up CVS updates of those files, so its good to know in advance.

Helen - Changing to check boxes would like make it most clear that we are wanting them to select all that apply. Considering that folks have been used to a drop down menu, if that stays the same they may not notice the ability to select more than one.

Might this be the time to consider in adding some type of rating system? I would really like to be able to start assessing a number of things including popularity, ease of installation, functionality/value (which indirectly gets at whether it should be in core), whether it is actively being maintained and by whom, quality of code (i.e. buginess), and portability (does it focus on a particular platform or can it be used in across the board). Perhaps some of this would best be handled by simply adding a feedback in the CONTRIB course. If someone uses a piece of CONTRIB code, we encourage them to provide feedback about their experience with it. That could give some type of metrics by which we could measure some of these things.

Peace - Anthony

Matt - My sense is that by and large folks are doing a good job of keeping their code modular. Blocks are blocks, mods are mods. Some combine a combination and the consensus has been to make it clear in the installation instructions of both the block and the mod that they work together and to install both. I don't know if we might (at some point) want to write some custom code for creating zip files such that if a block and mod exist with the same name that we combine them together.

What you are referring to as a plugin that overwrites core code is considered a patch. At this point, I think we have plugins (blocks, mods, and themes) and patches (like the GBPv2 patch). Folks working on patches are encouraged to keep their code updated. I would like to see that they include which version they used from core to merge their customizations with. In that way, it should be fairly clear how to update a file to incorporate the latest changes.

Peace - Anthony

Anthony - those are great ideas. Another to add (if possible) would be to somehow collect data from moodle registrations on which modules/block/plugins are installed, and derive a popularity rating that way.

Matt - Gathering those stats from Moodle registrations would be ideal. Peace - Anthony

Helen - What are your thoughts of changing the name modules and plugins? It is somewhat misleading. A good module is a plugin. The title says nothing of blocks and themes. It does not make the distinction between plugin vs. patch. I'm not a huge fan of patches and plugins. Contributed Code or Community Code come to mind although I think all of the code is Community Code - even core stuff done by the developers belongs to the community and in many cases in part comes from the community by responding to their issues in the tracker. If we change the name, what would be involved in changing the autolinking to the Modules and Plugins (I think this was autolinking on the forums)? I doubt it would impact the autolinking to a particular block or module but if we formalize a naming structure it would be nice to have autolinking on block: feedback and mod: feedback or even better feedback block and feedback module. I don't know how practical that is but it doesn't hurt to dream a little. Peace - Anthony

Thanks for the great suggestions Matt and Anthony

How about we continue our discussion in the Moodle.org design forum http://moodle.org/mod/forum/view.php?id=7135 in order to encourage further suggestions.

I am linking MDLSITE-353 to MDLSITE-265 as it that deals with the common idea of gathering more information from the site registration process. Peace - Anthony

Resolving as fixed since we now have http://moodle.org/plugins

Thanks everybody!