Upgrade path from 0.x to 1.x and ghost-cli improvements

Ideas
1

Hi GHOST Team,

I have had a bit of a frustrating go at upgrading GHOST this morning, so I’ll quickly explain what could be a bit better on the upgrade path.

Apologies if some of the stuff I want is very possible already, but it wasn’t obvious to me when I was upgrading, maybe I’m not the only one.

my 0.x setup

  1. pm2 runs ghost on VPN
  2. git hook restarts pm2 process when theme is pushed
  3. ssl is handled through letsencrypt and nginx (set up myself)

I have described a pm2 deploy with a git hook to restart ghost when I push my theme here: https://jonathanmh.com/node-js-ghost-theme-development-and-deployment/

This really didn’t seem very exotic to me until the upgrade.

Improvements for GHOST / ghost-cli

Overall I like the ghost-cli, but it’s painfully conservative and doesn’t allow a lot of --force when one dabbles with trying stuff out.

  • assume less about the stack, don’t force “required” setup steps
  • allow easy specification of an alternative linux system username (I had one)
  • detail instructions for setting config path of knex-migrator when upgrading (and that ghost migrate must be run afterwards)
  • do care about nvm, it’s become a bit of a must-have for running GHOST in the past (long engine update cycles, other deployment systems have fine support for it)

Improvements for Theme upgrade

  • possibly specify that image will turn into img_url $entity like img_url featured since the helper name looks like a replacement for image.

Summary

These are the things I’ve run into and I’m excited for the upgraded theme API. Depending on how many 0.x GHOSTs are still out there, it might not be very relevant to apply all of this, but improving on the installation indstructions will benefit every new user as well I assume.

We’re running a blog for our photo side-business at gegenwind.dk with a custom theme, so it’s actually awesome to have multiple authors and better custom querying with get.

Thanks for listening on twitter and for generally being awesome!

2

assume less about the stack, don’t force “required” setup steps

So the reason the stack is super locked down right now is providing support for a plethora of configurations will limit the features that can be added to the CLI (because the resources of the Ghost team is limited). That doesn’t mean you can’t create a PR to add support for additional configuration (as long as it doesn’t break the recommended stack :smile:) The readme for the CLI repo was recently updated, with more info about this, so feel free to check out the project goals!

detail instructions for setting config path of knex-migrator when upgrading (and that ghost migrate must be run afterwards)

With the CLI, this should occur automatically! There’s work being done to make setup steps more idempotent; see Issue 594

do care about nvm, it’s become a bit of a must-have for running GHOST in the past (long engine update cycles, other deployment systems have fine support for it)

This should be fixed, now that there’s no native knex-migrator dependency! See PR 505. Just make sure you run ghost with the correct node version :wink:

possibly specify that image will turn into img_url $entity like img_url featured since the helper name looks like a replacement for image.

If this is for the docs, you can suggest edits! There’s a button at the top right of the page in desktop mode. I don’t fully follow what you’re saying, although I think I understand the gist of it :grimacing:

3

RE the last one, I think he’s saying that the intuitive expectation of an {{image}} helper is an <img> tag – so maybe {{image_url}} would be clearer, given that it outputs a URL

Makes sense, and worth considering :slight_smile:

4

Thanks for the pointers, I’ll check them out!

Regarding the support: I understand that, it’s that the commands are fairly locked down for a reason, but there’s not always an obvious way to break out of it.

A good example in my world is create-react-app that defaults a lot of settings for you, but you can run eject and then every config is exposed and it takes a step back.

5

Almost!

My code in the loop before:

{{#if image}}
  <a href="{{url}}">
    <img class="post-cover" src="{{image}}" alt="">
  </a>
{{/if}}

My code after:

{{#if feature_image}}
  <a href="{{url}}">
    <img class="post-cover" src="{{img_url feature_image}}" alt="">
  </a>
{{/if}}

It just wasn’t obvious to me that the img_url is not the property, but the helper to get the URL of an image (which makes total sense now, especially if more complex media handling is coming).

6

also doing 0.x to 1.x. Can you please update the ugrade tutorial to explain that you will need to use different node versions during the process. e.g. when installing v1, you will need nvm install v8.9.0