For my enrolment plugin I'm using a table in the Moodle DB to store the mappings. I originally created this table manually, then used XMLDB within moodle to create an install.xml file for my plugin. Through some...clumsy coding on my part I accidentally deleted the admin user from my site. This lead to many...odd...behaviors. So, I created a new schema (database) on the server and then renamed config.php and re-ran the Moodle installation. All is now working much better...EXCEPT that Moodle seems to be ignoring the install.xml for my enrolment plugin and is, therefore, NOT creating the table it needs, causing it to fail to work. I understand this should be automatically setup when the admin logs in, but it is not happening.
Basic question, then, how do I get moodle to actually USE my install.xml file?
I finally tracked this down...
It seems that, to install a plugin I have to manually enter the URL for a part of moodle that is DEPRECATED!? >:( Seems Moodle refused to process my install.xml until I visited https://mymoodlesite/admin/index.php , which I only got to by typing it in MANUALLY. Of course, I now notice that it is helpfully labeled as 'Notifications' (what on earth!?) on the front page of the site when logged in as the administrator.
I like Moodle, but this needs to be documented or fixed in some way. I clicked pretty much EVERY configuration/setup/security/etc. link in the "Site Administration" box. I only figured out the 'Notifications' bit after applying find and grep to the source tree to see where the upgrade_plugins function was actually being called from. Even the instructions I found on this website for installing plugins still refer to the "Administration page" that disappeared at least two versions back. (I have a 1.6 install and a 1.8 install, I can't verify whether it exists in 1.7)
It seems that, to install a plugin I have to manually enter the URL for a part of moodle that is DEPRECATED!? >:( Seems Moodle refused to process my install.xml until I visited https://mymoodlesite/admin/index.php , which I only got to by typing it in MANUALLY. Of course, I now notice that it is helpfully labeled as 'Notifications' (what on earth!?) on the front page of the site when logged in as the administrator.
I like Moodle, but this needs to be documented or fixed in some way. I clicked pretty much EVERY configuration/setup/security/etc. link in the "Site Administration" box. I only figured out the 'Notifications' bit after applying find and grep to the source tree to see where the upgrade_plugins function was actually being called from. Even the instructions I found on this website for installing plugins still refer to the "Administration page" that disappeared at least two versions back. (I have a 1.6 install and a 1.8 install, I can't verify whether it exists in 1.7)
This made me laugh (sorry) but you are so right - 'notifications' is just a weird name that doesn't mean anything, and unless you actually know 'oh yeah, the admin page that you use to update things, that's labelled as notifications' you would surely never think to click on it. I assume this is covered in the documentation but most people follow the RTFMOAEEOPUTAIDRTTPOTUS* principle.
Perhaps it should be renamed to 'info and upgrades', if that will fit. It could even include a link to the Moodle plugins repository, and help about installing plugins.
--sam
* Read the 'ing manual only after exhausting every other possibility up to and including direct request to the President of the United States.**
** What, me? Make up completely new abbreviations just to confuse? NEVER.
Perhaps it should be renamed to 'info and upgrades', if that will fit. It could even include a link to the Moodle plugins repository, and help about installing plugins.
--sam
* Read the 'ing manual only after exhausting every other possibility up to and including direct request to the President of the United States.**
** What, me? Make up completely new abbreviations just to confuse? NEVER.
I'm glad I'm not alone...I /DID/ try to find it on the Moodle website, as mentioned above, and it referenced the admin page.
I would suggest, though I lack the time to implement such a thing, that it might be nice to have a more centralized plugin management system.
I think it would help people form a more accurate mental model of plugin installation and removal if there were a better defined, explicit interface for installing and uninstalling plugins, modules, blocks, etc.
Given that each plugin is configured within its category (auth plugins are configured in authentication, enrolment in enrolment, etc.) this might just need to be a simplified add/remove plugins (blocks, etc.) page listing installed plugins (blocks, etc.), perhaps by category, their current status, and their current version, with some kind of add/remove plugin option from the same locale. (Imagine something like "Add/Remove" programs on Windows, but for Moodle plugins instead)
Even something as simple as this
Made accessible from the System Administration block would be nice.
I would suggest, though I lack the time to implement such a thing, that it might be nice to have a more centralized plugin management system.
I think it would help people form a more accurate mental model of plugin installation and removal if there were a better defined, explicit interface for installing and uninstalling plugins, modules, blocks, etc.
Given that each plugin is configured within its category (auth plugins are configured in authentication, enrolment in enrolment, etc.) this might just need to be a simplified add/remove plugins (blocks, etc.) page listing installed plugins (blocks, etc.), perhaps by category, their current status, and their current version, with some kind of add/remove plugin option from the same locale. (Imagine something like "Add/Remove" programs on Windows, but for Moodle plugins instead)
Even something as simple as this
| Action | Category | Type | Name | Installed Version |
| Remove Upgrade | Enrolment | Plugin | Cedar | 2008031300 |
| Install New | ||||
Made accessible from the System Administration block would be nice.
> I think it would help people form a more accurate mental model of plugin installation and removal if there were a better defined, explicit interface for installing and uninstalling plugins, modules, blocks, etc.
I agree this is a good idea and have set up a Tracker ticket (http://tracker.moodle.org/browse/MDL-13941) which refers back to this discussion.
During the upgrade to v1.9, there is a plugins table that lists all the standard and non-standard plugins on the system. Perhaps this table could be extended to include install/upgrade/uninstall links, then accessible via a link in the Admin tools.
I agree this is a good idea and have set up a Tracker ticket (http://tracker.moodle.org/browse/MDL-13941) which refers back to this discussion.
During the upgrade to v1.9, there is a plugins table that lists all the standard and non-standard plugins on the system. Perhaps this table could be extended to include install/upgrade/uninstall links, then accessible via a link in the Admin tools.
Neat! Thanks. Maybe this can save some confusion for others in the future. It might also help people know what is actually IN their Moodle instance. I've found some items in the source tree whose existence is not, to me, readily apparent from the web interface.
Thanks,
Jeremy
Thanks,
Jeremy
Well, normally you don't have to manually go there - if your plugin has a new version number then just visiting the home page as admin will redirect you to this page to make the upgrade happen.
But I agree it's a bit odd when the automatic upgrade doesn't happen. A rename of that page would be a good idea.
But I agree it's a bit odd when the automatic upgrade doesn't happen. A rename of that page would be a good idea.
My plugin couldn't have a "new" version number, since that was he first time it was being installed. Moodle seemed to have ignored its install.xml completely. Also, given the following:
done within the moodle base directly:
find . -type f -exec grep -He "upgrade_plugins(" "{}" \;
./admin/index.php: upgrade_plugins('qtype', 'question/type', "$CFG->wwwroot/$CFG->admin/index.php"); // Return here afterwards
./admin/index.php: upgrade_plugins('enrol', 'enrol', "$CFG->wwwroot/$CFG->admin/index.php"); // Return here afterwards
./admin/index.php: upgrade_plugins('format','course/format',"$CFG->wwwroot/$CFG->admin/index.php");
./lib/adminlib.php:function upgrade_plugins($type, $dir, $return) {
I don't see how, exactly, moodle would be running any plugin upgrades outside of that page. (unless there is a differently named function that does the same thing)
[EDIT]
Okay, I see what you're saying...so why didn't Moodle re-direct me on the initial installation of my plugin?
done within the moodle base directly:
find . -type f -exec grep -He "upgrade_plugins(" "{}" \;
./admin/index.php: upgrade_plugins('qtype', 'question/type', "$CFG->wwwroot/$CFG->admin/index.php"); // Return here afterwards
./admin/index.php: upgrade_plugins('enrol', 'enrol', "$CFG->wwwroot/$CFG->admin/index.php"); // Return here afterwards
./admin/index.php: upgrade_plugins('format','course/format',"$CFG->wwwroot/$CFG->admin/index.php");
./lib/adminlib.php:function upgrade_plugins($type, $dir, $return) {
I don't see how, exactly, moodle would be running any plugin upgrades outside of that page. (unless there is a differently named function that does the same thing)
[EDIT]
Okay, I see what you're saying...so why didn't Moodle re-direct me on the initial installation of my plugin?