Module updater module
I set out to port my 3rd or 4th module to 5.x today, and started doing calculations about time/effort spent per module, and also started musing about the fact that I needed some way to flex my regex muscles, so I came up with this: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/webchick/ module_updater/ it's in my sandbox rather than an actual project, because about 10 hours into it when I only had a couple functions written, it started to get really daunting and I wasn't sure if I really wanted to continue working on it or not. ;P I'll see again in the morning. ;) In the meantime: - It generates an .info file and removes the description from hook_help (or hook_help altogether if that's all that was in it) - It adds a menu item for any hook_settings() and changes the return $form to return system_settings_form($form) - It replaces user_mail with drupal_mail() and generates a unique $mailkey for each instance. - It replaces module_exist with module_exists() ;) - It replaces user_mail_wrapper with drupal_mail_wrapper. :P - It also provides documentation for certain changes so that people can alter the "guess" behaviour that the script has to do (ex: dependencies in .info files) - It drupal_set_message()s any changes that it made so that you can go back and correct the work if necessary. It is also probably horribly buggy and has a very long way to go before all of the items at http://drupal.org/node/64279 are covered (I've created skeleton functions in the .inc file for all transition issues). The next ones I'll probably focus on are the t() changes, the hook_view changes, and the hook_link changes, as those have all bit me before. But anyway, if someone wants to take a look, it's there. Or, if someone wants to work on it with me for some reason, let me know! Thanks to eaton, merlinofchaos, dopry and whoever else was in #drupal at the time who helped me brainstorm about this. :) -Angie
Nice module Angela!!! :) I've gone and changed it around a little. Might not be what you want, but my itch has been scratched. It now presents a list of modules that aren't 5.0 compatible yet (marked by the lack of a .info file). The modules can be anywhere in: /modules /sites/all/modules /sites/<whatever is being used>/modules It presents a list of those modules and then reads the code from that module file. Nothing else has changed. It still displays the code on the results page and you need to copy it. I'm thinking of making a downloadable copy of the resulting module file as well. Please find the patch attached. Cheers, -- Sammy Spets Synerger Pty Ltd http://synerger.com On 22-Nov-06 01:40, Angela Byron wrote:
I set out to port my 3rd or 4th module to 5.x today, and started doing calculations about time/effort spent per module, and also started musing about the fact that I needed some way to flex my regex muscles, so I came up with this:
http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/webchick/ module_updater/
it's in my sandbox rather than an actual project, because about 10 hours into it when I only had a couple functions written, it started to get really daunting and I wasn't sure if I really wanted to continue working on it or not. ;P I'll see again in the morning. ;)
In the meantime:
- It generates an .info file and removes the description from hook_help (or hook_help altogether if that's all that was in it) - It adds a menu item for any hook_settings() and changes the return $form to return system_settings_form($form) - It replaces user_mail with drupal_mail() and generates a unique $mailkey for each instance. - It replaces module_exist with module_exists() ;) - It replaces user_mail_wrapper with drupal_mail_wrapper. :P - It also provides documentation for certain changes so that people can alter the "guess" behaviour that the script has to do (ex: dependencies in .info files) - It drupal_set_message()s any changes that it made so that you can go back and correct the work if necessary.
It is also probably horribly buggy and has a very long way to go before all of the items at http://drupal.org/node/64279 are covered (I've created skeleton functions in the .inc file for all transition issues). The next ones I'll probably focus on are the t() changes, the hook_view changes, and the hook_link changes, as those have all bit me before.
But anyway, if someone wants to take a look, it's there. Or, if someone wants to work on it with me for some reason, let me know! Thanks to eaton, merlinofchaos, dopry and whoever else was in #drupal at the time who helped me brainstorm about this. :)
-Angie
Another very useful tool! Yeah, Angie!
On 22-Nov-06, at 4:55 AM, Sammy Spets wrote:
I've gone and changed it around a little. Might not be what you want, but my itch has been scratched.
It now presents a list of modules that aren't 5.0 compatible yet (marked by the lack of a .info file). The modules can be anywhere in: /modules /sites/all/modules /sites/<whatever is being used>/modules
It presents a list of those modules and then reads the code from that module file. Nothing else has changed. It still displays the code on the results page and you need to copy it.
I'm thinking of making a downloadable copy of the resulting module file as well.
Nice! This definitely makes it easier for people than the clunky thing I currently have. ;) The only thing is that this "module_updater_get_module_list" function will need to change between versions. For 4.7.x -> 5.x there's an easy way to tell that modules aren't ported yet -- they lack info files. We will need to find a different trick to detect 6.x modules, and 7.x modules, and... So maybe what I could do is switch it to a 3-step form: 1. "Select the version you want to convert to" ... Drupal 4.7.x => 5.x or 5.x => 6.x, or... 2. "Please choose the module you want to convert" ... foo, bar, baz... this page includes the module_updater_#x.inc file, calls its module_updater_get_module_list() function, and displays a list of modules that match. 3. The output that gets processed, and results are displayed. I was thinking of generating .zip files of the module at the end, but the thing is that there are a lot of caveats and follow-ups that will be associated with this that need to be taken into consideration. For example, see the .info file generation or the drupal_mail converter. But I guess if we could display those and then the link to download it (saved in a temp file) that would work. Hmmm. ;) wheels spinning. Anyway, thanks again. I'll make sure I get this integrated in some form. -Angie
Angela,
The only thing is that this "module_updater_get_module_list" function will need to change between versions. For 4.7.x -> 5.x there's an easy way to tell that modules aren't ported yet -- they lack info files. We will need to find a different trick to detect 6.x modules, and 7.x modules, and...
So maybe what I could do is switch it to a 3-step form:
Yepo! That's what I was thinking too! :) Download of the updated module could be done adding a menu item for a direct download of the code. The conversion process that currently happens is good for eyeballing the resulting code. I had a few of my modules lose 30% of the functions through one of the conversions. I'm not sure which one though. Looks like we need to clean that up. Perhaps we should put in a safety check where it counts the number of lines starting with 'function ' and ensures the resulting module has that number minus the number removed by conversion functions. Just a few ideas off the top of my head. I'll have a look into the reason for the 30% code loss and get back to you with a patch. Cheers, -- Sammy Spets Synerger Pty Ltd http://synerger.com On 22-Nov-06 22:31, Angela Byron wrote:
On 22-Nov-06, at 4:55 AM, Sammy Spets wrote:
I've gone and changed it around a little. Might not be what you want, but my itch has been scratched.
It now presents a list of modules that aren't 5.0 compatible yet (marked by the lack of a .info file). The modules can be anywhere in: /modules /sites/all/modules /sites/<whatever is being used>/modules
It presents a list of those modules and then reads the code from that module file. Nothing else has changed. It still displays the code on the results page and you need to copy it.
I'm thinking of making a downloadable copy of the resulting module file as well.
Nice! This definitely makes it easier for people than the clunky thing I currently have. ;)
The only thing is that this "module_updater_get_module_list" function will need to change between versions. For 4.7.x -> 5.x there's an easy way to tell that modules aren't ported yet -- they lack info files. We will need to find a different trick to detect 6.x modules, and 7.x modules, and...
So maybe what I could do is switch it to a 3-step form:
1. "Select the version you want to convert to" ... Drupal 4.7.x => 5.x or 5.x => 6.x, or... 2. "Please choose the module you want to convert" ... foo, bar, baz... this page includes the module_updater_#x.inc file, calls its module_updater_get_module_list() function, and displays a list of modules that match. 3. The output that gets processed, and results are displayed.
I was thinking of generating .zip files of the module at the end, but the thing is that there are a lot of caveats and follow-ups that will be associated with this that need to be taken into consideration. For example, see the .info file generation or the drupal_mail converter. But I guess if we could display those and then the link to download it (saved in a temp file) that would work.
Hmmm. ;) wheels spinning.
Anyway, thanks again. I'll make sure I get this integrated in some form.
-Angie
participants (3)
-
Angela Byron -
Chris Johnson -
Sammy Spets