This issue is a placeholder for keeping a list of documentation we're going to need to write/rewrite for Ghost 1.0.0.
@AileenCGN
@kirrg001
@kevinansfield
grunt masteryarn run init -> explain that this command is only for initial setup + warning on feature branches!grunt dev documentation to explain when/why to use the individual commands@cobbspur
General category@frantzypants
author.feature_image is not valid, but the theme developer must be able to lookup the valid properties in the docsWe have added two new wiki pages so far. Both need a final review.
https://github.com/TryGhost/Ghost/wiki/Working-with-Ghost
https://github.com/TryGhost/Ghost/wiki/Developer-(Local)-Install
Thinking we should add updating help.ghost.org to the list - the settings screens and anything with the editor will need updating.
Some notes:
ghost install vs ghost install localghost doctor, ghost config & ghost setup are not documentedGeneral:
ghost install local if you're developing themes etc - would be really to have a theme devs guide/landing page that explains gscan and links to themes.ghost.org as well)_Caveat: These are opinions & I haven't read everything, just a few bits from the perspective of being a CLI user._
@ErisDS
I have added this issue back to the Ghost backlog.
Thanks for your notes 馃憤
We kept the CLI documentation for the first beta release short on purpose (was discussed/agreed in slack). The goal was to cover the basic CLI commands for development install. See e.g. https://docs.ghost.org/docs/basic-nginx-config-self-hosted-with-custom-domain, we added notes to share what's upcoming. As soon as we are ready for CLI production, we will extend the CLI guides.
I didn't see that page in the docs, I was only looking for information on ghost-cli, which does the nginx config for me.
That nginx config page is very confusing, as the only thing that should be done before running ghost-cli is getting rid of the default vhost (and perhaps set the client_max_body_size). If you create this nginx setup documented on this page before you run ghost-cli, then your blog will not work as there will be multiple sites listening on port 80.
What I think we ought to do, is document what ghost-cli does in terms of nginx setup - e.g. show the configuration it creates.
The goal was to cover the basic CLI commands for development install.
Quick Q to clarify what is meant by a development install? Did you mean self-hoster install here? because a development install would be ghost install local which has not yet been documented.
Oh that is interesting. It was ghost install local before 馃槙 I will change it back for now.
I am still not sure if there is clarity here:
ghost install local = developer install, for running on your local machine and testing. Does not setup nginx etc, uses sqlite3. Meant for quick tests or installing locally to create themes and apps.
ghost install = for production servers, only runs on linux and warns if it is not ubuntu 16.04
I don't understand why we have cli + separate nginx documentation in the same section?
If the current CLI guide is meant to just be for developers testing out locally, it doesn't fit under a section called "Self-host" & also this should be clearer. If it's meant to be the self-hosting instructions, then it should be documenting that ghost install does the nginx setup.
I know that next sprint is going to be a CLI sprint, and I understand wanting to keep it short to start with, however I'm double checking this because the documentation makes it seem like the difference between ghost install and ghost install local is not well understood.
I know that next sprint is going to be a CLI sprint
Correct.
ghost install local = developer install, for running on your local machine and testing
Yes absolutely correct. In theory, you can use ghost install local in your droplet, configure the rest yourself (e.g. nginx) and you can test the beta. But sure, it was designed for local install.
I absolutely agree having this section under Self Hosters might be a big confusion, but that's why we have put warnings everywhere. I can't remember that we have gotten feedback that the guide is very bad/confusing, but i might be wrong.
We all knew that the CLI was and is not ready yet and we all knew that the the next sprint is going to be a pure CLI sprint pulling it straight. Let's tackle this together 馃槑
Hi, have you considered adding a section for self-hosters with non-standard stack? I could provide some key information for RedHat/Centos users regarding firewall, selinux and nginx settings.
This would defeat the point of having an "official" stack.
What we are trying to achieve is not having the core team spending large amounts of time trying to add support for every possible self-hoster setup & adding a ridiculous QA overhead that literally stops us from being able to do anything ever. Instead, we have one stack that we support for self-hosters and that is Ubuntu 16.04 + MySQL + Nginx + Systemd.
You are more than welcome to ignore the official recommendation, but in that case you would need to refer to community documentation not official documentation.
@ErisDS yes I understand the point with official stack and i fully agree with that aproach. I wouldn't want you guys to spend your time on documenting or developing for hundreds of possible builds. What I ment is to actually host or indicate (link from ghost.org) place where community could keep such documentation so that it's kept in one place. That's just an idea anyway.
All of the tasks here were resolved. We can re-open this issue if we discover any missing tasks or raise a new one 馃憤 Closing.
Most helpful comment
This would defeat the point of having an "official" stack.
What we are trying to achieve is not having the core team spending large amounts of time trying to add support for every possible self-hoster setup & adding a ridiculous QA overhead that literally stops us from being able to do anything ever. Instead, we have one stack that we support for self-hosters and that is Ubuntu 16.04 + MySQL + Nginx + Systemd.
You are more than welcome to ignore the official recommendation, but in that case you would need to refer to community documentation not official documentation.