-INTRODUCTION
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:
- 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 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 :-)
CURRENT STATE OF AFFAIRS ... bw.o
an out-of-the-box bw.o install is physically laid out as:
${main bw.o install}
|
|-- util/
| |-- smarty/
| |-- adodb/
| |-- ...
|
|-- themes/
| |
| |-- admin/
| |-- modules/
| |-- templates/
| |-- styles/
| |
| |-- basic/
| |-- clean/
| |-- jill/
| |-- firebird/
| |-- ...
|
|-- ...
GENERAL APPROACH
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:
- 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
FUNCTIONAL CONSIDERATIONS:
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 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 subdomain
so, for example,
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 in addition to those installed in the installation's global 'modules' and 'themes' directories, e.g.:
${main drupal install}
|
|-- themes/ (global)
|-- modules/ (global)
|-- sites/
| |-- default/
| | |-- themes/ (site-specific)
| | |-- modules/ (site-specific)
| |
| |-- www.domain.com/
| | |-- themes/ (site-specific)
| | |-- modules/ (site-specific)
| |
| |-- ...
|
|-- ...
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' src
my primary rationale is to ensure that:
|
| -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.
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/
|-- ...
where each site's "settings.php" can specify, e.g.:
- path to a specific version of adodb
- path to a specific version of smarty libs
- specific smarty class configs
- custom delimiters
- locations for templates_c & other smarty-specific dirs
- etc etc
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.:
- compiled templates in a RAM DISK
- individual site dirs on indiv front-end boxes
- shared drupal & smarty installs on a back-end box
- etc
DATABASE ISSUES w/ MULTISITES
- multisites in multiple databases
- multisites in single database, shared tables
- sharing some tables ... e.g.:
- consolidated single sign-on 'users/groups'
- per-site-unique themes, modules & content
- etc
- etc
MULTISITE ADMINISTRATION
what's a admin GUI for all this look like?
is one evern necessary, or should it be left to manual admin?
PER-SITE PAGE & 'other node' OVERRIDES
|
|
|
| -enuf for tonite ... 3/28/06 21:17:57 |