[development] Module updater module

[Sammy Spets]

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
>