Fork me on GitHub

Arbitrary number of module directories.  Bottom

  • This is a lower-level question then I typically see in the forums, so if there is a more appropriate place to ask please direct me there and I'll hapily move along.

    I see that wihle there are now two module directories, they appear to have been hard-coded in every place that modules/ appeared before. Has any thought been giving to making this an array, so that additional module directories could be added easily ?

    In CS classes, one of the first things you learn is the 0-1-infinity rule. When you program, you should be able to do tihngs either not at all, once, or as many times as you like. Arbitrary limits usually end up comming back to bite you in the rear later, when you decide you need just one more. I've learned this lesson the hard way, over and over and over.

    More specifically: I'm running multiple PostNuke sites from a single set of installed main source code, using Unix symbolic links. (This allows easier upgrades, and with PHP caching has all sites using the same cached code, giving a speed increase). One thing I would like to do would be to add a third modules directory called something like "localmodules" that was specific to the site. This way the core modules could still be installed globally, but a specific site could install a local module on their own, or for testing.

    If this isn't a frozen feature yet I'm willing to take a look at what is involved.
  • Actually we thought of abandoning the second modules-folder but decided to keep it. The idea IIRC was that it's faster to have as few places to look for modules as possible.

    Why do you keep any module in a project at all? If you need moduleX only on site A you put it only there. But what if later site B also needs moduleX?

    I's suggest you keep them all centrally installed and use links only. icon_wink

    --
    best regards from Kiel, sailing city

    Steffen Voss

    Member of the Zikula Steering Committee
    Read The Zikulan's Blog "If you want people to RTFM, make a better FM!"
  • I was looking through the 0.8 code to see what was possible. Like taking a new tool and seeing what new things you could do with it. I was thinking of s hosting option that would be best of both worlds: a core install that we maintain/upgrade, but still having the flexibility of the site owner at lesat being able to try a module on their own, with us later having the option of offering it globally.

    I think separating modules into at least core and add-on (system and modules) is generally a good thing, in terms of upgrades for the average user being able to remove the whole system directory so core modules are updated without worrying about their add-ons. I could see the ability to add arbitrary directories useful for say specialized distributions to be able to group their modules together (ie, Openstar modules all in one place, separate from what the site owner adds himself).

    For speed, you could just store the module directory in the database, (ie, for the users module, instead of storing 'Users' in the pn_directory field store 'system/Users')

    Currently I'm just linking /modules to the central install. linking each directory inside /modules/ is also an option. It's more to maintain, but also lets unused modules be removed to avoid future problems (like the current guestbook issue)





    edited by: ccandreva, Mar 18, 2007 - 01:05 PM

This list is based on users active over the last 60 minutes.