* 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?
<\/script> tags in post content would sometimes be recognized as
actually ending the script tag, even when escaped (not exactly sure
why). This is fixed by encoding the < > characters in unicode.
Here, the order is relevant, because at this
point, the application has already been booted.
Hence, all boot() methods are called immediately,
which might depend on other service providers'
register() methods having run.
In this case, the DiscussionServiceProvider
depends on the Gate class being registered in the
container by the UserServiceProvider.
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.
They will probably be refactored away at a later stage (when we get
rid of the command bus). Until then, this lets us remove the
Flarum\Core namespace and actually feels quite clean.
