The `.env` file shouldn't live in the `/config` directory when it is created, but
currently, the `.env_sample` file lives within `/config`. This can be confusing and
cause ENV var issues if someone duplicates `.env_sample` and renames it to `.env`,
because none of their ENV variables will get picked up, since their `.env` file will
mistakenly end up in `/config`.
This change moves `.env_sample` out of `/config`, and updates the documentation/relevant
.yml files accordingly.
* Refactor:Remove ENVied Gem in Favor of Default application.yml
* Copy sample_application.yml for Travis
* Create .env_sample file, Warn of missing ENV variables, ignore .env file
* Use dotenv For ENV variables and create Rake Task to Populate
* Update docs to copy .env_sample file
* make application config a bit more resilient
* update more documentation and only initialize dotenv in dev and test
* Update doc code snippet types and refactor rake task and app config
* remove push defaults
* Make initializers more resilient, remove unused ENV from travis
* Exit new rake task if application.yml does not exist, include dotenv in docs
* Rename all GitHub links from thepracticaldev/dev.to to forem/forem
* Use new site name
* Rename to Forem
* Rename more dev.to to forem
* Remove unnecessary redirects
* Rename DEV to Forem
* Use Forem instead of DEV for branding
* Use Forem instead of DEV for licensing
* Use seedling instead of DEV logo
* Improve format and clarity of the docs [ci skip]
While this change produces a lot of git noise by enacting what seems
like an arbitrary linewrap on most of the files in the documentation it
will result in better version control and tracking of the changes in the
documentation.
For example, as it currently stands, if one was to make a
PR to move a comma in a sentence because each paragraph in most of the
files is on a single line, that small change would look in the git
history like the author had modified the entire paragraph. In reality,
this author just moved a comma.
This change also includes a significant number of modifications to the
more article-esque docs. Many of these docs were written in a sort of
stream-of-conciousness and aren't as easy to read as they could be.
Hopefully this is the first of several readability changes. If we could
get these docs to a more accessible reading level, we would probably see
an increase in contributions. :)
* Delegate markdown wrapping to Prettier
* Add linewrapping explanation in the docs [ci skip]
* Correct installation documentation
* Add stylized titles
* Add some changes to the getting started documentation
* Add changes for the backend guide
* Add changes for the design guide
* Add testing / Q&A guide improvements
* Minor fixes to contributing docs
* More improvements to the general doc
* Improvements for frontend guide
