The intent of the `content_dir` config option is to limit what is available to the end user. My thought was that for the carrot blog cms, we'd only really want to give the end user the blogging content to view and edit. I now realize that there are probably some more directories that need to be shown such as press or project overviews, so maybe it's a good idea to change to it an array of paths. But, there are still some pieces of dynamic content we might still want to edit ourselves and not allow changes through the cms.

To clarify, `config.project_dir` does default to `process.cwd()`. `project_dir` can be overridden by adding a `config.json` file into the ___roots-cms___ directory with `{project_dir: '/where/my/roots/project/is'}`. I added this because in production I needed to tell the CMS where the roots project onto the server. I haven't tried figuring out how to run the app/`pm2` process in the carrot.is directory itself, so if I can do that, I probably don't need that additional config file.

The rest of the config values are loaded from the config file in ___the roots project___, which roots-cms finds based on `project_dir`.

For reference, [here](https://github.com/carrot/roots-cms/blob/extensibility/lib/config.coffee#L4-L18) is where the configs are loaded.

@jenius Regarding architecture, it actually works fine loading all the content from the root of the roots project. This is because I sort all the content into categories by the parent director(y/ies) of the content file relative to the root of the project. The issue is that if there are nested directories I get several categories for the same top level directory (e.g. 'blogging/announcements', 'blogging/welcome', 'blogging/industry'). I think I'll need to build a more robust model of categories/directories to accommodate for when they're nested, it'd be nice to basically recreate the folder navigation hierarchy on the front end.