I would like to announce that work has started on creating a replacement system for the modules and plugins database and the themes database.
This new system will be a local Moodle plugin that will be specially designed to meet the needs of our community and contrib developers.
As well as tracking plugins like the current database activities this new system will also track versions of plugins.
Other new features include a trusted review process, awards that can be handed out, recognition of multiple contributors, better tracking of supported Moodle versions for plugin versions, better collection of stats, and the list goes on.
Presently we are in the initial stages and a draft proposal has been created - Development:Modules and plugins replacement proposal
We would greatly appreciate it if anyone who has a few spare moments could take a look at the proposal and provide feedback on it.
Obviously we want to get this right and while the project is in the early stages it is easy to adapt. So please if you spot anything we have missed, or can think of anything you'd like to see in the new system we'd love to know.
The draft looks very comprehensive to me. However, one thing I am missing is a bug reporting feature and issue queue for each plugin. I'd like to have this all under one hood instead of resorting to the forums for it. I like the way Drupal does this, see http://drupal.org/project/moodle for an example.
Just my 2 € cents.
Like now, bug reports relating to contrib code will go in the CONTRIB project in the Moodle bug tracker. For example: http://tracker.moodle.org/browse/CONTRIB/component/10341.
The new Modules and plugins database will just link to that. (I assume.)
Would be nice to se tracker tickets listed in the DB. A great way for users to see if issues are still prevalent and also if development is ongoing. Maybe even a link on the module page to "List a bug" or something similar instead of having these issues entered as comments
Thanks for the feedback, indeed Tim is quite right we will still be using the main tracker and the CONTRIB project to manage bug reports.
I've talked to Martin about this as it would be great to get the new system talking with tracker, and by the sounds of it we should be able to at least pull in the list of issues based upon the component through RSS. We'd need to have a component for every plugin but I don't think that is necessaries a bad thing. Perhaps the one big downside is however that we will be able to only relate to plugins, we won't be able to relate the issues to a version of a plugin.
Sam, there already is a component for each plugin
Not quite all of them have a component - just most of them!
A few random musings....
* User ratings. I'm not sure if this is covered by 'awards'. However, a basic Amazon-style star rating would be useful.
* I'm not sure what you mean by 'Reviews can only be created by privileged users'. Who decides who can review? I can't understand why everybody can't (everybody can post in forums). Maybe the same logos (e.g. particularly helpful Moodller) could be used to indicate the (ahem) "worthyness" of the reviewer rather than imposing actual restrictions.
* I'd be keen to see the ability to display 'top' plugins by methods such as "most downloaded" and "highest rated". Not scientific but I suspect users rely on this sort of thing more than you might expect. It's really about finding ways for new users to find the "must have" plugins out of a vast list.
I think (from discussions with Sam) that your third point is what the 'Set' thing is about. A set might be 'Featured plugins', or it might be a 'Highest rated' set that is populated automatically by Cron.
First up thanks for the feedback, regarding the points you raised:
- We will allow users to rate versions of a plugin and it most likely will be in the form of a star rating . The ability to do so will be granted by a capability and likely all authenticated users will have that capability.
- Awards will only be handed out by a very select number of people and is designed to be for things such as the project being constantly maintained and updated, the code being uber secure, etc, they are a bit like badges for the plugin or plugin version. The actual decision about what awards there will be and who can hand them won't be until further down the track.
- The idea behind having only privileged users write reviews is that we will be end up with trustable reviews that will have been created by someone who is known to be an expert in one or more area's of Moodle development and will hopefully be written in a way that honestly reflects the state of the plugin and perhaps even provides constructive feedback for the contributors. Really we are aiming for thorough reviews that look at the plugin both generally and in regards to specific criteria such as how secure the code if, the usability of the plugin, how well it is maintained, and use of Moodle API's.
- Most downloaded, highest rated, yes fantastic point that one. This is what sets are for (the name is pretty ambiguous unfortunately but is the best we could come up with). The idea behind sets is basically to build collections of plugins that share something in common. They will be things that can be calculated such as most downloaded, and highest rated. They will also be things that can't be calculated but are manually created such as must have plugins, plugin of the week, and top plugins of 2011. Hopefully the system will be flexible enough in the end that we can easily create new sets as we think them up.
I hope that answers some of the questions you have, and again thank you for the feedback!
My main gripe with the current system is the communication with users (which I note is mentioned in the proposal).
Currently, if a user has an issue with a plugin, they might submit CONTRIB issue on the tracker (usually not if they're just a user and don't have a tracker account), post a comment on the database entry (which doesn't alert the maintainer), send a message to the maintainer (in which case the discussion's hidden from users who might have the same problem), post in the plugin's forum (if there is one) or post in the thread where the plugin was initially discussed (if there is one, often this results in the resurrection of a very old thread).
It would be nice if each plugin had a sort of "mini forum" created where discussions like this can take place (alerting the maintainer when a new one is created), and then a tracker issue created if the discussion proves it necessary (perhaps with a nice "Create a tracker issue for this problem" button? ). I've certainly found it frustrating when one of my plugins has a comment saying that it doesn't work/install correctly, but my private discussions with the poster (as I don't want to turn the comments into a discussion thread) revealed that it was down to user error and the plugin works fine.
Perhaps the tracker could provide at least an RSS feed to the plugin to see which bugs have already been reported? And in case there's a new bug a button as suggested by Mark would indeed be great.
Agree with Mark. The vast majority of users look at CONTRIB and throw their hands in the air. Coupled with Sam's suggestion for basic instructions w/each plug-in, and the Amazon-like review/star system, this replacement would be a much more powerful tool.
Thanks for the ideas. Looks like the integration with tracker is a pretty popular topic. The plan presently is to still use the CONTRIB project in the main tracker, and will of course still require people to have an account and log in to create the bug.
I had talked to Martin about this and we decided this was still the way we want bug tracking to occur, however I can certainly see what you are getting at with the points you've made.
First up I really like the idea of having a report bug button, I certainly think we can do this an will make a note of it.
Second in regards to the mini forums on each plugin, I had thought about that a little, however after discussing it with a few people we decided we would use the comments API within Moodle allow authenticated users to post comments. The plan is then to tie that in with the notification improvements within this new system so that when someone posts a comment on a plugin, or plugin version you get a message through the messaging system. Hopefully to further this we will allow users to choose to recieve notifications about any plugin, not just plugins they are a contributor for.
I know that this isn't overly different to the present system however hopefully the notifications will at least keep you up to date what what is going on. I also plan to redesign the comments html for this plugin so that it more prominent and friendlier looking feature.
Does this sound like it would meet your needs or do you think we would still be better to integrate discussions or a mini tracker?
Thanks for your reply!
I certainly agree that keeping all CONTRIB bugs under a tracker project is a good idea.
Your suggestions regarding comments and notifications would certainly be a big improvement, and I also like the idea that's been mentioned about an RSS feed from the tracker to show recent bugs. I haven't played the comments system in 2.0 that much, does it allow some sort of discussion threading? Even if it just allows one level of replies below the initial comment (perhaps that are hidden initially) it would be helpful in this context. I'm just concerned about keeping the comments on the plugin page tidy and useful for users, while still allowing maintainers to respond to issues directly and in public. This mockup might better explain what I'm getting at:
P.S forgot to say thanks for your work on this Sam (and to anyone else involved)!
I agree - communication with users is tricky at the moment.
The most difficult thing for me (as Mark mentions) is that there isn't an RSS feed/email generated when people add comments to plug-ins at the moment, so if they ask questions I have to remember to go and look every now and then.
I like the idea of connection to forum/tracker etc. I don't really care where you think the best place for communication takes place, as long as its consistent, public and it notifies me as the maintainer automatically.
Hi Sam, the document looks excellent. Some ideas.
Who will be able to approve a Plugin? Currently only Helen can I beleive.
We have had a Plugin for a few years now. We are a commercial company and we are very careful with what we wrIte about our Plugin.
But we don't want to have our Plugin pending of approval for a few hours every time we change it. Will certain 'well known people' have the right to approve their own Plugin?
The current design seems to be focused on contributed Plugins developed using a public CVS.
When you install Moodle you can register it. It would be nice to be able to do the same for Plugins.
a tag cloud in the begining would be an excellent way to enter the Plugins page.
Thanks for taking the time to read the proposal and providing feedback.
In regards to approvals there is going to be two ways for a plugin, or version to get approved.
The first is as it currently happens a small number of people who are trusted to approve plugins will head in and mark things approved. Currently this is people like Helen, Anthony, and Michael Blake.
The second method is that users can be given a special capability after which any plugins or versions they create will be automatically approved.
I have no idea who is going to be on this trusted list or who decides, but it will be possible. I suppose the list will be made up of well known, trusted people.
In regards to providing CVS information it is completely optional. Under the current proposal you will be required to upload a file, and optionally you can choose to enter the information about your public versioning system. I haven't replied to Sam Marshall's post yet, he raises some good points + ideas that will likely see the it being changed to 'you either upload a file or provide information about your vcs and a download link'.
As for registering sites there are plans, in the future, probably distant future, to provide a means of installing + updating plugins from your Moodle installation. This will require that plugins + the version being used are tracked and essentially registered although I don't think there are plans to collect and correlate that information from an installation. It would be something that people would have to explicitly turn on.
Finally in regards to the tag cloud, the plan is presently to enable tagging of plugins, however we will still require a plugin to be created in a single category. The category will describe the type of plugin, not what it does. So 1 category, 0..n tags.
As for displaying the tag cloud, I'm sure it will be on the front page of the new system somewhere
Thanks for this, it looks great. I do have some concerns though regarding management.
Specifically, with regard to the OU plugins, we would like to automatically update these based on our own code to ensure they stay in synch with our live code. To achieve that we are looking at automatically building a zipfile from our stable branch code (nightly or on change).
I currently manage about four plugins and it is too much work to do this properly already. With our Moodle 2-based system we would like to release many more plugins (basically everything that isn't directly tied to integration - at least twenty or so plugins).
With the current M&P system, we can achieve this by setting the download link to point to our zip file (wherever that will be). Then it will automatically update each time we apply a bugfix to our live systems.
My main concern is that this new system would appear to mean we have to manually upload a new zip file for each minor version update. This isn't feasible for us. With this approach, we would end up only uploading a new file for major versions, which would mean that users at other sites would miss out on important bugfixes that we are patching to our live server. These are always important fixes and occasionally critical security issues.
Example of currrent approach - this is what I currently do for the plugins. As you can see this is not automated yet either, I have uploaded them to Google Docs. At least it's quite a quick interface...
So in summary, what I'd really like from a new system is either
a) a way so that the link for major version 4 of a particular plugin points to a standard URL which we can change so that we can update it to 4.1, 4.2, etc without ever going to the moodle.org site.
b) some kind of 'pull' system for updating plugins so that we can specify the URL of an xml file which moodle will check periodically, such as the following:
c) (worst case) some kind of 'push' system for plugins so that using a web service token, one of our systems is able to upload a new version when it notices it changes
d) (kind of opt out) a way to add a plugin where the files, versioning are not provided at all within the moodle M&P system and it only handles the community part - description, reviews etc - then a link to the home page for the plugin.
I understand there might not be too many other people who do this sort of thing so you might not be inclined to implement it, but just saying...
Re the rest of it, something that would be cool is if it automatically creates a big Install this plugin on your Moodle system button, which links to a page that tells you how to do everything, like this:
0. Are you sure you want to do this? You should try it on a test server first blah blah blah.
1. Check your Moodle version by going to the admin blah blah blah. You need at least version 2.0.1. [from specific plugin]
2. Download this plugin zip file [link to specific plugin].
3. Extract the zip file and place it in the following folder blah blah blah. The folder should look something like this: [CSS'd-up picture of mod folder including the standard modules and the new folder name from the specific plugin they installed, with arrow pointing to the latter. Or for whatever folder.]
4. Go to the notifications page blah blah blah click upgrade blah blah etc
I'd also like to avoid having to manually zip and upload a new version of my plugins, every time I make a change to them. The current system of being able to submit changes to CVS and have them automatically appear for download the next day is much easier.
On a related note, I don't suppose there is any chance of getting a moodle.org hosted git CONTRIB area set up, with automatic linking from tracker? Since Moodle core moved over to git, CONTRIB commits via CVS no longer show up in tracker (and third-party hosting, such as github, wouldn't allow that linking to take place either).
In regards to manually uploading a zip file check out my reply to Sam's post above.
As for the Moodle hosted git contrib area, I know at one point we looked at the prospect of doing this, however I don't know what the final decision was only that we weren't going to do it straight away.
Perhaps this will catch Martin's eye.
I realize this is a tangent, but: github could not possibly have been easier for me to use to set up my plugin project. Then I provided links to the github project in the current M&P system, and away we went.
Unless a Moodle-hosted git contrib area somehow improves on what github (or any other no-cost online VCS) can do, why bother? I think Sam Marshall's (a)/(b) suggestions get me everything I need to be comfortable continuing to use github for my project without needing to babysit a new M&P entry.
+1 for basically everything Sam Marshall said.
One note: If it comes down to a choice between Sam Marshall's (a) and (b), I would pick (b). At least in the case of the one M&P entry I'm currently working on, you really need to install multiple plugins that work together in order to do anything useful. (I designed the enrolment plugin to work alone, but for now you really want the associated block.) So there is no top-level 'version.php' file, because the project download contains 'moodle/enrol/blah' and 'moodle/blocks/blah'. I guess I could put a pretend version.php file in the top level just for the sake of the M&P system, but the flexibility of the XML file seems quite a bit better.
There's much in Sam's comment that I love.
The move to Git is a fantastic one for helping new developers fork, tweak or patch, and contribute the changes. Many plugins in the current database either have no public repository or no obvious way of accepting patches. Anything we can do to encourage public repositories and easy contributions gets my vote.
Lots of teams will use different systems. I think it's great if we have a simple way of pointing out where the source is, how to get a zip download, where discussion is located, etc. IMO the way the Ruby community does it at Rubygems.org is a winner (e.g. http://rubygems.org/gems/rspec). Most people use github, but you could use any option you like - since github automatically produces downloadable packages, we could just point to the latest one without any need to trigger a special process.
Credibility: stats and voting
I think it'd be great if we had the ability to see downloads (of limited use when many will use Git) and also to submit a quick 'user's 5-star ranking' and a rubric-based assessment about overall quality. The 5-star ranking would tell you whether people love using the module, the larger assessment would help institutions identify whether a module is community-rated as being suitable for installation.
Having a rubric with visible, community-managed criteria (security, performance, etc) would be great. I'd imagine reviews being conducted by Moodle Partners, HQ developers, freelance developers etc.
None of the assessments would be anonymous, and would be explicitly done against a specific version number.
That's probably more than 2c worth ;)
Great work Sam H! - I agree with Sam M - having to upload a "package" file each time you update your git repo seems to break some of the big advantages of people using their own repos - it's much more convenient to be able to link to a download from github (or elsewhere) - it's unlikely I'd remember to "update" the m&p entry each time I make a push into my git repo - and I don't think I should have to. If Moodle still needs to keep a "package" file seperate from the externally hosted repo IMO it should do this in an automated fashion.
To handle versions of interally stored packages - for blocks/modules the script could check the version.php file to see if it has changed since it last looked and if so it could grab the code down again and store the package.
Patches/packages could also use a similar method - using a version.txt or version.php file to signify versions?
..Really looking forward to the ability for full reviews to be added to plugins!
By all means the idea of making creation of new versions as quick, painless, and automatable as possible is certainly an idea worth investigating and one that I would love to find a good solution for.
The current system, you make changes in CVS, the new download pages are produced on a regular basis, and everyone gets the latest version.
With the new system where we are tracking versions properly having a record of each version is important. Reviews, awards, sets etc will all make use of particular versions. It is pretty crucial to providing information that can be trusted and readily availble.
That all said really it only means we need a record for each version in the database.
Presently the proposal requires that you manually create a new version through the system and that you upload a zip of the version.
I completely agree that it could be made quicker and I'd love to do so. Looking through your ideas for how this could be done:
a) Looking up a standard link: strangely enough this could work. Part of getting the zip is that we will extract it and look at version.php so we could probably peice together enough of a version record to get it into the database.
b) The descriptive XML file: This is certainly doable, it would need to contain a link to the file we could curl down, and could optionally contain the other information you can specify for the version such a relese notes and whatever.
c) The webservice: At one point or another I did actually discuss using webservices like this with Martin however we decided against it. This option is a no go.
d) Throw away versioning: This one is definatly out, in order to provide trusted information and access to old versions we need to have the version stored ourselves.
From the options a or b sound good to me, and if I had to choose one I think I would go for option b, but perhaps we can support both? I don't know. I'll see if I can steal some of Martin's time and see what he thinks.
Regarding the Install this plugin button that sounds like a cool idea, and easy enough to implement. I'll make a note of it and see about getting it in.
btw. Thanks for reading over the proposal and giving feedback
We already have the convention that if you are publishing your pugin in a git repository, you call the repository something like moodle-mod_forumng. That, of course, is browsable at some URL somewhere on the web, for example https://github.com/sammarshallou - and we know that version control information will already be in the modules and plugins database.
And, in fact, if you look at the proposal, there is already a field in the local_contrib_vers table vcstag. That is all the information that the modules and plugins database needs to pull the code and build a zip file. And so it should. Perhaps not in the very first release of the system, but very soon afterwards.
Also, you may have ruled out web services in the first version of the database, but please re-consider long term. Anything I (as a plugin publisher) can do by going to the Modules and database system in my web browser, I should be able to automate, and web services are the obvious way to do that. What we are thinking of here is a publish script that extracts the latest changes from mod/forumng in our main development branch in our main OU git repository, copies those changes to the moodle-mod_forumng project, pushes that to a public git server, and then updates the M&P database entry with a new version. It is OK if that is not completely automated at first, but getting it to the point where it is just pushing a single button is a worthwhile and achievable goal.
We haven't really sorted out our plugin deployment locally.
What I'm thinking of as a minimal implementation is a script which builds a zip file (every night or on push) from the /mod/forumng folder of the 'released to live server' branch of our repository. In this world there would be no use of GitHub and no public access to any source repository, just the zip files.
However as Tim says it's possible that this could also be implemented by automatically copying the folder contents into a local clone of a GitHub repository then automatically pushing the changes to GitHub. That would add a bit more work to making the script (which it appears nobody has time to do anyway and make it a bit more complicated to set up our procedures. (Actually not THAT complicated if we start off by getting an organisational github account and defining standard repository names.) This would indeed be better; it wouldn't preserve history in any useful sense but it would give a nice place for people to browse the source.
One other important factor is that I'm proposing to export primarily the live version of our modules (that's the same version in the google docs folder I linked earlier). I don't think it's appropriate to release untested development versions for easy access to other people to accidentally install when they happen to be in a broken state. We need to make sure that the version people are getting is the fully tested one that we have deployed on our live system (plus critical patches) and not some half-baked dev version. Of course, we could provide both versions (which would be easy using the export-to-github approach, just export it twice into two remote branches).
Anyway, we can have this discussion locally, just wanted to say that I think both approaches - the one where somebody provides only a zipfile, and maybe they don't even use a source control system, who knows; and the one where the zipfile is generated by a source control system such as github, which can also be used for browsing the source - ought to be feasible via the M&P database.
Re Sam's response to my comment, thanks I didn't have anything to argue about there. Pulling version out of version.php automatically is a great plan.
Please see if you can use TAGs and not a fixed category tree,
In which, plugins can only be related to one category.
It would be great if it could work in a similar way to the wordpress plugins, where the plugin can either be automatically installed (subject to it being on the right version, etc), or be downloaded and manually installed.
Disagree - doing this means that Moodles webroot would need to be writeable by default - in my opinion this is something we should discourage as much as possible - The security risks this could cause far outweigh the convenience.
The other argument, of course, is that if upgrading is hard then people don't do it, and expose themselves to all kinds of known vulnerabilities in the future. We see this all the time. Better to make upgrading a one-click operation.
I'm still not sold on this - the impression I get is that a massive number of Wordpress sites get hacked even with the ability to do an "easy upgrade" - and having the webroot writeable just seems wrong! - I would expect that it would make Moodle sites a bigger target for hosting of unwanted content.
Dan, there is a compromise position where we try to educate admins to run with wwwroot locked down most of the time (huge screaming notices on the admin notifications page, which explain how to do the lockdown on your OS.)
But then, we accept that when the site is in maintenance mode, people may like to chmod their wwwroot, then use a one-click installer, then chmod back. Of course, if you can use chmod, then you can probably use git pull.
Any one-click installer should be opt-in for the admin. I am sure there will never be a requirement to use it.
And while Martin thinks a one-click installer is a good idea, he has not yet convinced Petr
I don't think the compromise should be to educate admins to allow their webroots to be writeable - even if for a short time during an upgrade - it's highly likely they will forget or not bother to move back to a read-only state.
A compromise could be to allow upgrades of core "lib" style files - and dump them all in the dataroot - we can already come close to doing this using $CFG->libdir
IMO - educating/allowing Admins to have a writable wwwroot opens a can of worms - it may be a can that Moodle wants to eat, but it's still a can of worms
...and to be honest - it's not going to affect me directly all that much - we'll still run our production servers with a read-only wwwroot
As a side note - if the M&P ends up having an "easy install" link which easy download/install directly on your site - these links should only appear on M&P entries that have passed a Security Review - otherwise it will contribute to having more sites running insecure code than we already have - people wanting to install other plugins must/should have to do this manually..... And - it would be great if the a sites environment page checked the M&P database for information about installed plugins that weren't safe and displayed big messages about their status to the admin.
Dan, I love the idea that the Moodle site should check the M&P database for information about installed plug-ins.
One of the things that's nice about Drupal is that it warns you when there's an upgrade that you need to apply. It would be great if Moodle did that too.
But like you I really wouldn't want to see the wwwroot writable. We already spend a lot of time and money keeping openlearn free of spam, and I'd have nightmares if I had to open it up further!
i.e. if it were possible to run a duplicate of a plugin and still keep it in sync with the upstream
I also like the idea of repo's.
Built in would be a core repo of standard modules. Users could enable a Moodle 3rd Party repo maintained throgh Anthony. But also could allow partners to have theor wn repo's with approved code for their clients.
Through these repo's Moodle notifications could also alert to updates for plugins. Not a installer yet, but at least an alert that the code has been updated.
If your familiar, I look at how the Cydia app on the iPhone works as a great example of how this could operate. Of course, if the user is not savy enough to enter a path for an extra repo, chances are they dont have the skills to safely use 3rd party either :D
Just my 2c worth
Agree with your comments about security around wwwroot - how many sites have we rescued from people "just poking around with the code".
One idea we had was to write an installer that required a user to enter FTP/SSH details whenever they were installing a plugin or performing an upgrade and using one of those protocols to install code (IIRC Joomla has this?). The user/pass details would be stored on a session basis, If the user has the details then obviously they can already install or kill everything so we'd be letting them do this in a more controlled way where there would be warning notices about plugins with low security ratings etc.
Just thought dumping here - I'm sure there are a lot of issues to consider around any installer.
Agreed. Security through Obsurity has always been proved not to work!
Tere are ways we could do this without webroot writable. Couldnt a script download the code into a tmp folder in moodledata, then the server do it's own extraction and install.
Or maybe Moodle keeps only core M&P in the current et folders and others can be accessed from a seperated directory structure in a new folder (in moodledata or elsewhere) thus limiting exposure?
Dont think we shoud shut down 1 cick installs purely based on Moodle current way of storing this code. These are possibly changes that could be rolled out in a new point release as a new feature.
Just trying to think outside the box here
I like both these ideas.
Instead of instant 1-click install, we could flag the plugin for cron to upgrade on it's next run, after setting cron to operate under an account with more privileges.
Putting all plugins into a separate directory is a very cool feature of Drupal, which allows very simple upgrades of core code as you just copy the /sites/modules/ directory into the new codebase. It also allows you to see at a glance which modules are core and which are not, so I think it's be very helpful.
+1 for a one click install option.
I agree about all the security issues, but given Wordpress's failure to cause global server meltdown, an option for advanced users to do it can't be that bad, especially given Martin's point about encouraging timely upgrades.
I see no problem adding extra authentication just for that operation as others have mentioned, and the hassle of using FTP, or chmod or whatever would be more than worth it given the time saving, especially when managing lots of sites.
I have issues with users hosting their own code. Links are not updated and fail, Some nasty operators use the process to force signups to build mailing/marketing lists, code that was approved can be replaced with a tainted versio without having to edit the record and therefor notify the DB managers.
This may very well be a pipe dream, but it would be advantagous to have all the code store in the DB (if not directly in GIT for obvious tracking and version control reasons).
Assuming all code writers are capable of setting up and uploading to GIT is a mistake. And as much as the purists here will probably shoot me down for saying, just because they cant use GIT (or CVS, SVN, etc) does not mean they cant contribute useful and well written code.
So I guess I am alluding to a system where a zip of the code MUST be uploaded or a path to a GIT repo added. And then a script that can ither auto add it to GIT (thats the pipe dream part), or the DB managers will upload to GIT on behalf of the user.
Comments, suggestions, flames? ;)
Maybe I'm being a purist but I think that any serious/seasoned developer would already be using a SCM/VCS of some description. It's a basic necessity of the job and it's not hard to learn. Places like github make it very easy to manage projects and have some great instructions and tutorials.
That is not to say that someone who isn't at that level can't contribute code, but I think there are already avenues for doing that - eg posting to a forum, tracker etc.
Regarding tainted code in the linked versions, two thoughts:
1. Reviewers would soon find out and perhaps they just blacklist that user/plugin - maybe a policy should be agreed to before an new entry is added to the database?
2. I'm sure it would be possible to automate a check that the link does in fact download some pluggable code;
Nice work, Sam. I remember floating this idea a few years ago, so nice to see it's finally got some legs! I like the mock ups and reckon it will be an improvement on the current plugins database.
a couple things - will the current plugins database ie comments, ratings etc be migrated to new system? also, is it fair to say there won't be any scope for third-party developers to monetize their contributions as 'commercial' extensions via the proposed system?
Joomla & Sugar extension sites might be worth a look for some additional ideas. I'll also include a reference to the initial discussion and tracker issue.
First up a massive thank you to all who have taken the time to read over the proposal and provide feedback + ideas. There is a lot of stuff that has come out of what's being said that will make its way into this new system.
Tomorrow I am heading back to New Zealand for a month to get married and won't be back at HQ until 8th March.However before I head off I would like to share with you all how things are going! Martin's had me working madly on this for the past week and I think I've made fair process to getting the basic functionality of the plugin developed.
I've attached several screenshots to this forum post that illustrate the main screens of this new system. Again please any feedback is more than welcome although I won't likely get a chance to reply until I am back. (Right click and view image to see full sized images)
For those who are interested in the code you can find it at the moodle HQ git hub repository https://github.com/moodlehq/moodle-local_contrib Please note that this plugin is still in its initial development, things aren't secured yet and bits of it may be broken.
The current state of things is that much of the core functionality is now working in one form of another. However areas that require Moodle core modification and fixing such as tags, comments, and ratings aren't implemented yet. I will be tackling those when I am back now.
Cheers and again thanks for all the thought!
great work Sam - looks really promising! - flick me an e-mail if you make it to chch and want to come over for lunch/dinner/coffee with your new Wife! - hope the wedding plans go well!
thank you for your work and for the interesting screenshot, and of course our best wishes for your marriage . I tried to gather as many information about this thread, however i still have some doubt (apologize if I 'm missing something already discussed):
- writable wwwroot: as Dan pointed out, it is a concern we should take care of
- as far as I can understand it is a web interface. I'm a little concerned about the fact an Admin can download and install plugins at will, easily making a system out of control
- Moodle 2.0 has a cli upgrade script very useful to automate upgrade processes of sites using a local git/cvs common repository. Would the plugin still have a git/cvs repo where the plugin can be downloaded at their proper version ?
are there any news about this?
The last post is from 12th february
Juan - Development:Modules_and_plugins_replacement_proposal gives the direction that things are taking and it remains a work in progress (on hold until Sam gets back) but as mentioned you can check the current status of things at MDLSITE-571 or if you are interested in what is happening with the code you can checkout https://github.com/moodlehq/moodle-local_contrib. I look forward to seeing things come together over the next several months. Your comments in the tracker or on the Moodle Docs page would be very helpful. Peace - Anthony