With this change, session objects are no longer instantiated
globally, but instead created within a middleware during the
request lifecycle.
In addition, session garbage collection is integrated with
the already existing middleware for this purpose.
Symfony's component relies on PHP's native session functionality, which
is not ideal. It automatically sets its own cookie headers, resulting in
this issue: https://github.com/flarum/core/issues/1084#issuecomment-364569953
The Illuminate component is more powerful and has a simpler API for
extension with other drivers and such, and fits in nicely with other
components we use (the majority of which are from Illuminate).
Exceptions thrown while attempting to dispatch routes are now informing the exact value that was incorrect; url for not found routes and the method when the method was invalid.
This prevents garbage collection to randomly break the installer:
before installation, the models that are being accessed have no
database connection.
Now, the middleware is only mounted into the forum's middleware
stack. I want API requests to have stable performance, and the
forum middleware stack is only mounted when Flarum is installed.
* Returning the $default value if there's no config
This is especially important for the CookieFactory which accesses
the configuration before the application is installed
* Injecting the configuration values into the CookieFactory
I decided to put this in config.php because if cookie settings were to
be stored in the database and configured via admin UI, entering
incorrect settings could cause the admin session to be destroyed,
requiring manual database intervention to fix. But it's a good prompt
for discussion as to which kind of settings belong in config.php vs the
database. Thoughts?
This class holds all information relevant to a local Flarum site,
such as paths and local configuration. From this information, it
is able to instantiate a Flarum\Foundation\Application instance,
which represents a Flarum installation's runtime.
This will also be useful for setting up e.g. multi-tenant
environments.
The various middleware can be registered in the service provider,
and the rest of the logic can all go through one single front
controller (index.php in flarum/flarum, and Flarum\Http\Server in
flarum/core).
This will also simplify the necessary server setup, as only one
rewrite rule remains.
* Added `language` and `direction` properties to WebAppView
* Use properties `language` and `direction` in app.blade.php
* Added WebAppView::setDescription to set the meta description
* Whoops! Changed "ltr" to \'ltr\'. Thanks StyleCI :)
* Removed unnecessary `= null` for
* Changed `.. ? .. : ..` to `.. ?: ..`. Useful thing right there ;)
The way I read it, HTTP 405 is a generic statement about the
resource. Once a language pack is not the default, this is not
true anymore, so I figured 403 is more correct.
* Fix dependency version constraint. (Reverts #1066.)
* Allow exceptions to be raised when dispatching middleware.
* Fix our error handler middleware (do not implement Stratigility's
error handler interface, catch exceptions instead).
See https://docs.zendframework.com/zend-stratigility/migration/to-v2/.
Closes#1069.
