• A 'mods' directory for webv4

    From echicken@1:103/705 to All on Wed Sep 23 17:10:56 2020
    Seeking feedback from any who use webv4 - especially if you've customized the stock pages or added new content or sidebar modules to your site. If this doesn't apply to you ... uh, don't read this, because it'll be very long and boring for you.

    I've made a branch of webv4 with a new feature: a 'mods' directory, much like the one you may already be using elsewhere on your BBS. Things may change, but here's how it works so far:

    Let's say your webv4 is in the default location and looks like this:

    webv4/
    webv4/components/
    webv4/lib/
    webv4/pages/
    webv4/root/
    webv4/sidebar/

    You can now have:

    webv4/mods/
    webv4/mods/components/
    webv4/mods/pages/
    webv4/mods/sidebar/

    "Components" include the header, footer, and navigation menu that appear on every page. If a file exists in webv4/mods/components/ and has the same name as a file in webv4/components/, the 'mods' variant will be used instead.

    For pages, if a file in webv4/mods/pages/ has the same "name" as a file in webv4/pages/, the 'mods' variant will be used instead. When checking to see if there is a 'mod', the numeric prefixes of both files are ignored; this means that webv4/mods/pages/999-home.xjs will override webv4/pages/000-home.xjs. If a file exists in webv4/mods/pages/ but not in webv4/pages/, it will still be included in your menu and available on your site.

    Subdirectories of webv4/pages/ are handled according to the same rules, recursively. If you want to override webv4/pages/More/001-userlist.xjs, you can create webv4/mods/pages/More/001-userlist.xjs (and give it whatever numeric prefix you want, for ordering purposes). Any other files/directories in webv4/pages/More will still be listed; you don't need to duplicate them in 'mods'.

    Sidebar modules are handled the same as pages (though there are no subdirectories to consider there).

    Pages and sidebar modules are sorted into display order after the lists have been merged, so the numeric prefix of a 'mod' will determine its placement, and the prefix of the file it overrides will be ignored.

    This means that if you want to replace or customize one of the stock components/pages/sidebar modules, you can make a copy of it in webv4/mods/ and you won't risk losing your changes or running into other problems during an update.

    (Also, *nix sysops can change the order of pages/sidebar modules by creating a symlink in the mods directory, pointing to the 'real' file in the stock directory. You'll benefit from updates to the stock file but be able to maintain your own display order.)

    Up until now, the stock contents were kept in '.examples' subdirectories, and it was up to you (or the installer) to copy them out of there and into the parent directory when you installed or updated. This was done for similar reasons, to avoid overwriting your customizations. Now I'd like to move the contents of those .examples directories up one level, and get rid of the .examples directories. This might make things a bit messy if/when you update, so I still need to think about how best to handle that.

    These changes aren't "live" yet; they're in the 'web-mods' branch of the sbbs repo in gitlab.synchro.net. I still need to finish some of the work and test a few things - and take into account any thoughts you may have on the subject.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
    þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to echicken on Wed Sep 23 14:45:54 2020
    Re: A 'mods' directory for webv4
    By: echicken to All on Wed Sep 23 2020 05:10 pm

    Seeking feedback from any who use webv4 - especially if you've customized the stock pages or added new content or sidebar modules to your site. If this doesn't apply to you ... uh, don't read this, because it'll be very long and boring for you.

    No objections from me. As for the update process, feel free to add stuff to exec/update.js if it helps (when relevant).

    digital man

    Synchronet "Real Fact" #77:
    Rob Swindell still has dozens of BBS-related magazines in his possession. Norco, CA WX: 89.5øF, 30.0% humidity, 8 mph NNE wind, 0.00 inches rain/24hrs --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From echicken@1:103/705 to Digital Man on Wed Sep 23 22:25:01 2020
    Re: A 'mods' directory for webv4
    By: Digital Man to echicken on Wed Sep 23 2020 14:45:54

    No objections from me. As for the update process, feel free to add stuff to exec/update.js if it
    helps (when relevant).

    I was thinking about that earlier, and it'd be a good fit for update.js.

    The only people I can see this causing problems for are folks who are using webv4 from a git-controlled directory. They might have copied eg. pages/.examples/* up one level, where there were no files before by default; now they would conflict with files from the repo.

    I'm not sure if anyone's using it that way. If they are, I hope they don't mind making a small adjustment. Or perhaps I can find another way around it.

    ---
    echicken
    electronic chicken bbs - bbs.electronicchicken.com
    þ Synchronet þ electronic chicken bbs - bbs.electronicchicken.com
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)
  • From Digital Man@1:103/705 to echicken on Wed Sep 23 19:52:04 2020
    Re: A 'mods' directory for webv4
    By: echicken to Digital Man on Wed Sep 23 2020 10:25 pm

    Re: A 'mods' directory for webv4
    By: Digital Man to echicken on Wed Sep 23 2020 14:45:54

    No objections from me. As for the update process, feel free to add stuff to exec/update.js if it helps (when relevant).

    I was thinking about that earlier, and it'd be a good fit for update.js.

    The only people I can see this causing problems for are folks who are using webv4 from a git-controlled directory. They might have copied eg. pages/.examples/* up one level, where there were no files before by default; now they would conflict with files from the repo.

    I'm not sure if anyone's using it that way. If they are, I hope they don't mind making a small adjustment. Or perhaps I can find another way around it.
    I symlinked most (all?) the .examples/* files to their parent dirs. And pages/More/.examples to pages/More. But I don't have any uncommitted local changes, so won't be a problem for me.

    digital man

    Synchronet "Real Fact" #47:
    The Synchronet Museum is online at http://wiki.synchro.net/history:museum:index Norco, CA WX: 77.2øF, 46.0% humidity, 5 mph E wind, 0.00 inches rain/24hrs
    --- SBBSecho 3.11-Linux
    * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)