- bitweaver

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: <ol><li>gather,
summarize & provide examples of the way things *currently* work
in bw.o</li><li>brainstorm ideas, documenting 'issues'
& 'wishlists' of 'how to make it better' -- and end
up with a functional design proposal to float for development ...</li></ol>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: <ol><li>physical & logical
separation of app src, smarty src & site data</li><li>provide
inheritable/overridable configs, from global default to local specific</li><li>insulate
designs changes from other/coeexistent webapps</li><li>do
not break access to other app APIs</li></ol> 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: <ul><li>sites
are 'created' by simply creating a subdirectory in its sites/ dir</li><li>directories
are named as FQDNs; one exception is the 'default' site</li><li>a
given site's URL is constructed from the subdirectory name</li><li>sites
can be individual/unique domains, and/or subdomains</li><li>non-standard
ports can be assigned for a site, prepending the portnum as the deepest
subdomain</li></ul>so, for example, <div
style="margin-left: 40px;">sites/default sites/example.com sites/sub.example.com sites/www.domain.com sites/8080.www.domain2.com
 </div> 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: <ul><li>a core
application's source</li><li>data & configuration
files used by the application</li><li>third-party
applications' src</li></ul>my primary rationale is to
ensure that: <ul><li>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'.</li><li>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.</li><li>core & 3rd party
applications can be -- with necessary caveats & cautions -- be
asynchronously upgraded</li></ul>of 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: <pre> ${main bw.o install}</pre><pre> |</pre><pre> |-- util/</pre><pre> | |</pre><pre> | |-- smarty/</pre><pre> | |-- adodb/</pre><pre> | |-- ...</pre><pre> |</pre><pre> |-- themes/</pre><pre> | |-- admin/</pre><pre> | |-- modules/</pre><pre> | |-- templates/</pre><pre> | |-- styles/</pre><pre> |</pre><pre> |-- sites/</pre><pre> | |-- default/</pre><pre> | | |-- settings.php</pre><pre> | | |-- modules/</pre><pre> | | |-- themes/</pre><pre> | | |-- styles/</pre><pre> | | |-- admin/</pre><pre> | |</pre><pre> | |-- "examples.com"/ </pre><pre> | | |-- settings.php</pre><pre> | | |-- modules/</pre><pre> | | |-- themes/</pre><pre> | | |-- styles/</pre><pre> | | |-- admin/</pre><pre> |</pre><pre> | |-- www.domain.com/ (symlink to ${main my_sites location}/www.domain.com)</pre><pre> | | |-- settings.php</pre><pre> | | |-- modules/</pre><pre> | | |-- themes/</pre><pre> | | |-- styles/</pre><pre> | | |-- admin/</pre><pre> |</pre><pre> | |-- ...</pre><pre></pre><pre> ${main my_sites location}</pre><pre> |</pre><pre> |-- www.domain.com/</pre><pre> |-- settings.php</pre><pre> |-- modules/</pre><pre> |-- themes/</pre><pre> |-- styles/</pre><pre> |-- admin/</pre><pre> |-- cache/</pre><pre> |-- configs/</pre><pre> |-- include/</pre><pre> |-- locale/</pre><pre> |-- templates/</pre><pre> |-- templates_c/</pre><pre></pre><pre></pre><pre> ${main smarty install location}</pre><pre> |</pre><pre> |-- smarty v2.5.x/</pre><pre> |-- smarty v2.6.x/</pre><pre> |-- ...</pre><pre></pre><pre> ${main adodb install location}</pre><pre> |</pre><pre> |-- adodb v2.80/</pre><pre> |-- adodb v2.70/</pre><pre> |-- ...</pre><pre></pre> where each site's
"settings.php" can specify, e.g.: <ul><li>path to a specific version
of adodb</li><li>path to a specific version
of smarty libs</li><li>specific smarty class configs</li><ul><li>custom
delimiters</li><li>locations for templates_c &
other smarty-specific dirs</li><li>etc etc</li></ul></ul>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.: <ul><li>compiled templates in a RAM
DISK</li><li>individual site dirs on
indiv front-end boxes</li><li>shared drupal &
smarty installs on a back-end box</li><li>etc</li></ul>DATABASE ISSUES w/ MULTISITES <ul><li>multisites in multiple
databases</li><li>multisites in single
database, shared tables</li><li>sharing some tables ... e.g.:</li><ul><li>consolidated
single sign-on 'users/groups'</li><li>per-site-unique
themes, modules & content</li><li>etc</li></ul><li>etc</li></ul> 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

Page History
Date/Comment	User	IP	Version
01 Apr 2006 (19:50 UTC) —	openmacnews	70.231.29.225	7
Current • Source
29 Mar 2006 (05:22 UTC) —	openmacnews	70.231.29.225	5
View • Compare • Difference • Source
29 Mar 2006 (05:18 UTC) —	openmacnews	70.231.29.225	4
View • Compare • Difference • Source

History of brainstorming multisite support