After an email discussion with Petr and Mike Churchwood, I think we need to come up with a general consensus about how to handle versioning for modules in contrib (and other things too, I guess).
I would say that contrib mods should follow the same branching strategy that the main distribution does, and the modules available for download on download.moodle.org should reflect this.
Petr also points out that download.moodle.org should probably not have the standard modules available for download, as it can lead to version mismatch and others. If they're part of the main distribution, why are they needed on the download page?
Any developer ideas about this?
This was raised because of the need to differentiate contrib versioning between 1.5 and 1.6 because of the backup refactor I've been doing, but the switch to unicode is going to raise this as well. And probably other things too.
I made contrib/data module and it should be removed because there is different module for standard 1.6 with the same name.
Teemu
Teemu
Hi,
Is there a definitive list of all the contrib modules together with version numbers, a description of what they do and any caveats for beginners?
If not, what would it take to assemble this?
Craig.
Is there a definitive list of all the contrib modules together with version numbers, a description of what they do and any caveats for beginners?
If not, what would it take to assemble this?
Craig.
Hi Craig,
There is not yet a list of all contrib modules with descriptions, although there are plans for a repository solution for all contrib code. In the meantime, you may browse cvs: moodle/contrib (version.php should contain the module version and required Moodle version plus README.txt should contain a description) as well as the Activity modules forum.
There is not yet a list of all contrib modules with descriptions, although there are plans for a repository solution for all contrib code. In the meantime, you may browse cvs: moodle/contrib (version.php should contain the module version and required Moodle version plus README.txt should contain a description) as well as the Activity modules forum.
I just updated a December 3, 2005 CVS installation of Moodle (and the contrib) with (Moodle 1.5.3+ MOODLE_15_STABLE). The CVS install proceeded as usual.
After attempting to access moodle/admin, the following error appeared:
Versionmismatch: authorize can't downgrade 2005071602 -> 2005071600 !
The site seems to be functioning properly in most respects, but I cannot access the admin page.
This may be the wrong area to post this, but since you are talking about version mismatches, perhaps you could point me in the right direction.
I found earlier advice on moodle.org to delete enrol/authorize, but will await suggestions.
After attempting to access moodle/admin, the following error appeared:
Versionmismatch: authorize can't downgrade 2005071602 -> 2005071600 !
The site seems to be functioning properly in most respects, but I cannot access the admin page.
This may be the wrong area to post this, but since you are talking about version mismatches, perhaps you could point me in the right direction.
I found earlier advice on moodle.org to delete enrol/authorize, but will await suggestions.
The error is telling you that your existing authorize plugin is in fact newer than the one you are trying to install, and it refuses to downgrade (downgrading is not supported in Moodle).
Your only choice is to replace enrol/authorize with a version equal to or newer than the one you had before the update.
Saludos. Iñaki.
Your only choice is to replace enrol/authorize with a version equal to or newer than the one you had before the update.
Saludos. Iñaki.
Download Latest Stable Branch (Moodle 1.5.3 +), not latest release.
HttpS is required in version 2005071602.
if ($oldversion < 2005071602) {
notify("If you are using the authorize.net enrolment plugin for credit card
handling, please ensure that you have turned loginhttps ON in Admin >> Variables >> Security.");
}
The thread title seems appropriate, but I'm asking a different question. I've changed a table used by the contrib/portfolio module, and I want to implement an easy upgrade path. I already have (useless, I believe) version.php files in the portfolio, access_control, and filter module directories, but there is (AFAICT) no place in the database for these versions to be stored.
mdl_modules would seem to be the appropriate table, but I believe that inserting rows there will cause problems because none of this stuff lives under the mod/ directory.
How is my contrib module supposed to handle versioning for upgrading?
mdl_modules would seem to be the appropriate table, but I believe that inserting rows there will cause problems because none of this stuff lives under the mod/ directory.
How is my contrib module supposed to handle versioning for upgrading?
Hi Matt,
modules upgrade is handled directly by Moodle Core, i.e. you don't need to modify the mdl_modules (nor other core table) from your module at all.
All you need to do is:
- Modify your module/db/*.sql files to the new, latest DB structure. They'll be used in new installs.
- Modify your module/db/*.php files to upgrade the previous DB structure to the new one (alter tables, modify fields... and any php code you need to upgrade your module. Note that you must put all those upgrade code inside one:
(where XXXXXXXXXX is the NEW version that you will update in your module version.php file!)
Once finished if you go to the admin page, Moodle automatically will detect if the module version has changed by comparison with the previous version stored in the mdl_modules (automatically too). If so, it'll execute the module/db/*.php script, so your upgrade operations will be performed, and finally, the new version will be saved in the mdl_modules (automatically) table for future references.
Finally, I recommend you to take a quick look to other modules db scripts to see how they are performing such upgrade db operations. It's really simple and central!
Ciao
modules upgrade is handled directly by Moodle Core, i.e. you don't need to modify the mdl_modules (nor other core table) from your module at all.
All you need to do is:
- Modify your module/db/*.sql files to the new, latest DB structure. They'll be used in new installs.
- Modify your module/db/*.php files to upgrade the previous DB structure to the new one (alter tables, modify fields... and any php code you need to upgrade your module. Note that you must put all those upgrade code inside one:
if ($oldversion < XXXXXXXXXX) {
///
/// Your code here
///
} (where XXXXXXXXXX is the NEW version that you will update in your module version.php file!)
Once finished if you go to the admin page, Moodle automatically will detect if the module version has changed by comparison with the previous version stored in the mdl_modules (automatically too). If so, it'll execute the module/db/*.php script, so your upgrade operations will be performed, and finally, the new version will be saved in the mdl_modules (automatically) table for future references.
Finally, I recommend you to take a quick look to other modules db scripts to see how they are performing such upgrade db operations. It's really simple and central!
Ciao
Ahhh - we've hit on something I should definitely not have left ambiguous previously. My module is NOT an activity module, so it doesn't even belong in the modules table (AFAICT). I also see no way that installation or upgrading are handled automatically at all, and I don't know what word to use other than "module", because it is a module even if it's not an activity module.
I currently have routines called "module_installed", "module_install", and "module_upgrade" that are smart, so if you go to http://moodle/module/, index.php checks module_installed() and module_upgrade('check'), and redirects you to http://moodle/module/install.php, which calls module_install() and module_upgrade('process') appropriately. (The installation instructions tell you to go to http://moodle/module/install.php right away.)
If there's an automated way to deal with this, I'm all ears to hear it, and I'm sorry I've missed figuring out what it is!
So my problem is that module_upgrade() can only check table metadata to figure out what version it's replacing. I.e., for the only upgrade I've yet had to do, it checks for the existence of the column I added, and if it doesn't exist, it alters the table appropriately. If there were someplace I could stick a version number in the DB, it would make things quite a bit cleaner.
OTOH, having a regular, automated way to handle this would just be peachy and I'm excited to know if there is one and what it is.
(It hasn't been obvious to me. 
)
I currently have routines called "module_installed", "module_install", and "module_upgrade" that are smart, so if you go to http://moodle/module/, index.php checks module_installed() and module_upgrade('check'), and redirects you to http://moodle/module/install.php, which calls module_install() and module_upgrade('process') appropriately. (The installation instructions tell you to go to http://moodle/module/install.php right away.)
If there's an automated way to deal with this, I'm all ears to hear it, and I'm sorry I've missed figuring out what it is!
So my problem is that module_upgrade() can only check table metadata to figure out what version it's replacing. I.e., for the only upgrade I've yet had to do, it checks for the existence of the column I added, and if it doesn't exist, it alters the table appropriately. If there were someplace I could stick a version number in the DB, it would make things quite a bit cleaner.
OTOH, having a regular, automated way to handle this would just be peachy and I'm excited to know if there is one and what it is.
(It hasn't been obvious to me. )
A regular, automated way to install and upgrade code placed in arbitrary directories is not that simple
Could your code have been better made as an activity module, or even as a block?
Could your code have been better made as an activity module, or even as a block?
Heh - of course it's not simple. 
OTOH, would it be too hard to have a DB table with 'name', 'dir', and 'version' fields that checks the given dir for a regular directory tree (such as a 'db' directory with files like 'mysql.sql', 'postgres7.sql', and 'upgrade.php') and then behaves roughly like the activity modules code already does? Then the installation process for each non-activity module could just consist of adding a row to that table, and the Moodle core could do the rest.
In fact, this could be done by adding a couple fields to the existing modules table, one of which would distinguish between types of modules (activity v. non-activity, for now).
Just an idea. My main concern was to make sure I wasn't failing to use the proper upgrade mechanisms, if there were any.
There's something to the idea that my module could be a block, because the portfolio module does have a block, and the rest of the code could be put under there... but no, because you still want to be able to go to http://yourmoodle.com/portfolios and see stuff...it's just not the right way to do it.
And besides, the module I was upgrading was the access_control module, which certainly shouldn't have a block or be an activity module.
OTOH, would it be too hard to have a DB table with 'name', 'dir', and 'version' fields that checks the given dir for a regular directory tree (such as a 'db' directory with files like 'mysql.sql', 'postgres7.sql', and 'upgrade.php') and then behaves roughly like the activity modules code already does? Then the installation process for each non-activity module could just consist of adding a row to that table, and the Moodle core could do the rest.
In fact, this could be done by adding a couple fields to the existing modules table, one of which would distinguish between types of modules (activity v. non-activity, for now).
Just an idea. My main concern was to make sure I wasn't failing to use the proper upgrade mechanisms, if there were any.
There's something to the idea that my module could be a block, because the portfolio module does have a block, and the rest of the code could be put under there... but no, because you still want to be able to go to http://yourmoodle.com/portfolios and see stuff...it's just not the right way to do it.
And besides, the module I was upgrading was the access_control module, which certainly shouldn't have a block or be an activity module.
My module is NOT an activity module
If you put your module under ...moodle/mod/something, as far as the upgrade routines concern, it is an activity module
So if you put it there, you can (and should) use the same mechanisms activity modules use to handle installations/upgrades (the ones Eloy describes in his previous post).
Saludos. Iñaki.
Right, but (though I haven't checked this to be sure) I'm afraid my module would then show up when you want to add an activity to a course, and that's completely inappropriate for my module. Besides - my module just isn't an activity module, so it shouldn't sit under that activity modules directory just to take advantage of the upgrade mechanism.