The content/themes/ need to be excluded because they're meant to be copied over from node_modules, NOT hardcoded in the repo.

Revert this change.

@JaneJeon I don't think this should be a problem. See my points on why pushing your themes to this repository might be a better idea. Also, since the included themes are copied over to content/themes after the install step (which happens only on heroku), we should not have to worry about getting them there in content/themes in the source code

Of course all the themes belong in content/themes, as specified by Ghost CMS.

The question is whether you want to check the raw theme code into your codebase, and that's really just a hacky AF solution. Come up with a better way (that doesn't involve checking in individual themes) or remove this change entirely.

Again, no. The correct way to do it is to host your own theme on github/gitlab/npm and then specify the versions in package.json. This entire section needs to be rewritten.

@JaneJeon I can see your point there but I still think this is a better way to host themes. Here are my reasons:

1. The method of hosting my theme on GitHub and specifying versions in package.json has way too much complexity. The things you have to do to get it working are:
   • Create a new repository and push your theme there.
   • Fork and clone this repository
   • Add your theme in package.json
   • Add your theme name in copy-themes.sh
   • Push your changes to fork and deploy.

Compared to that, the method I am suggesting has fewer moving points:
* Fork and clone this repository
* Copy over your theme to content/themes/
* Push your changes and deploy
After all this repository aims to reduce work from the user, we want the work to be minimal.

2. While I can see your method work great for open source themes (the fact that it will fetch the latest theme post-installation), it doesn't work at all if a user wishes to install a paid theme. The user won't want to host their theme on a public GitHub repository and currently, there is no way to fetch it from a private one.

3. I can clearly see why your method makes sense for open source themes. We don't have to bloat the repository with extra stuff. But if the user wishes to add one extra theme, copying over shouldn't be a problem.

You can use private packages/verdaccio and such to get around "non-open-source" themes. My main concern is that it will clutter up your repository with the actual themes checked into the codebase, not version-tagged or anything like that. Good luck updating your themes, because you'll still need to do the "way too complex" steps of pinning your theme in package.json and in the script. It's LITERALLY two lines.

Updating the theme should be equal work. It only involves copying the updated theme and redeploying. That is equivalent if to editing the package.json and redeploying.

You can use private packages/verdaccio and such to get around "non-open-source" themes

I don't think this is a good solution.

@JaneJeon I think your method is the best when we are dealing with open-source themes which are already there on GitHub.
I can't find a better way to easily add (private) themes without managing multiple repositories and editing a bunch of files. Copying over and pushing is the quickest and easiest to go with no major downsides.

If you think this change won't improve the project, feel free to close this PR.
A quick note though, it will be really good to value an open-source contributor's efforts and time a little more. Having an open-minded and polite discussion always helps.

This shouldn't really be removed.

I don't really see a point in cloning this repository, making a change in it and not tracking that change. The correct way to change the source code should always be to fork