force the timezone to be defined in the config file, rather than deferring to an environment variable.
IMO having the timezone dependent on an environment variable adds an unnecessary amount of risk for your average user who may be unaware of the effects from changing this value.
some scenarios where this could cause issues:
- devs set this value to their local timezone on their local dev machines, and they are writing `Carbon:create()` commands or similar that now are working only under the assumption of that timezone value
- you have multiple production servers setup across the country and each has their own timezone value according to their location, but they all talk to a central database. now the database is loaded with mixed timezone variables
having an explicit value defined once for the application removes these risks.
reverts part of #6188
See: https://github.com/laravel/framework/pull/47309
# Laravel 11 Skeleton Overview
### General Notes
More environment variables have been added to the `.env.example` file.
The default `QUEUE_CONNECTION` variable value has been updated to `database` instead of `sync`.
The `BROADCAST_DRIVER` and `CACHE_DRIVER` environment variables have been renamed to `BROADCAST_CONNECTION` and `CACHE_STORE`, respectively.
The HTTP Kernel has been removed. Configuration that was previously done in this file can be done in the `bootstrap/app.php` file, including registering / replacing middleware.
The console kernel has been removed. Schedules can be defined in the console “routes” file. Commands generated by `make:command` are automatically loaded and do not require registration. Additional command loading paths can be registered in the `bootstrap/app.php` file.
The exception handler has been removed. Exception handling behavior can be configured in the `bootstrap/app.php` file via `reportable`, `renderable`, `throttle`, and more. Callbacks received by these functions will have their type hints inspected to see if they handle a given exception.
The base HTTP controller no longer extends any other classes (requiring new middleware definition feature). No traits are included by default on the base controller. Authorization can be done using facades, or traits can be added manually.
All middleware has been removed. Configuration of these middleware’s behavior can be done via static methods on the middleware themselves (see framework notes).
The `User` model now utilizes a `casts` method instead of a property. The `HasApiTokens` trait has been removed by default since Sanctum is not installed by default.
All service providers except the `AppServiceProvider` have been removed. Policies are auto-discovered and gates can be registered in `AppServiceProvider`. Likewise, events can be registered in `AppServiceProvider`. Routing behavior is now determined / customized in the `bootstrap/app.php` file.
New `bootstrap/app.php` file can be used to customize core framework behavior like routing, container bindings, middleware, and exception handling.
Sanctum is no longer installed by default (see `install:api`).
Configuration files are not present by default. Can be published by `config:publish` command. Default values are present in the framework and application level configuration now cascades with framework definitions, so only customized values need be present in application level configuration files.
Migration files have been re-dated to be evergreen. The `password_reset_tokens` table migration has been combined into the `users` table migration file. Likewise, the `jobs` table migration has been combined into a single migration with the `failed_jobs` table.
Echo bootstrapping has been removed by default. It is re-inserted by new `install:broadcasting` command.
API and channel routes files are not present by default, can be recreated by `install:api` and `install:broadcasting` respectively.
These are very similar to routes in that they are channel endpoints
that your application supports and they also fully support route model
binding in Laravel 5.4. Upgraded applications do not need to make this
change if they do not want to.
when i started, i ended up putting all package specific service providers just at the bottom of the application service providers. But when making a route group like domain.com/{keyword}, the packages that are registering its own url's, not work anymore (like now when i installed the translations manager from barryvdh). When putting them above the app specific, everything works. So just give it to the user as a default place?
