Moodle Plugins now live!

Moodle Plugins now live!

by Martin Dougiamas -
Number of replies: 44
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi all,

I'm really happy to announce that the new Moodle Plugins database 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 database.

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.

Cheers,
Martin

Average of ratings: Useful (4)
In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

It's looking like a great improvement over the old database, but I have a couple of questions:

  1. 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?
  2. 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)?
In reply to Davo Smith

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi, Davo.

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.

Average of ratings: Useful (1)
In reply to Marina Glancy

Re: Moodle Plugins now live!

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Thanks for the clarification. Would it also be possible to add a 'discussion' link, like with the old database, or is discussion expected to take place in the comments instead?
In reply to Davo Smith

Re: Moodle Plugins now live!

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Davo,

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.

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I have found with my plugins that the vast majority of discussion about new features or bugs happens in the Moodle.org forum post linked to from the discussion link. Comments are limited by not being threaded and getting less'passing traffic' than the contrib forum (but I'm pleased to note that they are no longer hidden by default and that an RSS feed is now available). Tracker is great, but not all Moodle.org users have tracker accounts, or know how to use it. Again, there is less 'passing traffic', so others are less likely to comment on suggestions made (unless they happen to have the exact same thought about improvements). For example, I doubt I'd be writing this now, if the new features of the plugin database had only been announced in tracker. As it is, I've set the website link to point at the discussion thread for my plugins, but I thought it would be clearer if it said 'discussion'.
Average of ratings: Useful (1)
In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Itamar Tzadok -

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. smile

In reply to Itamar Tzadok

Re: Moodle Plugins now live!

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

I've fixed this now so that most developers can add new versions of the plugin without needing approval.

I reserve the right to force approval for certain developers if it becomes a problem (we can do this using roles).

Average of ratings: Useful (1)
In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

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?

Joseph

In reply to Joseph Rézeau

Re: Moodle Plugins now live!

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

Hi Joseph,

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.  smile

I've improved the text too.

Cheers!

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Martin,

This is to confirm that the new plugins interface looks OK now. I probably had extra permissions allocated from the Facilitators Corner group.

The new interface looks quite nice, by the way. Well-done!

Joseph

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Mark Ward -

Looks like a big improvement, many thanks!

In reply to Mark Ward

Απάντηση: Re: Moodle Plugins now live!

by Andreas Panagiotopoulos -

Many many thanks for your efforts!!!

I can't imagine my moodle work without the community...

 

Andreas P.

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Matt Gibson -

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?

  1. Should I have different repositories for 1.9 and 2.0 or just different branches?
  2. How to manage the issues - moodle tracker or github tracker?
  3. How to make sure commits to github are linked to any relevant moodle tracker issues as used to happen in CVS?
In reply to Matt Gibson

Re: Moodle Plugins now live!

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Matt,

As someone who made the move from CVS to GIT some time ago, I would say that the learning curve is very steep, but it's worth the effort!

Q1 : use branches, not different repositories

Q2 and Q3 are very good questions, which I ask myself.

Joseph

In reply to Joseph Rézeau

Re: Moodle Plugins now live!

by Matt Gibson -

Thanks Joseph.

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?

In reply to Matt Gibson

Versions, branches etc.

by Henning Bostelmann -
Picture of Core developers Picture of Plugin developers

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.

In reply to Henning Bostelmann

Re: Versions, branches etc.

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

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.

Average of ratings: Useful (2)
In reply to Martin Dougiamas

Re: Versions, branches etc.

by Itamar Tzadok -

but this database is 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. smile

Average of ratings: Useful (1)
In reply to Itamar Tzadok

Re: Versions, branches etc.

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Whilst I think I agree with the general gist of Itamar's plea for a constructive view of the plugins repository, I do not quite see the practical implications.

Joseph

In reply to Itamar Tzadok

Re: Versions, branches etc.

by Martin Dougiamas -
Picture of Core developers Picture of Documentation writers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

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?

Average of ratings: Useful (1)
In reply to Martin Dougiamas

Re: Versions, branches etc.

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

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:

  1. It was created as so called "Ex post facto law", forcing validation on the Moodle plugins for Moodle versions existed before it was created;
  2. 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.
  3. 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.

In reply to Oleg Sychev

Re: Versions, branches etc.

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

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.

Those wondering who am I and what I've written for Moodle could look at http://docs.moodle.org/22/en/Preg_question_type and MDL-29095 where some of it's users give comments.

In reply to Oleg Sychev

Re: Versions, branches etc.

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

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.

In reply to Oleg Sychev

Re: Versions, branches etc.

by Anthony Borrow -
Picture of Core developers Picture of Plugin developers Picture of Testers

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

In reply to Anthony Borrow

Re: Versions, branches etc.

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

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...

In reply to Henning Bostelmann

Re: Versions, branches etc.

by Hubert Chathi -
Github provides a "Download" link for each repository, where you can download a zip file of your code. You can select which branch you want to download. This should make it easy to get code from github into the Plugins database. Command-line fans can use "git archive".
In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Paul Nicholls -

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...

Cheers,
Paul

Average of ratings: Useful (1)
In reply to Paul Nicholls

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

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.

 

 

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Tim Williams -
Picture of Plugin developers
Will the automatic plugin update system allow for the use of third party plugin repositories, in the same way that the Linux package mangers (yum/apt-get/urpmi etc) are able to pick up packages from multiple sources, or will it be tied to moodle.org as a single source? Use of a third party repository would obviously be at your own risk.

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.
In reply to Tim Williams

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

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.

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Tim Williams -
Picture of Plugin developers
I'm encountering a problem trying to make my first addition to the plugins database. I'm trying to upload a Moodle 1.x block, but the registration pages won't let me proceed because there is no version.php file. Given that Moodle 1.x doesn't use version.php, does this mean that I now have to add a redundant version.php file to all my Moodle 1.x blocks or can this requirement be removed for blocks which are only for Moodle 1.x ?
In reply to Tim Williams

Re: Moodle Plugins now live!

by Tim Williams -
Picture of Plugin developers
Additional: I'm encountering a similar problem with Moodle 1.x Activity modules, the plugin database is refusing to allow me to proceed if $string['pluginname'] is missing, even though I didn't think this was required by Moodle 1.x.
In reply to Tim Williams

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi Tim,

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 

Marina

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

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?

mike

(edit - Solved my own problem. At the bottom right, under the "Settings" block, there is an "add new version" link).

In reply to Mike Churchward

Re: Moodle Plugins now live!

by Joseph Rézeau -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Mike,

I had exactly the same problem you describe. Surely that "add new version" link is well-hidden in the "Settings" block, as far away as possible from where one would look for it. sad

Joseph

In reply to Joseph Rézeau

Re: Moodle Plugins now live!

by Itamar Tzadok -

I had the same problem. big grin It's not (or not only) that the add new version link is well hidden but rather that the UI is inconsistent since you don't need that link for adding the first new version. smile

In reply to Itamar Tzadok

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Isn't it the same way you edit the course, or enroll students?

But if the location of the links continues to cause confusions we may create an issue of moving the links to the more visible location

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Samuli Karevaara -

Hello, looks sweet, great! I've been away, I mean really, so excuse me for a dummy question: is that done with some standard Moodle activity module or is it custom code all the way?

In reply to Samuli Karevaara

Re: Moodle Plugins now live!

by Gareth J Barnard -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers

From what I remember of iMoot 2011 it is custom code.

Plus can there be a way of deleting old versions / reuploading a version if a 'silly' mistake is spotted that is annoying but does not require a new version?

Cheers,

Gareth

In reply to Samuli Karevaara

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

This is a local plugin, without any hacks in core. It has it's own DB tables for storing plugins/versions information. There is an apache redirection, the full path would be /local/plugins/ and all links inside plugin are also changed.

In reply to Martin Dougiamas

Re: Moodle Plugins now live!

by Greg J Preece -

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. wink (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.

Average of ratings: Useful (1)
In reply to Greg J Preece

Re: Moodle Plugins now live!

by Marina Glancy -
Picture of Core developers Picture of Moodle HQ Picture of Moodle Workplace team Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers Picture of Testers

Hi Greg,

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

Marina

Average of ratings: Useful (1)