I was facing the same issue after going through the same tutorials as you I think ^^ The truth is, it's a really bad idea to change the structure of Laravel. You will have problems sooner or later ... The best, as we have suggested to you, is to point your domain name to the public folder / of your Laravel directory.
The correct, secured Laravel folder structure should be:
└── blogapp <- 1. Laravel root folder, DocumentRoot CANNOT point here
├── public <- 2. DocumentRoot MUST point here, i.e. https://yourdomain.com
│ └── robots.txt <- 3. MUST be able to load https://yourdomain.com/robots.txt
├── .env
├── storage
...
└── vendor
├── public_html <- 2. DocumentRoot MUST point here
│ └── blog <- 3. move and rename `public` as `blog`, https://yourdomain.com/blog
│ ├── robots.txt <- 4. MUST be able to load https://yourdomain.com/blog/robots.txt
│ └── index.php <- 5. Must modify this index.php
└── blogapp <- 1. Laravel root folder, DocumentRoot CANNOT point here
├── .env
├── storage
...
└── vendor
@halim No, you should not be pushing .env files to production servers.
The .env is to mimic environment variables in environments where it’s difficult to use env vars proper, such as local development environments.
On your production server, you should be setting actual environment variables. Laravel will pick these up just like it would from an .env file.
This practice comes from the “Twelve-Factor App” principles, which states an application should be configured by its environment. So you should be able to move your code from one server to another and its configuration (database credentials, API Keys, etc) should be dictated by the environment instead of code.