[development] Evil hack: admin/modules without memory restrictions

[Larry Garfield]

On Sunday 22 January 2006 11:28, Khalid B wrote:

> > Has anybody talked about using "functional" folders?
>
> If you mean on the admin/modules and admin/settings pages, then yes,
> this is something I thought of. If we have "system" or "drupal", then
> groups that are categoriezed (much like RPMs on Red Hat for example:
> Internet, Games, Development, Office, ...etc.)
> 
> So, if we have drupal, community features, ecommerce, admin tools,
> misc,  ...etc.
>
> Again, this can be a settings in the modulename.ini file
>
>     category = 'Site tools'
>
> The trick is what hierarchy we put in place, and agreeing on such a
> basic hierarchy.
>
> If you mean we group the directories to be like that, then I disagree.
> Modules already have a place under sites/default/modules,
> sites/sitehostname/modules or (if we implement it) sites/all/modules,
> each in its own directory. Things that depend on other modules (e.g.
> ecommerce contrib) can be under their main module.

Just an FYI, the sites/all suggestion from an earlier thread is already slated 
for inclusion early in 4.8.

http://drupal.org/node/44920

That is step one of fully separating core and admin-added plugins.

Step 2 would be the drupal/ or core/ or whatever directory that some have 
discussed.  Since that requires a lot of moving stuff around in CVS, I think 
that really has to be done by Dries.  That would also be the proper time to 
move all core modules into their own directories, which I agree is what we 
should be doing.  That would then allow us to do a lot of other breakup and 
refactoring that needs to be done, for various reasons.

I'm liking this ini file idea to replace/supplement hook_help().  You only 
need a little bit of metadata for admin/modules, not any of the functionality 
of the modules in question.  Name, dependency information, description, etc. 
can all be put in there and parsed in a split second, even if they're then 
just put straight into the system table and pulled from there thereafter.

Currently, as far as I am aware the system will parse any module file anywhere 
in the modules/ directory (and its kin).  The file structure of the directory 
should reflect the packaging, not the dependencies.  If a given tarball comes 
with modules modA, modB, and modC (like ecommerce), they should all be in the 
modules/mod/ directory.  If another module, modD, is an extension to modB, it 
should say so in its metadata, not its file location.  Consider that mod/ may 
be in sites/all, but you only want modD available on the sites/myexample.com/ 
site.  You can't do that if it's filesystem dependent.

So +1 to an ini file.  +1 to every module having its own directory.  Assume 
sites/all/ will happen, since Dries seems to like it as well. :-)  

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson