Ghost 1.x compatibility for Heroku

[mars]

Provides Ghost 1.x made Heroku-compatible with a new config adapter, MySQL database, & updated S3 storage.

The new Ghost 1.x config.production.json file is generated as the dyno starts-up via .profile script using a revised version of your original config.js.

I updated the README too, but this probably needs a some peer review and testing/verification before merging.

[ifvictr]

@mars You removed the option for a one-click install? :cry:

[mars]

The one-click install is problematic because it makes upgrading even more challenging, especially in case of a security vulnerability.

The Deploy to Heroku button leaves the heroku git remote empty. Here's what happens with an app deployed from the button on master:

$ heroku git:clone -a ghost-button-test
Cloning into 'ghost-button-test'...
warning: You appear to have cloned an empty repository.

So, the only way to get the source code to perform a patch or upgrade is to come back to this repo, clone it, commit code updates, set the heroku git remote, and then deploy. (Not the simple "just clone it" instructions originally given.)

Basically, it's not responsible/safe to just deploy this Node app and never plan to push updates. Wordpress got itself into a security mess back before it had auto updates. Trying to avoid that here.

Perhaps I shouldn't have made deployment change part of this PR. An additional postdeploy script is still required to run the required knex-migrator init --mgpath node_modules/ghost step to initialize the MySQL database.

How does the maintainer prefer to proceed? I can add the database migration in a postdeploy script of app.json, if the deploy button is still favored despite the security considerations.

[ifvictr]

Oh okay, got it. Also, I noticed a typo in the PR in the README. "you nay beed" should be "you may need".

[mars]

Apologies for the closed/reopen noise.

I worked through the upgrade from 1.5.0 → 1.7.1 and made a few revisions to improve the update flow:

• Database migrations are run automatically using a release phase process (later removed to allow postdeploy script to work correctly)
• Tried my darnedest to make this repo co-operate with Ghost CLI, but that CLI does not understand this npm/node server.js app.

[cobyism]

First of all, I want to thank you @mars for submitting such a fantastic PR. I want to find a way to merge this change in so this project can continue post-v1.X, and I really appreciate your contributions here. 🙇 ⚡️ ❤️

In terms of the specifics, I’d really like to keep the "deploy to heroku" button option, despite the issues associated with subsequent clones being empty git repos. My thinking is that I’d rather document this as an unfortunate bug on Heroku’s part, and retain the possibility for anyone to deploy a Ghost blog for free, even if they don’t know how to use the command-line to do so.

Other than that, I feel like the main thing I’d like to include as part of this change is a really clear section in the README outlining the fact that MySQL addons are required, and that they’ll be limited in capacity and may require moving to paid options if using Ghost on Heroku at any kind of scale—the trade-offs of which may be undesirable, given the options for paid hosting elsewhere (e.g. https://ghost.org/pricing/).

@mars What do you think the next steps should be?

[jozic]

my 2 cents would be nice to keep 0.11.11/postgres version (maybe in a separate branch) and support 1.x/mysql people who want it cheap and okay with 0.11.11 can continue using it, and rest can try 1.x with mysql doesn't sound like 0.11.x version is going to be updated much, so hopefully not much work to keep it alive

[mars]

Great to hear from you @cobyism 🎩 The deploy button fiasco is something I hope to see fixed someday. Until then, we'll make it as easy as possible to work-around.

Deploy button is now working thanks to a post-deploy MySQL database wait trick. Try it out!

Also cleaned-up the mess I made of the README, including a point about upgrading to a paid database plan and streamlined "Updating source code" section.

Running as a free app with a free MySQL database is very limiting for performance. The previously implemented free Postgres offering is quite limiting too. With minimal paid dyno & database, Ghost 1.x on Heroku is $17/month. Ghost Pro starts at $29/month. The trade-off is that the Ghost folks are always maintaining, improving, protecting the app for their Pro customers. When someone deploys Ghost as a Heroku Node app, no-one automagically patches vulnerabilities for them 🐞

I think this is ready to go now.

[mars]

@jozic Thats a good idea to keep 0.11.11 deployable. The easiest way would be for @cobyism or another collaborator on this repo to create a 0.11.11-lts branch from master today, and then add a second "Deploy to Heroku" button on the master README to create 0.11.11/Postgres apps from that branch.

[legendtang]

@mars Thank you! From your code I successfully setup with just one problem. It says "You do not have permission to edit settings." when I touch any setting items. Any thoughts on this?

[mars]

@legendtang I've reproduced this error too. Looks like a poorly worded error that covers-up the fact that the database ran out of connections on the free plan.

I solved this "permission" error by upgrading MySQL/JawsDB to the cheapest paid plan.

[mars]

Figured out how to configure the connection pool size. A fresh deploy seems to work great, now.

[legendtang]

@mars Thank you mars! It works like a charm. Recently Ghost v1.9 seems to adjust the DB structure so re-deploying seems not working, which requires knex-migrator. Could you please point a direction on how to migrate without CLI during deploying?

[mars]

@legendtang you can add a Procfile containing:

web: npm start
release: knex-migrator migrate --mgpath node_modules/ghost

Commit that file and push to Heroku.

The release process will run for every deployment.

[legendtang]

@mars Great! I think second line should be changed to

release: knex-migrator migrate --mgpath node_modules/ghost

Mine does not recognize :latest.

[siwalikm]

@legendtang did you try @mars's forked version?

Here's a one click link for it.

[legendtang]

@siwalikm Yes, and my forked version is also based on mars' one. Should consider add this line.

[mars]

@legendtang @siwalikm adding that knex-migrator migrate release command to the Procfile results in undependable one-click button deployment. You're welcome to add it to your app after initial deploy.

[legendtang]

@mars Perhaps two branches solve this problem? One is for dirty deployment.

[cobyism]

❤️ Thanks again for your awesome work on this, @mars. I’m going to go ahead and merge this in so that we can keep things moving forward. I think it’d be good to also get a tagged branch and separate deploy button for the 0.11.12 LTS release in case people want to keep using that too, but that’s another issue altogether. 😅