Topic: Manager Context  (Read 3332 times)

Pages: [1]   Go Down

#1: 3-Dec-2007, 06:31 PM


Adam Wintle
Posts: 70

WWW
Two short questions:

With 0.9.7 is it possible to have the manager as a subdomain via and separate context?

and is it possible to change the name of the manager, for example: mydomain.com/admin instead?

#2: 3-Dec-2007, 09:13 PM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,949

damn accurate caricatures...

WWW
With 0.9.7 is it possible to have the manager as a subdomain via and separate context?

and is it possible to change the name of the manager, for example: mydomain.com/admin instead?

Yes and yes.  I've run one with the manager as area51/.  I have not run a manager as a standalone subdomain yet, but I don't see any obvious reasons why it wouldn't work as is.

In fact, I'm running a single core/ located outside of my web server document root for maximum security (and managed by SVN directly), and several different configurations (different databases, caches, managers) from that single core successfully right now.
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa

#3: 4-Dec-2007, 05:58 PM


Adam Wintle
Posts: 70

WWW
Quote
I'm running a single core/ located outside of my web server document root for maximum security (and managed by SVN directly), and several different configurations (different databases, caches, managers) from that single core successfully right now.
wow, that sounds hyper secure - what's the nature of the website that needs this much security? - or is it just because you can?

Do you know if this sort of stuff will be documented/wikied in conjunction with the 0.9.7 release? - has 0.9.7 got any documentation yet?

#4: 4-Dec-2007, 08:09 PM

Foundation

rthrash
Posts: 11,348

WWW
Documentation for 097 will be much more extensive. The advantage of running one core out of webroot extends far beyond security, though security is certainly a very good reason on it's own. You can run multiple sites off one core install, so an upgrade for one site upgrades them all.

For some preliminary ideas of some of what's going to be possible with 097, I suggest starting at Jason's blog post then peeking at the 097 Roadmap.
MODx is a content managmeent framework that allows web professionals to turn over sites to end-users for daily maintenance without worrying. Please help us help you when asking for assistance and read the wiki. Searching the forums from the top level helps, too.
Ryan Thrash
MODx Co-Founder
Principal @ Collabpad
work productively.
work intelligently.
work together.

#5: 24-Feb-2008, 06:00 AM

troycomp14
Posts: 1

I am new to modx and I am interested in how to setup multiple sites under the one install.  eg: www.somesite.com.au and www.othersite.com.au
Thanks,
Troy

#6: 23-Aug-2008, 10:45 AM

Moderators

AHHP
Posts: 397

Salut capitan,

WWW
In fact, I'm running a single core/ located outside of my web server document root for maximum security (and managed by SVN directly), and several different configurations (different databases, caches, managers) from that single core successfully right now.

i have a little information about security, would someone tell me how locating the core to outside of document web root cause more security?

#7: 23-Aug-2008, 11:44 AM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,949

damn accurate caricatures...

WWW
In fact, I'm running a single core/ located outside of my web server document root for maximum security (and managed by SVN directly), and several different configurations (different databases, caches, managers) from that single core successfully right now.

i have a little information about security, would someone tell me how locating the core to outside of document web root cause more security?
It would be unavailable to the web server directly, so any exploits depending on accessing a script would be rendered useless on everything stored in the core.  Of course, sloppy programming could still lead to vulnerabilities despite having the files unavailable to the web server document root, but that is always the case regardless and it never hurts to make it that much harder to exploit.
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa

#8: 30-Aug-2008, 11:09 PM


Adam Wintle
Posts: 70

WWW
Hello again - this thread's nearly nine months old!

I've just installed Revolution Alpha 3 and I'm still trying to get my head round Contexts.

When prompted to specify the manager context location and the web context location I decided to make some changes, my server path leading to the MODx installation is setup like something like this: /bla/blabla/blablabla/bla/12345/domains/firstdomain.com/html/ and I wanted to change the location of just the web context to this:  /bla/blabla/blablabla/bla/12345/domains/otherdomain.com/html/ leaving the manager context on firstdomain.com

After changing the web context path I was expecting to be able to go to otherdomain.com and be able to view the document with ID 1 - but instead I get a 403 Forbidden page error and fins a config.core.php file at its location containing:
Code:
<?php
define
('MODX_CORE_PATH''/bla/blabla/blablabla/bla/12345/domains/firstdomain.com/html/manager');
define('MODX_CONFIG_KEY''config');
?>
I was quite pleased that MODx had been able to put a file somewhere completely different on my sever, but otherdomain.com wasn't showing the website, instead firstdomain.com/ was showing the web context, and also firstdomain.com/manager was showing the manager context.

