Move core directory after install (ModX Revolution)

Hi there!

I’ve been experimenting with Revolution for a while now and would now like to move the core directoy out of the web-root.
Is there a tutorial for doing this with an already running installation?
Could somebody perhaps tell me what reconfiguration has to be done to achieve this?

Help would be greatly appreciated!!!

Cheers!

Siar

http://rtfm.modx.com/display/revolution20/Advanced+Installation

Hi!

Well I went through the official documentation...
but it is about how to move the core before installation

"Should you choose to rename or move the core, MODx recommends doing so before installing"

Well I didn’t follow that recommendation - so is it possible to move it afterwards?

Cheers,

Siar

I didn’t either, probably because this is my first attempt to use MODx. I find the best way to learn a new programming language, system, etc., is to try something "real world" in it. Toy programs ("Hello World") only delude one into thinking one knows the language when one is usually clueless!

Anyway, I found this thread because I have exactly the same issue: I want to move the MODx core AFTER having installed it.

If it is relevant, my reasons are both security and multi-site support. The ONLY thing I want the multiple sites to share is the MODx code (that can include add-ons, but I assume which add-ons are active would be reflected in the site’s MODx database).

This brings up another, related issue: When I first started trying out MODx, I got the impression that site/host dependencies (the URL of the site, the path to the site’s root directory, the DB name (user-id and password) were in the configuration file in the file system). This struck me as a very good state of affairs as it makes migrating a site from one host to another (or as many of us like to do, developing and testing on a local server and then uploading to a hosting provider) much, much easier — actually, "straightforward".

The same issue applies here. IF the core directory can only be moved easily prior to installation, it seems to me that implies site/host dependencies are being stored in the MODx database and not in the configuration file (where I happen to believe they should be). The exception I would make for that is the web site’s MODx configuration file. That could be stored outside the web root by having its name and path stored in the DB, but I would think a relatively trivial SQL query and update could be used to change that one item.

Well, I managed to do it, but there are no guarantees I didn’t miss something. The new location of my core directory is now outside the web root. I did some testing; that is:

- went into the front-end and browsed the site
- logged into the front-end as a user and browsed the site
- logged into the back-end as the administrative user

Here is what I did (some of this was based on browsing the database, some based on browsing the file system and some based on figuring out what I’d broken when something didn’t work — which happened a couple of times). I imagine that if one changed the directory name from "core" to something else in each of the places I mention changing its path, that would let you change the directory name at the same time (I’m almost certain of this). With the possible exception of the last step, the order you do these in doesn’t matter — just don’t try to use the site until you have finished:

1) Update the MODx mySQL database. There is a table called "modx_workspaces" (mine only had one row, but for safety, use the "where" clause anyway). You want to change the location of the "core" directory from what the initial value is to its new location. Mine, just as an example was:

UPDATE modx_workspaces SET path = ’/data/13/0/91/18/91833/user/93230/cgi-bin/modx/core/’ WHERE id = 1;

2) Move the core directory to its new location. If you are adventuresome, change its name as well!

3) Update the config.inc.php file in the core directory. Warning: There are two lines to be updated. Look for the lines with:

$modx_core_path =
$modx_processors_path =

and adjust the part of the path reflecting the location of the core directory.

4) There are three config.core.php files that need to be updated. There is probably a reason for having multiple copies of this file (performance?), but just one in the site’s root directory would seem less error-prone. Given <site-root> as the site’s root directory, update:

a) <site-root>/config.core.php
b) <site-root>/manager/config.core.php
c) <site-root>/connectors/config.core.php

Change the "define" statement to reflect the new location of the core directory. As an example, mine became:

define(’MODX_CORE_PATH’, ’/data/13/0/91/18/91833/user/93230/cgi-bin/modx/core/’);

5) Trash all the files, except the hidden ".gitignore" file from the .../core/cache directory. If you don’t things will break until you do.

That should do it. Those three config.core.php files (plus one in the setup/includes dir.) are the only places where the core name and location are defined.

You’ll have to edit the one in setup/includes if you upgrade to a new version of MODx.

In fact, just editing the setup/includes/config.core.php and running setup in upgrade mode (advanced if you want to edit db or the locations of the various contexts) is the easiest way to accomplish all those steps automatically.

Quote from: OpenGeek at Dec 19, 2010, 08:09 PM

In fact, just editing the setup/includes/config.core.php and running setup in upgrade mode (advanced if you want to edit db or the locations of the various contexts) is the easiest way to accomplish all those steps automatically.

I tried that out on my local server (Apache under Mac OS X). It more or less worked as advertised. I didn’t get any warnings about configuration files not being writable and I didn’t get an opportunity to change the Configuration key (which was my next step after changing the location of the MODx core — see next post).

I assume that the "traditional" install will catch up with the "advanced" install at some stage? I would think that most people who are doing web site development have some form of broadband Internet access and do not need to save download time at the expense of spending time un-compressing and moving files around manually.

It also seems logical that many (most?) people just starting to get their feet wet with MODx would start off with a traditional install and then want to progress to more advanced (and thus usually more complex) configurations.

Last night I started in the next logical step after moving the MODx core directory outside of the web root: I turned the installation on my hosting provider into a multi-site setup. Today I did the same on my local set up (the two are almost, but not quite, mirror images of each other).

There appear to be two things that need to be taken care of to create a multi-site set up (of the type I wanted).

First, this is the Multi-site setup I want (and set up):

