Add instructions to add your own themes. #52
Conversation
aayushdutt
force-pushed
the
feature/custom-themes
branch
from
453051f
to
47418c8
Compare
| @@ -5,6 +5,3 @@ content/data/*.db | |||
| content/logs/ | |||
| config.production.json | |||
| content/data/ghost-local.db | |||
|
|
|||
| content/themes/* | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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
There was a problem hiding this comment.
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.
| **To use a new theme follow these steps** | ||
|
|
||
| 1. Fork and clone this repository | ||
| 2. Extract and copy your theme folder in content/themes. If your theme is `Editorial` it should look like `content/themes/Editorial/...` |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@JaneJeon I can see your point there but I still think this is a better way to host themes. Here are my reasons:
- The method of hosting my theme on GitHub and specifying versions in
package.jsonhas 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.
-
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.
-
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
@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.
| ```bash | ||
| git clone https://github.com/snathjr/ghost-on-heroku |
There was a problem hiding this comment.
This shouldn't really be removed.
There was a problem hiding this comment.
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
|
@aayushdutt I have a few days of free time to work on open source stuff. Is your PR ready for review? If so, resolve all discussions and I'll look through it again. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I have tested this method and it works flawlessly.