3 ms·

Personally speaking as a developer, I had not-so-great experience building a Ghost blog last year. The choice of Handlebars templates brought all the usual head

Personally speaking as a developer, I had not-so-great experience building a Ghost blog last year. The choice of Handlebars templates brought all the usual headaches of stringly typed language: no IDE feedback on what’s in scope, unclear variable declarations, and the ever present feeling of a temperamental magic. The Ghost dev team has opted for a strict control over how local installs can be modified, or really, how they can’t. “Ghost Doctor” is more like a cop, and runs a level 3 diagnostic on startup, refusing to run if the engine has been tampered with in a way that the dev team deems unacceptable. And there is no off switch either. You can’t, for example, modify any of the template data fetching helpers. The only real way to customize the template language is by switching Ghost to a headless mode and praying someone out there built a starter kit that looks good. And don’t even think about changing the permissions of files within the engine. This especially burnt me when I tried to implement SVG placeholders that get generated on image upload. The suggested solution is to do all asset pipeline modifications via local web servers and shuttle data back and forth. The last straw was when I wanted to add custom fields to posts. The ruling opinion at the time was to fork the engine, modify the schema, add the new fields to the admin UI, and then modify your custom templates. Just remember that you’ve now opted out of automatic updates and will be maintaining your fork indefinitely. Believe me, I am sympathetic to why the Ghost devs chose this path. It’s easier to maintain a smaller and more predictable platform. I just couldn't help but feel silly using software with so many arbitrary and artificial restrictions.

nightpool 4y ago
> You can’t, for example, modify any of the template data fetching helpers. how is this different from forking the engine? I'm not super familiar with Ghost's internals, but wouldn't this basically count as a fork anyway? Seems like you either have the option to change the internal engine code, or you don't. I think it makes sense that there aren't a lot of "in-between" options, because that's just asking for unannounced breakage when your "auto-update" system decides to overwrite whatever files you've already messed with, or change the files that are downstream from that one (breaking compatibility)
- throwaway284534 4y ago
  That’s pretty accurate. I suppose what I should’ve wrote was that there a some template data helpers that can’t be modified or reimplemented from the vantage point of non-Ghost contributor. And somewhat more painful, adding new Handlebars helpers can’t be done within a custom theme. This would mean either forking the engine or switching over to the headless API mode and building something like a Next.js front-end.

nightpool 4y ago

> You can’t, for example, modify any of the template data fetching helpers. how is this different from forking the engine? I'm not super familiar with Ghost's internals, but wouldn't this basically count as a fork anyway? Seems like you either have the option to change the internal engine code, or you don't. I think it makes sense that there aren't a lot of "in-between" options, because that's just asking for unannounced breakage when your "auto-update" system decides to overwrite whatever files you've already messed with, or change the files that are downstream from that one (breaking compatibility)

throwaway284534 4y ago
That’s pretty accurate. I suppose what I should’ve wrote was that there a some template data helpers that can’t be modified or reimplemented from the vantage point of non-Ghost contributor. And somewhat more painful, adding new Handlebars helpers can’t be done within a custom theme. This would mean either forking the engine or switching over to the headless API mode and building something like a Next.js front-end.