- The core "code" and associated files are shared among the sites.
- Each site is in fact a separate site with its own domain name (i.e. not subdomains and not directories in a single domain). They are, however, hosted on the same service provider and under the same account. That gives (program, but not web browser) access to files outside the web roots.
- Each site is independent of the others and simply shares the core code.

It would be nice to be able to share the connectors and manager code as well — perhaps that feature will be arriving in the future.

The two things:

- The cache is located in the core directory, so it is necessary to avoid having one site over-write or accidentally pick up another site’s cached file
- There is a configuration file located in the core directory (.../core/config/config.inc.php). Since it is particular to a given site, there need to be distinguishable versions of this file for each site.

Both these things are accomplished using a "Configuration key" associated with the site. This key can be set during the installation process, but I ran into a problem that I had to fix — perhaps because of starting out with a "traditional" install. In any case, you can try using setup and if you have issues, here is what the final setup needs to be.

WARNING: If you are going to try out "setup", then before embarking on this process, make a backup copy of .../core/config.inc.php. Its contents reflect the current, single installation and if things muck up, you will want to be able to fix them easily (and this is the file that will get over-written).

Pick a Configuration key for your site. I suggest making it short and reflecting the name of your site. It will be used as a directory name and also as part of a file name, so stick to lower case letters with no punctuation. I used "wccr" for the site I have been experimenting with (it stands for "Women’s Club of Costa Rica").

As with all such manual changes, the site will be inconsistent until all of them are complete. The order you do these things in doesn’t matter:

1) Change the three configuration files in your site’s <site-root> directory:

a) <site-root>/config.core.php
b) <site-root>/manager/config.core.php
c) <site-root>/connectors/config.core.php

by changing the Configuration key. Using my example (in which I am using "wccr" as the key), the define for the Configuration key becomes:

define(’MODX_CONFIG_KEY’, ’wccr’);

2) In .../core/config/ change the name of the configuration file from "config.inc.php" to "wccr.inc.php" (i.e. substitute your Configuration key for the "config" part of the file name). You don’t need to change the contents of the file as you did that when you moved the core directory.

3) Delete everything (except the hidden .gitignore file) in ".../core/cache". Create a directory with the same name as your Configuration key (i.e. I created one called ".../core/cache/wccr"). Make sure it is writable.

That should do it!

You can now create additional site installations that share the same core files. Obviously the Configuration key for each site needs to be unique.

Quote from: jrg at Dec 20, 2010, 01:29 PM

First, this is the Multi-site setup I want (and set up):

- The core "code" and associated files are shared among the sites.
- Each site is in fact a separate site with its own domain name (i.e. not subdomains and not directories in a single domain). They are, however, hosted on the same service provider and under the same account. That gives (program, but not web browser) access to files outside the web roots.
- Each site is independent of the others and simply shares the core code.

It would be nice to be able to share the connectors and manager code as well — perhaps that feature will be arriving in the future.

The two things:

- The cache is located in the core directory, so it is necessary to avoid having one site over-write or accidentally pick up another site’s cached file
- There is a configuration file located in the core directory (.../core/config/config.inc.php). Since it is particular to a given site, there need to be distinguishable versions of this file for each site.

Both these things are accomplished using a "Configuration key" associated with the site. This key can be set during the installation process, but I ran into a problem that I had to fix — perhaps because of starting out with a "traditional" install. In any case, you can try using setup and if you have issues, here is what the final setup needs to be.

Indeed, traditional is not meant for these kinds of advanced configurations (especially moving the core), thus we have the advanced distribution to avoid these manual steps. Traditional is really meant for shared hosting environments that have limited access (e.g. FTP only, no SSH).

That said, even though having multiple configurations, each with their own database, manager, connectors, etc. is possible already, since components have to be installed into each configuration, this is still not recommended until we introduce the concept of multiple workspaces. Workspaces will basically just provide a way to isolate a set of configuration specific component packages and related items. At the moment you would have to install the components manually into each configuration and make sure they were all using the same versions of specific components since the files shared in your assets/components and core/components directories would all need to be in sync across every site.

Quote from: jrg at Dec 20, 2010, 01:29 PM

Pick a Configuration key for your site. I suggest making it short and reflecting the name of your site. It will be used as a directory name and also as part of a file name, so stick to lower case letters with no punctuation. I used "wccr" for the site I have been experimenting with (it stands for "Women’s Club of Costa Rica").

1) Change the three configuration files in your site’s <site-root> directory:

a) <site-root>/config.core.php
b) <site-root>/manager/config.core.php
c) <site-root>/connectors/config.core.php

by changing the Configuration key. Using my example (in which I am using "wccr" as the key), the define for the Configuration key becomes:

define(’MODX_CONFIG_KEY’, ’wccr’);

2) In .../core/config/ change the name of the configuration file from "config.inc.php" to "wccr.inc.php" (i.e. substitute your Configuration key for the "config" part of the file name). You don’t need to change the contents of the file as you did that when you moved the core directory.

3) Delete everything (except the hidden .gitignore file) in ".../core/cache". Create a directory with the same name as your Configuration key (i.e. I created one called ".../core/cache/wccr"). Make sure it is writable.

Advanced setup handles all of this for you. None of these steps are necessary using the advanced distribution. Actually, if you were not moving the core/, traditional setup does handle a change to the MODX_CONFIG_KEY, which you can choose in the first step of the setup process. But again, multiple configurations on a single core is possible, just not recommended yet.

You could accomplish this with Contexts and Access Permissions using a single configuration though, and then the component packages would be shared across the sites via a single installation.