-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Laravel 5.6 and other improvements #33
Comments
Sure, PRs are welcome :). The more, the better. |
Hi @petehouston, I've updated the guide for Laravel 5.7 on my fork, and I have a suggestion for future Laravel updates. Would you like to create a branch on this repo called |
@mrintoul can you make a PR? Thank you :) |
I can make a PR into |
Versioning instructions sounds nice, but... may not be easy to maintain. 😅 But yes, this needs update and old instructions should be moved to a legacy branch after deprecate instructions for old PHP/Laravel version instructions. |
Why not? We could just have a branch for each version and any changes would be pushed to that branch. I also imagine that when a new version is released, the previous version's branch would go untouched and we just continue working on the latest version. |
Hi @petehouston, I'd like to contribute an updated guide for Laravel 5.6. I've also tested it on a new provider, Web Hosting Canada.
There are a few other things in the instructions that I would change, including the part about symbolic links. In my experience, deploying works much better if symbolic links are made the other way around, i.e. pointing to laravel-project/public from ~/www and ~/public_html. This way, updates to the project can be made easily using
git pull
to pull new changes in to the project directory, and there is no need to copy directories and move files around every time.I am also thinking of adding some FAQs about 500/403 errors when deploying.
Thoughts?
The text was updated successfully, but these errors were encountered: