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