I'm really happy to announce that the new Moodle Plugins is now live! (at last)
It doesn't have much data in it yet, so it's not quite ready to replace the old Modules and Plugins .
We would now like you (Moodle developers!) to start adding your own plugins to the new database. You'll need to register a new entry for the plugin itself, and then create a "version" within that plugin every time you make a release. At first you'll have to wait for everything to be approved before it goes live, but trusted developers will get more privs later.
Once we have a critical mass of data we'll start directing everyone there to the new one and will gently retire the old one (but keep it visible for reference purposes, since I suspect a lot of old stuff in there will never (and should never) be migrated to the new one).
Eventually the new database will also be the source of data for a new "Check for updates" feature within Moodle, that's why we are being very strict about the naming and formatting in this one.
It will also be the location for official reviews of plugins for security, accessibility etc
Thanks to Sam, Marina, Anthony, Michael and everyone else who has helped getting the database where it is so far. We'll keep continuing to tweak and improve it while it gathers data and feedback.
It's looking like a great improvement over the old database, but I have a couple of questions:
- Is there (going to be) a way of automatically picking up the zip files from source control, rather than having to manually generate and upload them?
- Where do we put 'packages' of plugins that work together (e.g. my checklist plugin, which has an activity that works on its own, but also a grade report and block which are dependent on the main activity)?
1. This is discussed already several times. So it seems that we will implement it at some point. But this would also mean that contributors have to maintain the correct directory structure in the repository as well.
2. Please upload components independently as separate plugins and write to Anthony (or specify in the plugin description) that components are supposed to work together. Anthony or other moderator will create a set and combine the components.
Not sure a separate discussion link is necessary ... we already have:
- comments, for small general comments
- website link, for more info and possibly discussion
- tracker link, for bug reports and feature requests
About making it easier for developers to publish new releases, we'll do it but it will take some thinking to do it securely. One thought was that we read a feed from you with new details for each new release.
About making it easier for developers to publish new releases, we'll do it but it will take some thinking to do it securely.
I've released an alpha version and will be releasing updates on almost a daily basis until the module matures. The current 'wait for approval' system makes it necessary for me to release also through git (I cannot attach the zip in the forums due to size) but I prefer one place and that the place will be here. While a review of a plugin is important I think that after the first approval, it should generate a static stamp rather than change access permissions.
Some remarks about the new plugins site...
1.- The new plugins site says "This is our new plugins database, which will list all the non-core modules that you can plug in to Moodle. We are still in the process of moving across content from the old Modules and Plugins database, as well as the the old Themes database."
Who is the "we" in "We are still in the process of moving across content etc." ? Not Moodle HQ, I suppose, but 3rd-party contributors. If so, I suggest that both the old and the new site display a clear statement inviting 3rd-party contributors to move/copy their stuff from the old to the new...
2.- Also, when we arrive on the front page of the new site, there might be a short note explaining to would-be contributors that they'll have to enter one of the Categories in order to "register" their plugins.
3.- It is not immediately obvious what the (1 + 4), etc. numbers following the category names mean. Actually, I do not even understand what it means at all.
4.- I am also puzzled by the following example.
Blocks: Drag and drop file upload
Drag and drop one or more files directly from your desktop into a Moodle course
Maintained by: Davo Smith
In the Download versions tab, what on earth means:
Current unavailable version
How can it be at the same time "unavailable" and have an active Download link?
5.- Shoud not the rights to Add a new contributor & even more to Make lead maintainer be reserved to the original contributor?
For some reason you may have been seeing what admins see, which has a few extra things. I can't see that you have any extra permissions currently, someone else may have fixed it already ... can you please confirm with me that the interface looks different for you now? eg the numbers you were seeing (4+1 means 4 approved, 1 unapproved).
The statuses are confusing I know. Basically there is one for the state of approval (controlled by admins) and one for whether releases are available to ordinary users (controlled by admins and contributors). It'll be simplifed very soon into one state that makes more sense.
I've improved the text too.
Looks like a big improvement, many thanks!
Many many thanks for your efforts!!!
I can't imagine my moodle work without the community...
This looks awesome! Kudos to all involved.
I am planning on shifting my code to github in the next week or two. Any advice on how to do this effectively?
I'm keen to take advantage of the social side of github, so I'm trying to think of how to best integrate that with the new plugins database. I've found a lot of people in the past adding comments on the plugin page, which were not noticed by me for months due to a lack of notifications. Also, as noted, it's not the best place for discussions. Maybe we could have a JS widget that would link to a github comment feed ro similar?
I was wondering as well how to set up my version control scheme best for integration with the new plugin DB. (I'm using git.)
The developer documentation recommends that contributors should "maintain a branch for each major Moodle release (i.e. 1.8, 1.9, etc.)". Is that still valid for the 2.x series? And would each branch then correspond to a "version" in the plugin DB?
Further, if I now implement a bug fix, for which I update all branches, would that mean uploading 2 or 3 new "versions" to the plugin DB (one per branch)? (That actually seems a bit much - would it be easier to refer users to github for the latest bugfixes?)
Or is it a better idea to provide versions of plugins that support several Moodle releases; say, "2.0 onwards"?
There's certainly no unique answer here, but I'd be interested what works best in your point of view.
You only need to maintain a branch for each Moodle branch if your code is different. Depending on your code, a 2.x branch for it will be sufficient (if it runs on all Moodle 2.x).
Yes, you do need to upload packages every time you make a "release" of the plugin. This doesn't need to be every single bug (just the same as we do with Moodle).
You are welcome to point experience users to your git repository (we have fields for that), but this database is for people who want to deal with known stable releases, not bleeding edge code. The concept of storing your releases in the central database will also make the upcoming "Check for updates" feature possible in Moodle.
In future we will definitely allow some way for trusted developers to automate the updating of our packages in the database, probably via a specially-structured RSS feed that you supply to us.
but thisis for people who want to deal with known stable releases, not bleeding edge code
That's one way to look at it but it seems to me that this way misses an important aspect of what we're doing here, especially since some are happy to call it constructivism. Constructivism is not only already constructed end products but also products under construction. Some may even argue that the process is more important than the result. "Bleeding edge code" (aka alpha and beta versions) is important for informing the community what is worked on and for allowing community members to play with preliminary versions or to adopt ideas and implementation techniques. The forums are too busy to offer a clear view of what is cooking.
The plugin repository is the best place for this. The repository can have a principal categorization to stable and non-stable packages. This is just a matter of filters. So members who are interested in stable versions can look only in that category. It does not have to interfere with automated updating system of stable packages since packages can be flagged as stable/unstable and the updating system can count only the stable packages.
Alpha and beta versions can have a no-update timeout after which they are automatically archived but remain available for exploration. Just consider that someone may start working on a really good idea but for various reasons must drop the project. Someone else might see the the alpha/beta version in the archive and decide to revive it and even bring it to maturity.
While it is important, for the sake of stability and security, to regulate what goes into the core and through the automated updating system, the repository should stay as open as possible so that constructivism won't be just another empty word.
What you describe could be nice but will also complicate everything quite a bit.
I don't see that we should spend too much effort trying to duplicate what git already does very well (especially when we still have work to do on the basic system as it is).
If people want to use bleeding-edge alpha code then they will probably want to update quite often. So why not just give them directions for installing direct from your git repository (eg http://docs.moodle.org/20/en/Git_for_Administrators#Installing_a_contributed_extension_from_its_Git_repository) and make their life easier?
When you control a well-known software and create a place for distribution plugins for it - and place restrictions (e.g. validator that can't be bypassed) you are almost introducing a law on the plugins authors.
The laws forced in Moodle plugins Directory was forced on people in most rought way violating basic ideas of most modern judicial changes:
- It was created as so called "Ex post facto law", forcing validation on the Moodle plugins for Moodle versions existed before it was created;
- Any law must be published in well-known source before it is enforced (and it should be enforced only to the code written before publishing). Coding guidelines doesn't count as validator strictly requires only a small portions of them. There were no published link to the complete list of the rules developers must follow to be included in the Directory on the page when registering new plugin.
- All should be equal before the law. There are a lot of code in the Moodle core itself that would not go throught Moodle Plugins directory validator (should we wonder why there is no entries for the core plugins as in old database?). But the validator rules are forced only on 3d party plugins distributed throught moodle.org but doesn't affects core code distributed throught the same site.
The results from such distribution scheme is very unconvenient to the both 3d party developers and site admins:
- it forbids having one distribution packet of several plugins which should work together (like question type and necessary behaviours or block and quiz access rule accompaning it), forcing admins to find and install all necessary plugins separately;
- it forces developers with release ready to do changes potentially able to break many places in module - like renaming DB table - which could lead either to full retesting of module or haste re-testing and release with much more serious errors that the ones fixed - Martin, would you force Moodle HQ developers to rename tables in a week before release?;
- don't allowing repostitory access is common point, "just the same as we do with Moodle" Martin says - well, the Moodle does weekly releases and these are not manual, but automated. It's not hard to have master branch for "bleeding edge code" and stable branches for Directory.
The irony of situation is that validator checks not the rules that really important (like securty ones) but the ones that are easier to check (thought they are quite rarely leads to real problems). But it totally prevents even Moodle HQ admins from seeing the code and making decision, whether these rules are really important in that particular case.
Therefore, as a project leader and maintainer of PREG question type, used by some people from Moodle 1.9; and several upcoming plugins (http://code.google.com/p/oasychev-moodle-plugins/) I decide against using new Moodle Plugins Directory to distribute my code. I'll upload it only to be sure it satisfy validator (it's seems the only way to be sure) - I have no problems with rules themselves, only with the way they are enforced. I may reconsider if it will become better and more usable later (you could find some practical ideas how to do it at http://moodle.org/mod/forum/discuss.php?d=192083#p835967).
If you'll allow me to have a page with links in Moodle Plugins Directory without hosting code I'll use it, if not - I would be able to live with it.
I'm sorry for the inconvenience of the users involved but thems seems to be only way to get better Plugins DIrectory for all. I don't think losing my question type would hurt Moodle much, so you are free to continue with you policy thought.
For those wondering what convenient way of distribution several plugins I talked about is - you could look at http://oasychev-moodle-plugins.googlecode.com/files/preg-question.zip - unpack it in root Moodle folder and it would get all necessary stuff in place. It's actually not very hard to make an interface to assemble such distributions in the new Moodle Plugins Directory IMHO.
Well, the first part of problem is now solved - we get a link to a list of rules in the plugin upload page, and some particular bad cases of validator behaviour are fixed.
Now for unknown reasons we don't get the second part. People should know whom they are supposed to contact if they have problems with validator. Old plugins database contained link to the Anthony Borrow account and encouraged to PM him if the plugin was stalled in review.
Now the page rejecting the plugin for errors (and maybe even given warnings) should contain a link to the person (probably Marina Glancy?) plugin authors are supposed to contact if they have troubles with validator. That would very much lessen frustration from trying to share useful and complex work and been just thrown off by a piece of software. It is requested as MDLSITE-1623
A similar link to a human reviewer may be useful to show for the plugin authors while they wait for manual review.
Placing such link is an easy thing. If it would be done, I'll probably reconsider and submit my plugin to the new Directory.
Oleg - I am happy to answering any questions that folks may have about Moodle Plugins and work toward creating issues in the tracker for Marina as needed. If someone is pretty certain that there is an issue then they are perfectly welcome to report it directly in the tracker under MDLSITE project and the Moodle.org/plugin component. Those issues get assigned directly to Marina. I think part of the frustration has been my lack of availability over the past couple of months for which I apologize. Folks should feel free to give me a bump if they feel that the plugin is not getting the attention it deserves. Peace - Anthony
Anthony - this is very good, but the problem is people not know they are supposed to contact you when they have problems with validator. It's a one thing been just rejected during upload - and quite another receiving message "contact this man if you have problems with validation" along with validation errors/warnings.
Old Plugins Database have a big letter wit link to contact you if there were any problems during approval. There should be similar text for both validator and human approval phase on the new Directory IMHO
P.S. It would be also good if someone re-open MDLSITE-1625, a feature request which Marina closed right away (but it was so popular that it received two votes before been closed). Better to leave it open to gather votes etc. Regular people like me doesn't seem to have rights to reopen issues on the tracker. I've added you as a watcher there...
The new plugins database is looking good - but I have a couple of questions:
- Should I be notified (by email?) if a submission is approved? I don't seem to have been notified that the Decaf theme I submitted has been approved, but it does seem to have been approved at some stage.
- How long should we expect approval to take? I'm not sure how long Decaf took (due to the lack of notification), but I submitted an assignment type late last week which has yet to be approved. I don't mind waiting, but it'd be nice to have some indication of how long we should expect to wait...
Paul, notifications are on TODO list: http://tracker.moodle.org/browse/MDLSITE-1427
Approval usually takes couple of days, except when moderators are on vacation (what probably happend in your case). We'll add some information about it on moodle.org. Thanks for pointing it out.
Furthermore, the requirement to upload a copy of the module when registering is giving me some pause for thought, since part of our business is dependent on driving traffic to our own website and this would remove a reason for people to visit us. I suspect the impact wouldn't be all that great since most users of our users would still need to come to our website to view the tutorials, help database and support forum, but it is still something I have to consider when registering or updating a plugin.
Tim, contributors can fill "alternative download URL" and vcs repository links if they wish. Also we plan to automatically collect archive from git repository. When users download archives from moodle.org we collect download statistics (already) and will soon show the 'most downloadable' rating, which is also quite convenient for user. Would be hard to do it in case of external resources.
we now have very strict requirements for zip cotnent.
version.php is required for everything except themes (though recommended for themes)
Regarding $string['pluginname'] - I'm sorry, that was my mistake. For activity modules the $string['modulename'] is required. I fixed it already, it will be updated on moodle.org within couple of hours.
If you have other suggestions about archive validator, please post them to http://tracker.moodle.org/browse/MDLSITE-1494
Finally getting onboard. I added a new entry for our Adobe Connect plug-in. I was able to upload the zip for 1.9, but now I cannot figure out how to upload the 2.0 version. Is there something I'm missing?
(edit - Solved my own problem. At the bottom right, under the "Settings" block, there is an "add new version" link).
Bit late to the party on this one, only really took a look yesterday for our new release. The database looks good! Many excellent improvements over the previous one, and I particularly like being able to display both readable and system version numbers, as well as having multiple release versions under the one header.
A quick question regarding approval: will a block be rejected for generating a warning on upload? I get no fatal errors, obviously, but I too receive the version.php warning. As our current block is built for 1.7 through to 1.9, I ignored this as I didn't fancy creating a separate installer for 1.9, just to insert a file it won't use. (2.0 will get a separate and vastly improved installer.) After reading this thread I'm now thinking it might get rejected, which seems unnecessary.
Also, a few suggestions (nitpicks) if I may:
- On the first page after submitting the zip file, the rich text editor, which appears on subsequent edit pages, wouldn't load for me, so I inserted everything in plain text, then went back in and edited it later.
- When submitting a module for the first time, you can input release notes for the version you're releasing and a short description, and then later on once the module page is running, you can add a general description of the module. It would be cool if we could add this on the initial page at the same time as the rest, just to save going back in and editing things. (Love the README parsing, by the way.)
- The logo image uploady doodah doesn't give any hints as to what size the logo will be displayed at. I ended up re-uploading mine as it looked a bit dodgy on display.
- Once submitted, you're presented with your page as "marked for approval" and no edit link is displayed. This might be intended behaviour while the module is being approved, but once I was able to see the whole thing, I wanted to tweak and add bits, like the logo. Fortunately, being a cheeky sod, I was able to page back in Firefox and re-submit the form, but an edit link would be nice.
But these are all small issues really. Overall, the new repo looks like a great improvement over the old. A while back, I was working on an auto-update and deployment system for Moodle, before contractual issues got in the way, so when the uploader yelled at me for my file structure, I had a big knowing grin on my face. Good to know Moodle will get such a system - I've always thought it was begging for one.
Nicely done, guys, and thanks to everyone involved in creating it.
warnings do not necessary lead to unapproval of your plugin. This is just a result of automatic check. There could be a plugin absolutely correct and with no warnings but only a real person (moderator) can notice that it has huge security holes. We decided that version.php is very recommended but if it is not required in your case (block for 1.9), this is not fatal.
Please note, that there are separate intances - the plugin and its versions. During registering a new plugin there are fields regarding the uploaded version AND plugin, because you have to register both. But after that you can edit either plugin (link 'Edit this plugin' in the settings block), or the particular version (link 'Edit' on versions page). You are allowed to edit plugin in 'Waiting for approval' status.
Thanks for feedback