12
Because the module repository is referenced by many articles and pages, not only on XOOPS.org, but by the whole internet, it is IMHO a big treasure to keep. So, using another module will spoil all that.
Therefore I was planning to rework the existing repository module. Unfortunatly I didn't have much time for it.
These are the things that I will address.
Add a possibility to have category aliasses. This means that the same module can be a member of more than one categorie. This is for better cataloging multi purpose modules.
Integrating the similar existing functions of WF-links would do the trick.
For the older versions I have tought on this solution.
I want to preserve all modules and versions, because the said back linking and also for reference.
In order to have a clear overview of the modules, I will add two fields NewVersion and OldVersion.
These will be displayed as links in the module overview and allow navigation along the history of the module, mosttimes up to the latest version.
The Latest version of the module has no newer version, so this field is then empty. This fact will be used to limit all the list functions to select only the latest versions. The field will be part of an index field in the database to ease this search criteria.
Previous versions of a module can only be reached by following the OldVersion link or having a 'historical' direct link from other internet pages.
Maybe another field could link some related items as eg translation files, manuals, plugins or prerequisite modules. But that's more complicated to find a good structural base for that. The best thing I came up is a free text field, to put several links in.
The module description should be in a kind of standarized template manner, with some fix paragraphs as
module description, user functions, admin functions, blocks, screenshot, etc
