[development] 4.8/5.0: Modules, the install system, and directories

Morbus Iff morbus at disobey.com
Wed Feb 22 13:42:27 UTC 2006


This is what I'd like to see in 4.8/5.0 which would tie up some "loose 
ends" as it were with some of the direction that Drupal is moving in. 
These are bullet points because I'm heading off to work, but I'll be 
more than happy to wax further.

  * Modules get their own directory. (modules/system/system.module).

  * All modules get own .install (modules/comments/comment.install).
    This way, all the relevant tables of a module are "closest" to the
    source, and won't actually get thrown into the db until someone
    enables them (I hate the fact that I've got about 15 tables I'm
    not using in my Drupal database. Just drives me nuts.) This also
    helps update.php in that it will only need to go through ENABLED
    modules, instead of performing updates for unused tables. We can
    also pre-create/publish nid 1 in modules/node/node.install without
    having that dummy hardcoded text, a long standing issue.

  * databases/ directory is removed entirely. By giving each module
    their own .install, we don't really need databases/ anymore -
    we'd just need to, at first run, check if table system exists.
    If not, find all required modules and run their .install. This
    way, we remove the entire schema creation step of the INSTALL.
    All the existing updates.inc would move into system.install.
    This is nice, IMO, because it'll make a purdy friendly installer
    a lot easier to create (as it'd just have to send to the frontpage
    after DB config/QA instead of sucking in databases.mysql).

  * Modules get an activate, deactivate, and uninstall hook. I think
    Merlin was working on this to some degree. Activate enables the
    module, deactivate disables it, but keeps the created data, prefs,
    and tables in place, and uninstall removes everything. This mimicks
    the operation of Gallery 2 modules - the uninstall part is awesome!
    If I use search.module for a week on my 5000+ node site, then find
    out it's just not good enough, I don't want those gigantic tables
    hanging around forever, taking up backup space. If I uninstall
    search.module, those tables and data should be removed.

  * .install files get aggregator_schema_version() function which tells
    the installer which version number to set in the system table on
    FIRST INSTALL. This way, it's not calling or seeing a number of
    updates that are already applied to the initial starting table.
    (I think this is a problem in our current install system, right?)

  * By putting modules into their own directory, we're making it easier
    for some of those comments.help related ideas to kick in - to stick
    the help text in an external file and call it only when needed. I
    also think that chx's splitmode is a lot nicer if we could constrain
    the split functions to their source directory instead of having a
    primary directory full of 1000+ mini-files.

I coulda swore I had more in the shower, but I've to go to work now.

-- 
Morbus Iff ( accept no prostitutes )
Technical: http://www.oreillynet.com/pub/au/779
Culture: http://www.disobey.com/ and http://www.gamegrene.com/
icq: 2927491 / aim: akaMorbus / yahoo: morbus_iff / jabber.org: morbus


More information about the development mailing list