Note for self: Use https://github.com/snowmantw/Fe to test that a non content content directory works perhaps.

Aside from structural improvements this PR introduces the ability for a Ghost blog to define where the content directory resides. This is a step towards enabling Ghost to be used as a npm module.

I'm currently taking advantage of this PR for my own blog.

Let's say you want to use Ghost as a npm module, and want the content folder to exist outside of the npm module.

Create a repo with the following files (as I have in my blog repo:

- content/
- config.js
- index.js
- package.json

content/
The content/ folder is a direct copy of Ghost's content folder.

config.js
The config.js file is a copy of the config.example.js file, however it has additional configuration values that you can ovveride. (In actuality you can now override every config value if you so desire, allowing for greater flexibility without increasing the complexity of the code.)

Of particular interest is the new top-level property paths. Whatever you assign in here is used throughout the code base though the config module.

So this means that you can make this configuration:

production: {
  paths: {
      contentPath: path.join(__dirname, '/content/'),
  }
}

Assigning the location of the contentPath to exist where you desire, in this case relative to your config.js file.

index.js
The index.js is where you bootup your application and instantiate Ghost. This file can be a complete copy of Ghost's own index.js file.

package.json
This is where you define Ghost as a npm module.

My package.json looks like this:

"dependencies": {
    "ghost": "git://github.com/hswolff/Ghost.git#prod"
}

I'm using the GitHub dependency format for the moment as Ghost is not yet published on npm.

Another big caveot: because Ghost requires compiling the admin assets I actually do this within the module and upload those contents directly.

cd node_modules/ghost/
grunt production

This is one issue that is noted in #2078.

Hope this helps clarify!

Added tests.

Will merge just as soon as the build passes 👍

Passing now on all except Postgres. Seems this commit does break postgres, and it's not just a fluke of travis. I don't have postgres installed locally to test it unfortunately (although I do need to get that set up).

I'm pretty sure postgress is already mostly broken. I don't have it locally either yet. I'm just looking through all your comments and how the code has changed. One thing I don't understand... but easier to commend directly.