In an effort to become acquainted with Mura CMS, I have been spending some time looking at the overall way the application is structured - what is included into what, where settings are stored or specified, and what the options are for modifying the default way things are done, in order to retain some of the in-house workflow concepts I have developed over the years.
One of the main aspects of my production workflow involves the easy use of both a local and live server, running from the same database. Generally, when starting a new ColdFusion project, I like to:
- Set up a local directory for the project, where i can work in the browser via a local host url
(something like http://172.16.17.5:8500/SiteName/wwwroot/ or http://localhost:8500/sitename/wwwroot )
- Set up a database on my live production server at www.GoWestHosting.com
- Create a DSN on the live server, pointing to the database
- Create a DSN on my local CF server, pointing to the same remote database
Now I can work locally and view my changes instantly without the need for FTP.
Or, as needed, I can push changes to the live site with a few clicks, and view the changes there as well (such as posting work for clients, or working with routines that require server-specific settings, launched from the site's "real" location)
My application.cfc contains both sets of DSN info, and uses a switch, based on the current cgi. server variables , to determine which DSN to run from, along with other server specific settings (such as google map key). So, wherever the site is viewed, my application 'knows' which content paths and other settings to use for each page request or query.
(So... what about MuraCMS?)
One of the first things I noticed when installing Mura locally was the way that it cached the local directory structure. So if my Mura site was installed in a subdirectory of the local site, e.g. http://localhost:8500/sitename/wwwroot/test/ , Mura would store the setting "/sitename/wwwroot/test" automatically, and prepend this path to all required assets. Wonderful. Superb. But...
Then I pushed the Mura files to the live server, uploading the works via FTP. And found I had a problem. That path was still being prepended to all assets... but didn't exist.
On the live server i was simply working from http://sitename.com/test/ , so everything was instantly broken - images, javascript, css.
Unlike my own usual practices, where all primary templates or pages live in the site root, Mura is designed to use 'root relative' paths, rather than location relative, which makes sense if content will be served from different directory levels.
So instead of simply looking in ../css/ for a css file, it wants to use the path /sitename/wwwroot/test/css
(So... how did I fix this? Get to the point already... )
Half of any solution is identifying the problem. In this case, I needed to find out "how to use two different sets of configuration variables" , and set out to find the answer.
On setup, mura creates and populates a file called 'settings.ini.cfm', which is a simple text file with variables and values stored one per line. And inside, I could see the paths were being stored as text strings. Cool. Now I know where it lives... but how to change it on the fly, and keep two different versions?
I asked my question to the very friendly, patient guys on the Mura Show , but must not have asked correctly, or clearly enough. I came away thinking the solution was to set up a domain 'alias' and somehow map a direct IP to my subfolder locally , which doesn't work since you can't put paths in the Windows hosts file... and i got into a right frustrating mess.
Deciding to take another crack at it with fresh morning-coffee eyes, I got smart and did a bit of googling. And I found this, the settings.ini reference from the Mura site: http://docs.getmura.com/index.cfm/installation-set-up/settingsinicfm-reference/
and... AHA! a classic RTFM moment.
(finally... the fix !)
wouldn't you know it, the very first line of the settings.ini.cfm file is for the "mode", (which i completely overlooked before, and the Mura team must not have thought of in reference to my seemingly vague questions. )
The default mode is 'production' and beyond the first few lines, all settings in the file are under a heading of [production]. The light started coming on right about now... they really did think of everything!
So, all I had to do was create another grouping, and change that master 'mode' setting. I simply duplicated all the lines below [production], added a new heading of [localdev] , and changed the settings to match those of my local server. (I also changed 'production' paths to match the settings of my live production server with the simpler root directory structure)
Just a few more steps - upload the changed file to the live server, and click 'reload application' in the Mura admin. Then, change my local copy of the settings.ini.cfm file to 'mode=localdev' , and click 'reload application' in my local admin as well.
This caused the local settings to be loaded for the local site, and the production settings to be loaded for the production site ... and i am back in business, working in both locations with ease!
Bearing in mind that any uploaded images will need to be manually copied with FTP, and some other things might need a little hand-holding, I am very pleased to be back in business with the freedom to work the way I am used to, with live, functioning copies of the complete site on both my local server and the live location.
The only caveat at this stage - I'll have to be careful not to upload the settings.ini.cfm file, since I still don't have an 'automatic' switch for which group of settings to use. But as long as my production version of the file says "mode=production" and my local file says "mode=localdev" , I should be good to go.