Differences from version 5 to 7



@@ -1,261 +1 @@

-
- style="font-weight: bold;">INTRODUCTION
- style="font-weight: bold;">
among the key features
-i'm looking for in a cms is 'strong/flexible multi-site support'.

i
-know there are discussion's of mutlsite functionality scattered
-throughout both tw.o & bw.o.  personally, 
-find it confusing to find it all, let alone figure out what's best
-practice ...

that said, my hope/intention with this
-particular wiki page is to:
  1. gather,
-summarize & provide examples of the way things *currently* work
-in bw.o
  • brainstorm ideas, documenting 'issues'
  • -& 'wishlists'  of 'how to make it better' -- and end
    -up with a functional design proposal to float for development ...i'm
    -generally new to bw.o myself, and
    - style="font-weight: bold; font-style: italic;"> really
    -invite any/all interested to participate.
    if in doing so, if
    -we can keep it organized & readable to boot ... then, woot!

    i'm
    -gonna start by dumping *my* ideas/notes here ... please feel free to
    -markup, comment, etc.

    and, yes! i realize that all
    -of this may already be easily do-able in bw.o, and i just haven't
    -learned enuf yet.  in that case, i'll at least feel more
    -organized :-)

    - style="font-weight: bold;">CURRENT STATE OF AFFAIRS
    -... bw.o
    - style="font-style: italic; text-decoration: underline;">
    an
    -out-of-the-box bw.o install is physically laid out as:

    - style="font-family: monospace;">   
    -${main bw.o install}
    - style="font-family: monospace;">   
    -   |
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |-- util/
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |--
    -smarty/
    - style="font-family: monospace;">   
    -   |     |--
    -adodb/
    - style="font-family: monospace;">   
    -   |     |-- ...
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |-- themes/
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |--
    -admin/
    - style="font-family: monospace;">   
    -   |     |--
    -modules/
    - style="font-family: monospace;">   
    -   |     |--
    -templates/
    - style="font-family: monospace;">   
    -   |     |--
    -styles/
    - style="font-family: monospace;">   
    -  
    -|         
    -|
    - style="font-family: monospace;">   
    -  
    -|         
    -|-- basic/
    - style="font-family: monospace;">   
    -  
    -|         
    -|-- clean/
    - style="font-family: monospace;">   
    -  
    -|         
    -|-- jill/
    - style="font-family: monospace;">   
    -  
    -|         
    -|-- firebird/
    - style="font-family: monospace;">   
    -  
    -|         
    -|-- ...
    - style="font-family: monospace;">   
    -   |
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |-- ...
    - style="font-family: monospace;">

    - style="font-weight: bold;">GENERAL APPROACH
    - style="font-weight: bold;">
    prior
    -to moving to bw.o, or any cms project for that matter, when designing
    -my own smarty-based, multiple sites for a single server, i worry about
    -four things:
    1. physical & logical
    -separation of app src, smarty src & site data
  • provide
  • -inheritable/overridable configs, from global default to local specific
  • insulate
  • -designs changes from other/coeexistent webapps
  • do
  • -not break access to other app APIs
    - style="font-weight: bold;">
    - style="font-weight: bold;">FUNCTIONAL CONSIDERATIONS:
    - style="font-weight: bold;">

    - style="font-weight: bold;">BEST PRACTICES FROM OTHER
    -PROJECTS ...

    just like just about
    -everybody else, i've tried a number of 'other' CMS frameworks.
    - each has some nice features that make life-with-multisites a
    -bit easier.

    there are ideas from various projects
    -that might be worth 'adopting'.

    the
    - style="font-weight: bold; font-style: italic; text-decoration: underline;">drupal
    -project has what i consider to be a great start at multisite management:
    • sites
    -are 'created' by simply creating a subdirectory in its sites/ dir
  • directories
  • -are named as  FQDNs; one exception is the 'default' site
  • a
  • -given site's URL is constructed from the subdirectory name
  • sites
  • -can be individual/unique domains, and/or  subdomains
  • non-standard
  • -ports can be assigned for a site, prepending the portnum as the deepest
    -subdomainso, for example,

    - style="margin-left: 40px;">sites/default
    sites/example.com
    sites/sub.example.com
    sites/www.domain.com
    sites/8080.www.domain2.com 
    -   

    would all be valid
    -sites ...

    in drupal, each site can have its own
    -site-specific modules and themes that are made available
    - style="font-style: italic; text-decoration: underline;">in
    -addition to those installed in the installation's global
    -'modules' and 'themes' directories, e.g.:

    - style="font-family: monospace;">   
    -${main drupal install}
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |-- themes/      
    -(global)
    - style="font-family: monospace;">   
    -   |-- modules/    
    - (global)
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |
    - style="font-family: monospace;">-- sites/
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |--
    -default/
    - style="font-family: monospace;">   
    -   |     |
    -     |--
    - style="font-family: monospace;">themes/  
    -    (site-specific)
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |
    -     |-- modules
    - style="font-family: monospace;">/    
    - (site-specific)
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |
    - style="font-family: monospace;">   
    -   |    
    -|-- www.domain.com
    - style="font-family: monospace;">/
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |
    -     |--
    - style="font-family: monospace;">themes/  
    -    (site-specific)
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |
    -     |-- modules
    - style="font-family: monospace;">/
    - style="font-family: monospace;">    
    - (site-specific)
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    - style="font-family: monospace;">   
    -   |     |
    - style="font-family: monospace;">   
    -  
    -|     |-- ...
    - style="font-family: monospace;">   
    -   |
         
    - |-- ...

    - style="font-family: monospace;">
    - style="font-weight: bold;">SEPARATION/OVERRIDE OF UTILs
    -& SITEs

    in general, i'm a big
    -believer in keeping separate:
    • a core
    -application's source
  • data & configuration
  • -files used by the application
  • third-party
  • -applications' srcmy primary rationale is to
    -ensure that:
    • application source (core
    -& 3rd party) upgrades never 'come near' -- & possibly
    -overwrite! -- my valuable data/config files.  i consider data
    -files IN the app's src tree to be 'near'.
  • 3rd party
  • -applications can be located elsewhere -- either to share sinlge
    -instances amongst other apps, and/or to make available different
    -versions of a given app.
  • core & 3rd party
  • -applications can be -- with necessary caveats & cautions -- be
    -asynchronously upgradedof course, i think
    -bundling a default/global set of apps/config/data into a core app's
    -distro is a 'good thing' -- as long as those default
    -locations/assignments can be overridden on a per-site basis.

    - style="font-weight: bold;">A FRIENDLIER bw.o MULTI-SITE
    -LAYOUT

    taking
    -the drupal layout in conjunction with the keep-it-separate approach,
    -consider a possible
    -bw.o layout of:

        ${main bw.o install}
           |
           |-- util/
           |     |
           |     |-- smarty/
           |     |-- adodb/
           |     |-- ...
           |
           |-- themes/
           |     |-- admin/
           |     |-- modules/
           |     |-- templates/
           |     |-- styles/
           |
           |-- sites/
           |     |-- default/
           |     |   |-- settings.php
           |     |   |-- modules/
           |     |   |-- themes/
           |     |   |-- styles/
           |     |   |-- admin/
           |     |
           |     |-- "examples.com"/ 
           |     |   |-- settings.php
           |     |   |-- modules/
           |     |   |-- themes/
           |     |   |-- styles/
           |     |   |-- admin/
           |
           |     |-- www.domain.com/               (symlink to ${main my_sites location}/www.domain.com)
           |     |   |-- settings.php
           |     |   |-- modules/
           |     |   |-- themes/
           |     |   |-- styles/
           |     |   |-- admin/
           |
           |     |-- ...
        ${main my_sites location}
           |
           |-- www.domain.com/
                |-- settings.php
               |-- modules/
               |-- themes/
               |-- styles/
               |-- admin/
                   |-- cache/
                   |-- configs/
                   |-- include/
                   |-- locale/
                   |-- templates/
                   |-- templates_c/
        ${main smarty install location}
           |
           |-- smarty v2.5.x/
           |-- smarty v2.6.x/
           |-- ...
        ${main adodb install location}
           |
           |-- adodb v2.80/
           |-- adodb v2.70/
           |-- ...
    - style="font-family: monospace;">
    - style="font-family: monospace;">
    where each site's
    -"settings.php" can specify, e.g.:
    - style="font-family: monospace;">path to a specific version
    -of adodb
  • - style="font-family: monospace;">path to a specific version
    -of smarty libs
  • - style="font-family: monospace;">specific smarty class configs
    - style="font-family: monospace;">custom
    -delimiters
  • locations for templates_c &
  • -other smarty-specific dirs
  • etc etc
  • - style="font-family: monospace;">of course, in the absence of
    -any override directive, values would fall back to bw.o global/default
    -values.

    ultimately, this approach scales to src,
    -data, cache & compiled templates, and site files storable in
    -any network-mountable location; think, e.g.:
    - style="font-family: monospace;">compiled templates in a RAM
    -DISK
  • - style="font-family: monospace;">individual site dirs on
    -indiv front-end boxes
  • - style="font-family: monospace;">shared drupal &
    -smarty installs on a back-end box
  • - style="font-family: monospace;">etc
    - style="font-family: monospace;">
    - style="font-weight: bold;">DATABASE ISSUES w/ MULTISITES
    - style="font-family: monospace;">multisites in multiple
    -databases
  • - style="font-family: monospace;">multisites in single
    -database, shared tables
  • - style="font-family: monospace;">sharing some tables ... e.g.:
    - style="font-family: monospace;">consolidated
    -single sign-on 'users/groups'
  • - style="font-family: monospace;">per-site-unique
    -themes, modules & content
  • etc
  • etc
  • - style="font-family: monospace;">
    - style="font-weight: bold;">
    - style="font-weight: bold;">MULTISITE ADMINISTRATION

    what's
    -a admin GUI for all this look like?
    is one evern necessary, or
    -should it be left to manual admin?
    - style="font-family: mon;">
    PER-SITE
    -PAGE & 'other node' OVERRIDES

    - style="font-family: monospace;">
    - style="font-weight: bold;">
     
    Page History
    Date/CommentUserIPVersion
    01 Apr 2006 (19:50 UTC)
    openmacnews70.231.29.2257
    Current • Source
    openmacnews70.231.29.2255
    View • Compare • Difference • Source
    openmacnews70.231.29.2254
    View • Compare • Difference • Source