I'm not sure what I've done wrong here, anybody got an idea?

Also, what is the AJAX Context, and what would the purpose of changing its location be?

Finally, once I'm in the manager I can add a totally new context, such as thirddomain.com, which I can then start adding documents into - but how can I make /bla/blabla/blablabla/bla/12345/domains/thirddomain.com/html/ load this context?
« Last Edit: 30-Aug-2008, 11:22 PM by Mallmus »

#9: 31-Aug-2008, 09:45 PM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,949

damn accurate caricatures...

WWW
After changing the web context path I was expecting to be able to go to otherdomain.com and be able to view the document with ID 1 - but instead I get a 403 Forbidden page error and fins a config.core.php file at its location containing:
Code:
<?php
define
('MODX_CORE_PATH''/bla/blabla/blablabla/bla/12345/domains/firstdomain.com/html/manager');
define('MODX_CONFIG_KEY''config');
?>
I was quite pleased that MODx had been able to put a file somewhere completely different on my sever, but otherdomain.com wasn't showing the website, instead firstdomain.com/ was showing the web context, and also firstdomain.com/manager was showing the manager context.
It should have also extracted index.php to this location.  I assume you got the advanced package? It is the only package that is meant for deploying the reference contexts into custom locations.  And I assume that you did not select "files already in place" on the installation options page? This would only apply if you didn't change the default locations.

Also, what is the AJAX Context, and what would the purpose of changing its location be?
All AJAX manager requests are routed through the connectors context, and it can serve as a general purpose context for allowing custom interfaces to take the same actions as can be made in the reference manager implementation that is provided.  And the purpose is the same as the rest, to allow the physical location to be customized for whatever reason.

Finally, once I'm in the manager I can add a totally new context, such as thirddomain.com, which I can then start adding documents into - but how can I make /bla/blabla/blablabla/bla/12345/domains/thirddomain.com/html/ load this context?
You can either copy the index.php and config.core.php to this location and modify it to load the specific context in the $modx->initialize('web') statement, or you can serve the domain from a single location and use a plugin to detect the http_host and then use $modx->switchContext('myCustomContext'); to dynamically change it.  Please note there are significant improvements in this functionality in recent revisions (after alpha 3).
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa

#10: 1-Sep-2008, 08:40 PM


Adam Wintle
Posts: 70

WWW
Quote
It should have also extracted index.php to this location.  I assume you got the advanced package? It is the only package that is meant for deploying the reference contexts into custom locations.  And I assume that you did not select "files already in place" on the installation options page? This would only apply if you didn't change the default locations.

Actually I tried the modx-2.0.0-alpha-3.zip - the modx-2.0.0-alpha-3-advanced.zip file only has a core and a setup folder, should I overwrite modx-2.0.0-alpha-3.zip's core and setup folders?

Is there an SVN location for these and also the 0.9.6.2-rc2? I can't seem to find it anywhere....

#11: 2-Sep-2008, 09:58 AM

Foundation

OpenGeek
MODx Co-Founder
Posts: 6,949

damn accurate caricatures...

WWW
Actually I tried the modx-2.0.0-alpha-3.zip - the modx-2.0.0-alpha-3-advanced.zip file only has a core and a setup folder, should I overwrite modx-2.0.0-alpha-3.zip's core and setup folders?
Remove everything and load the advanced package; with the regular package, everything is automatically put in the same location as a traditional MODx installation (i.e. index.php in the root for web context, manager/index.php for mgr context, etc.).  If you change the locations in the setup of the regular package, you need to manually move the files associated with each context to the appropriate physical location; the advanced package will attempt to copy the files from the core transport package for each context to the location specified in the setup.

Is there an SVN location for these and also the 0.9.6.2-rc2? I can't seem to find it anywhere....
Current Revolution branch is @ http://svn.modxcms.com/svn/tattoo/tattoo/branches/revolution/
Current 0.9.6.2 is available @ http://svn.modxcms.com/svn/tattoo/tattoo/trunk/

There are currently no tags on the alpha/beta/RC releases in SVN, but thanks for the reminder; those need to be tagged under releases.  However, please note that the various distributions of Revolution are not just SVN snapshots; they require a build using Ant to be produced like the ones available for download of alpha-3.
Jason Coward
MODx Co-Founder
xPDO Founder
CTO @ Collabpad
work productively.
work intelligently.
work together.
Light is just a vibration of a note too. Everything is. You've got to keep that in mind.
  Frank Zappa
Pages: [1]   Go Up
0 Members and 1 Guest are viewing this topic.