I’ve discovered an interesting, and reproducible, bug with MODx 2.7.3 where the Manager will refuse to load if you are running multiple sites from the same MODx install, and you log into the Manager from a site that isn’t the main site.
Say you’re running site1 dot com and site2 dot com on the same MODx install, and you log in to the Manager by visiting site2 dot com/manager instead of site1 dot com/manager. The manager won’t load (the left-hand listing of resources and elements is blank).
Worse, from that point on, you can never again log into the Manager on that MODx install, from any URL, until you rerun Setup and do an upgrade install.
I’ve encountered this problem on Mac and Windows browsers (Chrome, Safari, Firefox) and it’s 100% reproducible. Log into the manager from site2 dot com/manager, boom, manager is forever broken until you rerun setup.
Can you look at your browsers’ developer console for errors? Parts of the manager not loading typically indicate errors, and seeing those will help sort things out.
Does clearing your cookies help when your in the broken state, instead of rerunning setup?
I didn’t look at the console for errors. Next time it comes up I’ll do that.
Clearing cookies and cache made no difference whatsoever (that was the first thing I tried). In fact, moving to a completely different computer and trying to log on also made no difference.
I have a project where I run multiple sites (different domain names, including language derivations of these two domains) within the same modx instance, and I tested now to login on each domain to the manager. No issues at all. I am running on Modx 2.7.3-pl.
Just for the record, I am using XRouting. No changes at all made to the htaccess file.
I’m running two different installs with MODx 2.7.3-pl that are running multiple sites, hosted in two different places (one on a Dreamhost VPS, one on a Hostgator shared server). Both exhibit this problem, and it’s consistently reproducible. Clearly, there’s some difference between what you’re doing and what I’m doing!
I’m also using the MODx .htaccess file. Here’s the relevant bit of my index.php file from one of the installs:
/* Initialize the default 'web' context */
/* $modx->initialize('web'); */
/* Setup context mapping */
switch(strtolower(MODX_HTTP_HOST)) {
case 'thinkbeyond.us:80':
case 'thinkbeyond.us':
case 'www.thinkbeyond.us:80':
case 'www.thinkbeyond.us':
// if the http_host is of a specific domain, switch the context
/* $modx->switchContext('thinkbeyond'); */
$modx->initialize('thinkbeyond');
break;
default:
// fallback, go to main context
$modx->initialize('web');
break;
}
I am not using XRouting on my installs. I wonder if that’s the difference?
It might well be.
XRouting works based on configurations that are specific to each context. Meaning that you just have to add those configurations and XRouting will take care of the rest.
I’m reluctant to re-create the Web sites with a new extra, since they’re working now as long as I remember to log in to the manager with the “proper” URL. If I build a new install, I might investigate XRouting, but as it stands now I’m hesitant to mess with what’s (mostly) working.
I am assuming that the code that you posted above is a plugin, right?
As an example, XRouting is a plugin and it is linked with the following events (when editing a plugin, you have an ‘events’ tab):
OnContextRemove
OnContextSave
OnHandleRequest
OnSiteRefresh
This is when the plugin should run.
You should also add the event handling code so the plugin can have different behavior (if needed) according to each event.
You may only need ‘OnHandleRequest’ event for now.
You may need to change your code in order to have a proper context switch.
Have a look at the XRouting code for the lines 127 until 141. I believe it will lead you to the right direction.
You need to switch context. I think that you don’t need to initialize a context. Then you need to set a culture key and a locale.
You can also have an overall read the XRouting plugin so you can check cache handling techniques. Most of the code you need is here. The difference is that you set the domains directly on your code, where XRouting checks for system settings on each context.
I know that you don’t want to mess up with live sites, but I believe that if you download a copy of it to your pc, remove this index.php modification, and try to setup XRouting with local DNS (site1.local and site2.local), you will end up saving valuable time and avoid potential problems in the future.
If you modify your code, you will have to keep adding it on every modx update, etc. Unnecessary work for you.
It might worth investing your time on it. I can help you with that on this topic if you are willing to try.
If you want to play with local DNS, you can edit your windows hosts file and add two lines:
site1.local 127.0.0.1
site2.local 127.0.0.1
The localhost website will reply now to those two DNS names, and modx will handle the two requests just like a live site with two DNSs.
That definitely makes sense, and seems like the most logical approach going forward. When the time comes to update these sites (any news on the MODx 3 front?), I’ll definitely not keep doing it the way I am now.
It’s interesting that the “official” MODx technique to host multiple sites involves editing the index file, and has this particular weird bug.
Modx3 should reach beta stage really soon as per some reputable and very old members of modx community that are main code contributors. Anyway, modx 2.8.0 will arrive first I think.
