DusX
How do you resolve your problem?
You mention that you changed the security settings, what and how?
This was your error:
Warning: main() [function.main]: open_basedir restriction in effect. File(/home/core/model/modx/modx.class.php) is not within the allowed path(s): (/home/domain1:/usr/lib/php:/usr/php4/lib/php:/usr/local/lib/php:/usr/local/php4/lib/php:/temp
THanks...
MODX Staff
A single, shared core provides a single maintenance point for core upgrades. Each manager in these scenarios is limited to a single database configuration. You can run multiple domains from a single manager, but...
So, seeing as Jason stated that things will get more organized around this issue as different use scenarios surface amongst users, here is my desired setup with multiple domains:
1. I want to manage multiple domains from a single Manager (using a single Manager is actually the most essential part for me, and to be honest, after reading this thread, I don’t see the benefits of using a single core but multiple managers).
...but only from a single database configuration. I don’t see any easy way to support your scenario at this time, other than using one modX instance within a component of another, but that would require custom components to accomplish (i.e. Wayfinder and other common components would not be aware of this odd configuration or the other databases). I think there are better ways to accomplish what you want to do.
2. Every domain will in 90% of cases a unique database; some of them could call a shared database.
Yes, quite complex tbh. In addition to the problem of supporting multiple databases with a single manager, there simply is no way to partition areas of the database like this, where some components come from database A and some from database B. Or rather, not without using modx as a development framework, in which case, it could definitely provide a foundation on which to build the solution, but such a scenario is currently beyond the scope of what we will be providing as turnkey multi-site/multi-domain solutions with Revolution.
3. I want to be able to share some (all?) Content Elements across these domains (specifically, Ditto, WayFinder, Google Analytics, XML Sitemaps - these are common elements that I always use, and I would want to administer them centrally for updates, etc).
So, stating things in another way, I envisage a single manager that "rules over" several "web" contexts (i.e., domain1.com, domain2.com, domain3.com, domain4.com, domain5.com), each context with its own database (mysql.domain1.com, mysql.domain2.com, mysql.domain3.com, mysql.domain4.com, mysql.domain5.com), and each context sharing a single pool of elements (chunks, snippets, plugins).
Does this sound overly complex? It would be a content management dream, I tell you, when running 10+ domains with fresh content on a daily basis.
Quote from: towerofbabel at May 21, 2009, 06:55 AMA single, shared core provides a single maintenance point for core upgrades. Each manager in these scenarios is limited to a single database configuration. You can run multiple domains from a single manager, but...
So, seeing as Jason stated that things will get more organized around this issue as different use scenarios surface amongst users, here is my desired setup with multiple domains:
1. I want to manage multiple domains from a single Manager (using a single Manager is actually the most essential part for me, and to be honest, after reading this thread, I don’t see the benefits of using a single core but multiple managers).
Ok, I see. a single database seems too unflexible for multiple, growing sites, but I can see how this can be handy for scenarios where a blog is on a subdomain, for example.
Quote from: towerofbabel at May 21, 2009, 06:55 AM...but only from a single database configuration. I don’t see any easy way to support your scenario at this time, other than using one modX instance within a component of another, but that would require custom components to accomplish (i.e. Wayfinder and other common components would not be aware of this odd configuration or the other databases). I think there are better ways to accomplish what you want to do.
2. Every domain will in 90% of cases a unique database; some of them could call a shared database.
Quote from: towerofbabel at May 21, 2009, 06:55 AMYes, quite complex tbh. In addition to the problem of supporting multiple databases with a single manager, there simply is no way to partition areas of the database like this, where some components come from database A and some from database B. Or rather, not without using modx as a development framework, in which case, it could definitely provide a foundation on which to build the solution, but such a scenario is currently beyond the scope of what we will be providing as turnkey multi-site/multi-domain solutions with Revolution.
3. I want to be able to share some (all?) Content Elements across these domains (specifically, Ditto, WayFinder, Google Analytics, XML Sitemaps - these are common elements that I always use, and I would want to administer them centrally for updates, etc).
So, stating things in another way, I envisage a single manager that "rules over" several "web" contexts (i.e., domain1.com, domain2.com, domain3.com, domain4.com, domain5.com), each context with its own database (mysql.domain1.com, mysql.domain2.com, mysql.domain3.com, mysql.domain4.com, mysql.domain5.com), and each context sharing a single pool of elements (chunks, snippets, plugins).
Does this sound overly complex? It would be a content management dream, I tell you, when running 10+ domains with fresh content on a daily basis.
.
MODX Staff
A single database can be extremely flexible, even for huge sites. Just don’t store every press release or product in your catalog inventory as a separate MODx Resource (i.e. page in the tree) if each site is gonna have thousands of them. Your scalability and the shared content features can be addressed in many ways; i.e. you can use custom tables for high-quantity content items, perhaps partitioned by site, or you could use a context for shared pages, or you could include shared view content from a domain dedicated to providing the shared data via web services that your individual sites talk to, or just make sure you partition your content appropriately based on expected quantities.
Ok, I see. a single database seems too unflexible for multiple, growing sites, but I can see how this can be handy for scenarios where a blog is on a subdomain, for example.
As a sort of shared-content web service makes more sense to me, but the idea is similar. You’d just need to create a snippet in the shared-content site that could deliver the content to other sites that had snippets designed to read (and potentially cache, filter, etc.) the content from the web service.
yes, I see. An immediate thought on reading this is "could storing chunks and snippets (elements) as static .php files which talk to a (particular) database depending on the context of the resource that calls the element solve this problem?", but I guess that is a fundamentally different paradigm to what we have here, and is totally and completely way over my head even though I formulated the question
As a sort of shared-content web service makes more sense to me, but the idea is similar. You’d just need to create a snippet in the shared-content site that could deliver the content to other sites that had snippets designed to read (and potentially cache, filter, etc.) the content from the web service.
.Context not found with key: %s
MODX Staff
Don’t use Alpha 6 as it’s really out of date at this point. The latest beta development branch is what you should probably work with at this point. The actual beta release is close in fact.