[development] Evil hack: admin/modules without memory restrictions
larry at garfieldtech.com
Sun Jan 22 19:59:31 UTC 2006
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.
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
More information about the development