✨ Added support for multiple built-in themes

[cmraible]

refs TryGhost/Product#3510

• Until now, Ghost has always shipped with a single built-in theme, Casper. This change adds support for Ghost to ship with multiple built-in themes.
• Updated the install and update commands to create symlinks for any theme that is shipped alongside Ghost (e.g. any theme in ghost/core/content/themes)
• When rolling back with ghost update --rollback, any symlinks that are broken in the process will be removed

[vikaspotluri123]

I think this should be done as a migration

[cmraible]

Thanks! I tried this out because I agree it's a bit awkward to put this code here, but it didn't do what I need it to 😔. The migrations file you linked to are run depending on the CLI version that installed the instance of Ghost, and I need to create this symlink depending on the Ghost instance version. Basically, the migrations you're referring to are dependent on how Ghost was installed, rather than which version of Ghost was installed.

Basically, Ghost 5.62.0 doesn't include this theme, but 5.63.0+ will. We could of course check the Ghost version inside the migration and that would work in most cases (e.g. when upgrading sites on Ghost (Pro)), but you could theoretically use the latest version of the CLI (e.g. 1.24.4 once this change is released) to install an older version of Ghost (5.62.0 or earlier) and then use the same version of the CLI to update to 5.63.0. In this case, the migration wouldn't run because the CLI version hasn't changed and therefore the theme wouldn't be installed.

I'll probably break this block into its own task because I agree it doesn't really fit inside the link task, but I don't think using the existing migrations 'framework' works in this case.

[vikaspotluri123]

Ahh, yeah, the main issue I see is that older versions of Ghost are "vulnerable" to invalid symlinks (the stat call fails but isn't handled). If they supported invalid symlinks, you could create a symlink regardless of the Ghost version.

It would be great if Ghost's migrations could handle this, but you'd have to assume that everyone is using the CLI, and hardcode current into the path 🤮

Another option is to extend the migrations framework to also support beforeInstance. You would need to add rollback support, though. Then again, rollback support is required regardless.

e: On the other side, I don't see any issues with a missing symlink in new versions of Ghost, since the core declares the minimum CLI version.

[cmraible]

@vikaspotluri123 I spent some time refactoring this today to address some of your concerns, and I think the result is much improved from my first attempt:

• The install command no longer checks the version number — it simply creates a symlink for all themes that are shipped with Ghost. So for versions < 5.67.0, it will only link casper because that's the only theme that ships with Ghost, for 5.67.0+ it will link casper and source, and eventually when we remove casper it will only install source.
• The update command uses basically the same logic — it will create symlinks for any theme that installs with Ghost, so when updating to 5.67.0 it will create a symlink for source and in the case of a rollback, it will remove any symlinks that are broken in the process of the rollback (e.g. when rolling back from 5.67.0 it will remove the symlink to source because it is not present in 5.66.1).
• I also added a migration to Ghost that will be included in 5.67.0 which does nothing when upgrading, but when rolling back to < 5.67.0 it will check if source is the active_theme and update it to casper if so.

These changes paired with a migration in Ghost to set the active theme to casper only when rolling back to < 5.67.0 and source is the current theme should address all your concerns, and I think it's a more elegant solution than manually checking the version at various points in the CLI.

[vikaspotluri123]

Looks good overall! Left a few comments and suggestions 😊