how to watch for modules/themes being enabled
Hi, I am in the process of implementing autolocale module, as you might already know (by reading the development list). This module now nicely imports PO files in install time and can import PO files later for all enabled components (modules/themes) with an optional database cleanup. The next (and for basic operation the last) step is to automatically import PO files for modules/themes enabled on the admin interface. I have tried to look into Drupal HEAD source to quickly solve this issue, but there was no immediate help. The drupal_install_modules() function seemed to be an inviting place, since it knows what modules are being installed the first time. Also drupal_enable() is called for modules previously disabled but being enabled again. None of these "call out" with a hook to inform possible evesdropping modules that a new module is installed or a previously disabled module is being enabled again. My autolocale would however would love to get informed. I also looked into themes, and found that the logic enabling themes is in system_themes_submit(). Interesting fact that the block initialization is wired in, because block module cannot watch for a theme being enabled (lines 1198-1201): "If theme status is being set to 1 from 0, initialize block data for this theme if necessary." After all it seems that my only option is to look for the module/theme list form appearing on the admin screen and alter the form to hook my module to the submit action. When the form is submitted, do the same checks the system.module does to identify installed/enabled/disabled modules/themes, so I know what autolocale should do. Maybe it is not too late to stuff a few module_invoke_all() calls to the proper places so module/theme changes are advertised for modules to watch for. If it is too late, I would be very interested if others faced the same problem and how did they solved it. Gabor
On 12/27/06, Gabor Hojtsy <gabor@hojtsy.hu> wrote:
Maybe it is not too late to stuff a few module_invoke_all() calls to the proper places so module/theme changes are advertised for modules to watch for. If it is too late, I would be very interested if others faced the same problem and how did they solved it.
I think having a module_invoke_all() when a module/theme is enabled/disabled is a very good idea. Examples are: sites with multiple admins can have an email send to a mailing list to inform them of site changes. But with the code freeze, it may be too late to do it for 5.0. Although it would only be Gabor's code that would be using it. Gabory, if it does not make it to 5.0, simply create a few patches and bundle them with your module. Hopefully these very same patches would go in my the time it is 6.0.
Gabor Hojtsy wrote:
I am in the process of implementing autolocale module, as you might already know (by reading the development list). This module now nicely imports PO files in install time and can import PO files later for all enabled components (modules/themes) with an optional database cleanup.
The next (and for basic operation the last) step is to automatically import PO files for modules/themes enabled on the admin interface.
I have looked into the module/theme handling code, found two bugs which I fixed, and introduced the new hook_system_notify(). I would very welcome every reviewer who comes around at this time of the year (instead of preparing for the new year's eve parties, which I am lucky enough to get done by someone else :). http://drupal.org/node/105937 This would be a crucial step for localized install profiles in Drupal 5, so I would like to get this in. Please review! Gabor
I want to announce a new Developer Module named "coder" that assists with code review and version upgrade. http://drupal.org/project/coder http://cvs.drupal.org/viewcvs/drupal/contributions/modules/coder/ The module supports the following built-in reviews: * Drupal Coding Standards - http://drupal.org/node/318 * Handle text in a secure fashion - http://drupal.org/node/28984 * Converting 4.7.x modules to 5.x - http://drupal.org/node/64279 * Converting 4.6.x modules to 4.7.x - http://drupal.org/node/22218 The module also supports a plug-in extensible hook system so contributed modules can define additional review standards. For example, if your company has it's additional/different coding standards, you can write your own review rules and enable them. The current CVS head version works in both 4.7 and 5. I'm hoping to add better security checking, using some tokenization and parsing. If you have some ideas, then collaboration/contribution/help is welcome. Doug Green 904-583-3342 www.civicactions.com www.douggreenconsulting.com Changing the world one node at a time!
I want to announce a new Developer Module named "version2" that assists with keeping contributed modules up to date and summarizing their upgrade availability. If you install this module on a 4.7 site, you can quickly determine if you are ready for the 5.0 upgrade based on the availability of 5.0 modules. http://drupal.org/project/version2 I believe that it works, but it is brand spanking new (I wrote it last night and today) and should be considered beta quality. But as we are in the middle of an upgrade push, I wanted to make it available sooner rather than later. Version2 reads the current version information of enabled contributed modules from CVS/Tag, the CVS $Id$ string, and from the new .info files. Using cron, it gets the current version information from cvs.drupal.org to determine if your there are both minor or major upgrades available; update checks are currently limited to once per day. Version2 displays this information on a single page and creates watchdog events when an upgrade is available. To quickly determine your contrib module upgrade availability for the next major release, install version2 on your current site and look for links in the cvstag column. These are links to the new release download on cvs.drupal.org. If most/all of your contrib modules are available, then it's time to upgrade your site! Doug Green 904-583-3342 www.civicactions.com www.douggreenconsulting.com Changing the world one node at a time!
Good work. I saw the commits in CVS, and wondered "what the heck is version 2"? Can you please consider renaming it a more descriptive name? Something like contrib status, upgradability status, or the like? On 1/2/07, Doug Green <douggreen@douggreenconsulting.com> wrote:
I want to announce a new Developer Module named "version2" that assists with keeping contributed modules up to date and summarizing their upgrade availability. If you install this module on a 4.7 site, you can quickly determine if you are ready for the 5.0 upgrade based on the availability of 5.0 modules.
http://drupal.org/project/version2
I believe that it works, but it is brand spanking new (I wrote it last night and today) and should be considered beta quality. But as we are in the middle of an upgrade push, I wanted to make it available sooner rather than later.
Version2 reads the current version information of enabled contributed modules from CVS/Tag, the CVS $Id$ string, and from the new .info files. Using cron, it gets the current version information from cvs.drupal.org to determine if your there are both minor or major upgrades available; update checks are currently limited to once per day. Version2 displays this information on a single page and creates watchdog events when an upgrade is available.
To quickly determine your contrib module upgrade availability for the next major release, install version2 on your current site and look for links in the cvstag column. These are links to the new release download on cvs.drupal.org. If most/all of your contrib modules are available, then it's time to upgrade your site!
Doug Green 904-583-3342 www.civicactions.com www.douggreenconsulting.com
Changing the world one node at a time!
On Jan 2, 2007, at 4:32 PM, Khalid B wrote:
Can you please consider renaming it a more descriptive name? Something like contrib status, upgradability status, or the like?
yes, please! down with "foo2" modules... aside from that, i'm thrilled to see stuff like this taking shape. nice work, doug. if you haven't already seen them, you're almost certainly interested in the following issues: http://drupal.org/node/94154 http://drupal.org/node/48580 cheers, -derek (dww)
'modulemonitor' or 'statusmonitor' sounds like how its working to me... Stefan Op 3-jan-2007, om 1:32 heeft Khalid B het volgende geschreven:
Good work.
I saw the commits in CVS, and wondered "what the heck is version 2"?
Can you please consider renaming it a more descriptive name? Something like contrib status, upgradability status, or the like?
On 1/2/07, Doug Green <douggreen@douggreenconsulting.com> wrote: I want to announce a new Developer Module named "version2" that assists with keeping contributed modules up to date and summarizing their upgrade availability. If you install this module on a 4.7 site, you can quickly determine if you are ready for the 5.0 upgrade based on the availability of 5.0 modules.
http://drupal.org/project/version2
I believe that it works, but it is brand spanking new (I wrote it last night and today) and should be considered beta quality. But as we are in the middle of an upgrade push, I wanted to make it available sooner rather than later.
Version2 reads the current version information of enabled contributed modules from CVS/Tag, the CVS $Id$ string, and from the new .info files. Using cron, it gets the current version information from cvs.drupal.org to determine if your there are both minor or major upgrades available; update checks are currently limited to once per day. Version2 displays this information on a single page and creates watchdog events when an upgrade is available.
To quickly determine your contrib module upgrade availability for the next major release, install version2 on your current site and look for links in the cvstag column. These are links to the new release download on cvs.drupal.org. If most/all of your contrib modules are available, then it's time to upgrade your site!
Doug Green 904-583-3342 www.civicactions.com www.douggreenconsulting.com
Changing the world one node at a time!
Doug Green wrote:
I want to announce a new Developer Module named "version2" that assists with keeping contributed modules up to date and summarizing their upgrade availability. If you install this module on a 4.7 site, you can quickly determine if you are ready for the 5.0 upgrade based on the availability of 5.0 modules.
http://drupal.org/project/version2
I believe that it works, but it is brand spanking new (I wrote it last night and today) and should be considered beta quality. But as we are in the middle of an upgrade push, I wanted to make it available sooner rather than later.
Version2 reads the current version information of enabled contributed modules from CVS/Tag, the CVS $Id$ string, and from the new .info files. Using cron, it gets the current version information from cvs.drupal.org to determine if your there are both minor or major upgrades available; update checks are currently limited to once per day. Version2 displays this information on a single page and creates watchdog events when an upgrade is available.
To quickly determine your contrib module upgrade availability for the next major release, install version2 on your current site and look for links in the cvstag column. These are links to the new release download on cvs.drupal.org. If most/all of your contrib modules are available, then it's time to upgrade your site!
I really, really think using information from CVS for updates is a bad, bad idea and is a step backward from where we're heading.
On Jan 2, 2007, at 5:53 PM, Earl Miles wrote:
I really, really think using information from CVS for updates is a bad, bad idea and is a step backward from where we're heading.
i basically agree, but given what actually exists right now, there aren't a lot of better alternatives. we desperately need a solution (i.e. someone to write the code) for: "provide module version info from drupal.org" http://drupal.org/node/48580 then, "version_updates.module" (or whatever we call this thing) can work as contrib for older versions (5.x, 4.7.x, etc), and in D6, we can finish implementing: "module page could say if new releases are available" http://drupal.org/node/94154 however, until #48580 is done, all you've got to work with is screen- scraping project nodes or something, and that's no joke. so, while i share earl's general distaste for this particular implementation in the long run, i can't at all blame doug for going this route in the meantime, since you have to build code with what exists, not with what's on my TODO list[1]. ;) of course, i would have rather doug knew about, wrote, tested, and provided a patch for #48580, helped get it all the way through review, commit and d.o deployment, and *then* built the contrib module we all wanted to see based on that, but who can blame him for just asking cvs.drupal.org instead? cheers, -derek [1] http://groups.drupal.org/node/1830 (among others) ;)
I read http://drupal.org/node/94154 before starting work on this. I was fighting the problem of knowing when I could upgrade my sites to Drupal 5 and looking up the current DRUPAL-5 tag availability of every contrib module for each of my sites, on an every so often basis, was becoming time consuming. I won't disagree that reading an html page from CVS is not the better solution, but it works today. What I don't like about it is that I am parsing a very specific HTML page looking for stuff inside a <select> statement. I'd be just as happy (happier) to make an http request to a d.o project page. I haven't looked at project.module at all, but I think all that is missing is to make project.module expose additional information (an RSS feed for aggregators and some other machine readable format [XML/ini style]). If I have the project name (i.e., views) and the module name (i.e., views_ui.module) can the project module return all of the releases and the most recent cvs id's for that tag? I'm open to other names, but may need some help getting CVS and the project system to recognize the new name. Under the same vain, does anyone know how to correct the project version 5.x-5.x-dev? When I created project release, I accidentally gave 5 for the major version number instead of 1. Doug Green 904-583-3342 www.douggreenconsulting.com Bringing Ideas to Life with Software Artistry and Invention... Providing open source software political solutions -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Derek Wright Sent: Tuesday, January 02, 2007 9:15 PM To: development@drupal.org Subject: Re: [development] Version2 Module On Jan 2, 2007, at 5:53 PM, Earl Miles wrote:
I really, really think using information from CVS for updates is a bad, bad idea and is a step backward from where we're heading.
i basically agree, but given what actually exists right now, there aren't a lot of better alternatives. we desperately need a solution (i.e. someone to write the code) for: "provide module version info from drupal.org" http://drupal.org/node/48580 then, "version_updates.module" (or whatever we call this thing) can work as contrib for older versions (5.x, 4.7.x, etc), and in D6, we can finish implementing: "module page could say if new releases are available" http://drupal.org/node/94154 however, until #48580 is done, all you've got to work with is screen- scraping project nodes or something, and that's no joke. so, while i share earl's general distaste for this particular implementation in the long run, i can't at all blame doug for going this route in the meantime, since you have to build code with what exists, not with what's on my TODO list[1]. ;) of course, i would have rather doug knew about, wrote, tested, and provided a patch for #48580, helped get it all the way through review, commit and d.o deployment, and *then* built the contrib module we all wanted to see based on that, but who can blame him for just asking cvs.drupal.org instead? cheers, -derek [1] http://groups.drupal.org/node/1830 (among others) ;)
On Jan 2, 2007, at 7:47 PM, Doug Green wrote:
I haven't looked at project.module at all, but I think all that is missing is to make project.module expose additional information (an RSS feed for aggregators and some other machine readable format [XML/ini style]).
right, that's exactly what's being proposed and discussed in: http://drupal.org/node/94154
If I have the project name (i.e., views) and the module name (i.e., views_ui.module) can the project module return all of the releases and the most recent cvs id's for that tag?
release versions: yes (from the {project_release_nodes} table) cvs ids: not currently (this info isn't mirrored into the DB at all)
I'm open to other names, but may need some help getting CVS and the project system to recognize the new name.
just decide on a better name and followup here: http://drupal.org/node/106526 (rename "version2" module to something better) then one of the cvs admins (myself, killes, kjartan, etc) can help with the rename in CVS. you'll be able to just edit the project node. you'll probably need a little help renaming the existing release nodes, so to avoid making extra work, please don't add any more releases until the rename is done.
Under the same vain, does anyone know how to correct the project version 5.x-5.x-dev? When I created project release, I accidentally gave 5 for the major version number instead of 1.
i just fixed it for you. again, you just need someone with enough permissions on drupal.org and they can edit these things in a release node. cheers, -derek
On 03 Jan 2007, at 03:15, Derek Wright wrote:
however, until #48580 is done, all you've got to work with is screen-scraping project nodes or something, and that's no joke.
No massive drupal.org screen-scraping projects please. If thousands of people start scraping hundreds of drupal.org pages, you created a DoS attack. :) -- Dries Buytaert :: http://www.buytaert.net/
On 03 Jan 2007, at 03:15, Derek Wright wrote:
I really, really think using information from CVS for updates is a bad, bad idea and is a step backward from where we're heading.
i basically agree, but given what actually exists right now, there aren't a lot of better alternatives. we desperately need a solution (i.e. someone to write the code) for:
While it's a cool little project, I agree with Derek's and Earl's assessment. I hate to say it, but Doug's time was better spent implementing http://drupal.org/node/48580. :) Of course, that can still happen, and version 2 of version2 (ugh, what a bad name!) could be updated to integrate with project module. What do you think Doug? We'd love this functionality done right! :-) -- Dries Buytaert :: http://www.buytaert.net/
Sure, I'd be happy to work on this next part. I do want to point out that my current module helps with the upgrade from 4.7 to 5.0. If your site installed the contrib modules from CVS (which I believe will be many/most professional developers), install this new module on your 4.7 sites, and view the /admin/version page. Sorry about the name. I knew it was bad. I pretty much developed the module overnight, and wanted to get it out. What do people think of "Project Release Monitor" ("projectreleasemonitor" in cvs)? I don't think it's as bad as Dries says. It wasn't a waste of time because this module will help some people with the 4.7 -> 5.0 upgrade (me being one of them). For it to be useful to the Drupal masses, though, it needs to (and will) use the new project system. Doug Green www.douggreenconsulting.com www.civicactions.com -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Dries Buytaert Sent: Wednesday, January 03, 2007 2:45 AM To: development@drupal.org Subject: Re: [development] Version2 Module On 03 Jan 2007, at 03:15, Derek Wright wrote:
I really, really think using information from CVS for updates is a bad, bad idea and is a step backward from where we're heading.
i basically agree, but given what actually exists right now, there aren't a lot of better alternatives. we desperately need a solution (i.e. someone to write the code) for:
While it's a cool little project, I agree with Derek's and Earl's assessment. I hate to say it, but Doug's time was better spent implementing http://drupal.org/node/48580. :) Of course, that can still happen, and version 2 of version2 (ugh, what a bad name!) could be updated to integrate with project module. What do you think Doug? We'd love this functionality done right! :-) -- Dries Buytaert :: http://www.buytaert.net/
Doug Green wrote:
I don't think it's as bad as Dries says. It wasn't a waste of time because this module will help some people with the 4.7 -> 5.0 upgrade (me being one of them). For it to be useful to the Drupal masses, though, it needs to (and will) use the new project system.
How does it handle module .inc files? (Example: views_query.inc) How does it handle multiple modules in the same directory? (Example: views_ui.module) -- these are two of the reasons I've preferred to avoid CVS at all for this kind of thing, and why I think doing this will end up getting your users into some trouble. I've been trying to set aside some time to help Derek out by writing an xmlrpc interface to get project info, as discussed in the thread Derek has mentioned a couple of times, but I haven't been able to fit it into my schedule. I think such a project is very simple. And once you can query it...yes, it's going to be difficult with 4.7 because you won't have the project info, but in 5 you'll have it. The 4.7 --> 5 problem might be well served by creating a module that guesses at the information and does some queries, and lets the users fill in information it guesses at incorrectly.
It reads the system table for a list of enabled modules. It then filters out core modules (based on name and the Drupal constant VERSION). It makes a pretty good attempt at determining the project name (works for every module I've tested with), and gets the latest CVS Id for that project module. When there are two modules in one directory, views being a good example, it displays both modules and tells the administrator that both modules can be upgraded. This is a great point! I should probably change it so that it groups modules into projects and only displays project upgrade notices (instead of the current module upgrade notices). It does not handle anything except .module files (.inc, .info, or .theme). This is a shortcoming that should/will be fixed by the project.module and the .info packaging information. I'll work in this direction. But I think we all recognize that this information is not available in 4.7. Doug Green www.douggreenconsulting.com www.civicactions.com -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Earl Miles Sent: Wednesday, January 03, 2007 9:21 AM To: development@drupal.org Subject: Re: [development] Version2 Module Doug Green wrote:
I don't think it's as bad as Dries says. It wasn't a waste of time because this module will help some people with the 4.7 -> 5.0 upgrade (me being one of them). For it to be useful to the Drupal masses, though, it needs to (and will) use the new project system.
How does it handle module .inc files? (Example: views_query.inc) How does it handle multiple modules in the same directory? (Example: views_ui.module) -- these are two of the reasons I've preferred to avoid CVS at all for this kind of thing, and why I think doing this will end up getting your users into some trouble. I've been trying to set aside some time to help Derek out by writing an xmlrpc interface to get project info, as discussed in the thread Derek has mentioned a couple of times, but I haven't been able to fit it into my schedule. I think such a project is very simple. And once you can query it...yes, it's going to be difficult with 4.7 because you won't have the project info, but in 5 you'll have it. The 4.7 --> 5 problem might be well served by creating a module that guesses at the information and does some queries, and lets the users fill in information it guesses at incorrectly.
On 03 Jan 2007, at 14:14, Doug Green wrote:
Sure, I'd be happy to work on this next part.
Great! Thanks Doug! :)
I don't think it's as bad as Dries says. It wasn't a waste of time because this module will help some people with the 4.7 -> 5.0 upgrade (me being one of them). For it to be useful to the Drupal masses, though, it needs to (and will) use the new project system.
Ok, I agree that something is better than nothing. The current module is a useful first step within the capabilities of Drupal 4.7. For Drupal 5.0 we can all collaborate on something better. :-) Rock on folks, -- Dries Buytaert :: http://www.buytaert.net/
I've checked in some changes intended to move the currently named version2 module toward project release management (proposed releasemonitor module) instead of just module versions. The most recent changes are: * shows projects instead of modules * look and feel more like a release monitor, changed text from "version" to "release", "module" to "project", tried to remove references to cvs and cvs.drupal.org. * added a "show cvs" setting in Drupal 5 that defaults to off. * pulls description information from the .info file, when it is available * added links to the d.o project page (would like to eventually make this the release download page, but I need to get that project status stuff implemented to do this) I'd like to rename the project "releasemonitor", but guess I believe that I need some help doing so: http://drupal.org/node/106526 One question... when the project is renamed in CVS, will someone also rename module files (.module, .install, and .info)? This stuff is in the HEAD/5.x-1.x-dev release currently at (but hopefully moving soon): http://drupal.org/project/version2 http://cvs.drupal.org/viewcvs/drupal/contributions/modules/version2/?only_wi th_tag=HEAD My wife wants me to get back to work that pays, so I hope y'all like this ;) Doug Green www.douggreenconsulting.com www.civicactions.net Changing the world one node at a time! -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Dries Buytaert Sent: Wednesday, January 03, 2007 10:25 AM To: development@drupal.org Subject: Re: [development] Version2 Module On 03 Jan 2007, at 14:14, Doug Green wrote:
Sure, I'd be happy to work on this next part.
Great! Thanks Doug! :)
I don't think it's as bad as Dries says. It wasn't a waste of time
because
this module will help some people with the 4.7 -> 5.0 upgrade (me
being one
of them). For it to be useful to the Drupal masses, though, it
needs to
(and will) use the new project system.
Ok, I agree that something is better than nothing. The current module is a useful first step within the capabilities of Drupal 4.7. For Drupal 5.0 we can all collaborate on something better. :-) Rock on folks, -- Dries Buytaert :: http://www.buytaert.net/
On 1/4/07, Doug Green <douggreen@douggreenconsulting.com> wrote:
I'd like to rename the project "releasemonitor", but guess I believe that I need some help doing so:
One question... when the project is renamed in CVS, will someone also rename module files (.module, .install, and .info)?
Nice new name (and a valuable module of course) If renaming everything is too much trouble, you could always start it as a new one. Deleting the old one should be simpler (or less necessary).
On 04 Jan 2007, at 04:23, Doug Green wrote:
I've checked in some changes intended to move the currently named version2 module toward project release management (proposed releasemonitor module) instead of just module versions.
Good job, Doug! Two important suggestions: 1. People should not have to install a contributed module to see what modules are insecure or outdated. Some of this are the natural next steps for core. With Drupal 5, we laid the foundations, and I hope people we can complete this work in Drupal 6. While it is great to see a module for Drupal 5, I hope you'll help submit patches for Drupal 6. This is core functionality. 2. This has come up a number of times but there is a need to perform some of these tasks from the command-line so people can -- potentially -- monitor hundreds of sites. As pointed out by Ber and others, we'll want to build command-line tools or libraries for this, and then build one or more GUIs on top of that. It might we worth keeping that in mind as the tool continues to evolve. // Stupid pseudo code: foreach ($sites_on_system as $site) { boostrap($site); $modules = drupal_get_outdated_modules(); print "$site needs to upgrade $modules!\n"; } Based on (1) and (2), I suggest we create a release.inc for core with the basic functionality required to make some of this possible. -- Dries Buytaert :: http://www.buytaert.net/
On Jan 4, 2007, at 12:20 AM, Dries Buytaert wrote:
This is core functionality.
i totally agree. work has already begun here: http://drupal.org/node/94154 "module page could say if new releases are available" (feature request against 6.x-dev, with a lot of initial work hashing out implementation ideas).
we'll want to build command-line tools or libraries for this
very good point.
I suggest we create a release.inc for core with the basic functionality required to make some of this possible.
sounds good. however, i should caution anyone planning to work on this stuff, if you haven't already, please read this comment (at least the 1st bullet point) about why core's release.inc should *NOT* have knowledge of CVS, $Name$ or $Id$ strings, etc: http://drupal.org/node/87298#comment-154604 in other news... bless his soul, nedjo has rolled a patch for the project.module XML-RPC server side to hand out the data: http://drupal.org/node/48580 needs review, but it's pretty simple, and could potentially go live in a matter of days (i can devote more time to this once i finish up the last of my tasks getting project* 5.x ready for the big d.o deployment). cheers, -derek
participants (8)
-
Cog Rusty -
Derek Wright -
Doug Green -
Dries Buytaert -
Earl Miles -
Gabor Hojtsy -
Khalid B -
Stefan Nagtegaal