Check the config.core.php file in the Manager directory. Also, double-check *all* the paths in config.inc.php.
Don't forget to delete the cache files and clear your browser cache and cookies.
-
☆ A M B ☆
- 2,475 Posts
Ah, interesting... after moving the core directory above the docroot (to /home/myuser/core instead of /home/myuser/public_html/core), most (all?) of the package management installs fail... they're all looking for the core in the public_html directory... hmm....
-
MODX Staff
- 10,725 Posts
Edit the workspace path in modx_workspaces, or run setup as an upgrade.
-
☆ A M B ☆
- 2,475 Posts
Got it. Yeah, I was just reading that in Bob's book: there is a core path stored in the database. Working now, thanks!
Next step: move the core directory above the web root and rename it.
Just do it, and edit config.inc.php and the three config.core.php files:
config.core.php
manager/config.core.php
connectors/config.core.php
-
☆ A M B ☆
- 2,475 Posts
Yep, already done. Thanks for the help!
Hi Everett,
does it really make sense to put the manager above the web root? I think you nevertheless need an web-access which you maybe have solved by manager.yourdomain.com which is assigned to your manager-folder above the web root. But in this case manager-access is still possible via the web or did you solved this by another way to make the manager-folder accessible for you to work?
Do you have problems when updating modx (especially when you also renamed and moved the core-folder)? Or do you just have to rename your downloaded folders before uploading them to your new destinations?
-
☆ A M B ☆
- 2,475 Posts
You can't have the manager above the web root: it must be accessible via HTTP. You can move the core folder above web root. I think it does make sense to do both if security is a priority on the site: MODX is not as easy to fingerprint (say as WordPress, which hard-codes paths and URLs), but once your site technology is known, it gives the potential attacker lots more information on how to break in. Sometimes all that stands between a hacker and total p0nage of your site is knowing what you're running and a quick search on exploit-db.com. Download the exploit, fire up Metasploit, and poof: your site is owned.
Moving the core directory above web root is pretty standard -- most security audits of sites will recommend things like that (at least, all the code reviews I've had included that, no matter what the technology was). It's more thorough than blocking access to the directory via .htaccess.... but yes, it makes updating more time-intensive. You basically have to update the 3 primary directories one at a time using a "cp -fr" command for each (core, manager, connectors). And some of the Add-Ons (and sometimes even the setup process itself) have incorrectly referenced paths, so once I had to move things to the standard locations, then run the updates, then move them back to a custom location.
So yeah... it does make things a bit more involved. Security always is at odds with convenience. I'd say that it's a happy balance if you put .htaccess restrictions on your core folder and limit access to the manager folder by IP address. That beefs up your security posture considerably and keeps your update process straightforward.