Post Reply 
 
Thread Rating:
  • 0 Votes - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
multi-siting i.e. one distributive cna work on several domains
05-29-2012, 05:30 AM
Post: #1
multi-siting i.e. one distributive cna work on several domains
My compliments to the author of Barebones,
although I don't use it my live projects, it took me lots of evenings and nights to learn ins and outs oа the CMS.

Now I got a question about multisiting. Is it difficult to realize it? High performance and widget system would be of great use here.
Quote this message in a reply
05-29-2012, 10:35 AM
Post: #2
RE: multi-siting i.e. one distributive cna work on several domains
If I understand the request correctly: You want multisite support on a single Barebones CMS instance.

How that works in other CMS products is to point multiple domain names to a single host and then letting the software differentiate between what content to serve up based on the incoming request via a database. There is only one uploaded and installed CMS instance - so less to maintain.

Using Barebones CMS in this manner should be possible but might have additional security implications. What you would need for this is to install Barebones CMS into one domain on the host (basically a "root domain"). Then, for each additional domain, create a new page in a subdirectory with the domain name as the name for the subdirectory (for organizational purposes - really, you can name it whatever you want). Then configure the web server to point at that subdirectory for that domain as the document root.

Each page in the CMS is its own set of PHP files and they know how to locate the root path structure of the CMS. However, you might encounter problems with the 'support' and 'widgets' directories not being able to be found if the web browser makes requests to them. To fix this issue, create symbolic links in each domain subdirectory that correctly point to the real 'support' and 'widgets' subdirectories.

I realize this is extra work, but you are wanting to do something a little out of the ordinary, so doing some extra work should be expected.

The main security implication for doing this is that a developer or designer account can edit any page in any domain regardless of the source of the request. If there is no need for per-domain developer/designer accounts, then this isn't an issue. Otherwise, this might be able to be "fixed" by writing a plugin that checks the incoming request against the domain name against a set of known accounts to determine if the user is actually allowed to edit the file.

Author of Barebones CMS

If you found my reply to be helpful, be sure to donate!
All funding goes toward future product development.
Find all posts by this user
Quote this message in a reply
Post Reply 


Forum Jump:


User(s) browsing this thread: 1 Guest(s)

© CubicleSoft