This can be achieved using the Route extender, which is more
flexible, as it does not necessary connect the URL with the current
frontend's router.
(Example use-case: The ext-embed frontend will be a new frontend,
however any routes using this frontend will be part of the forum
route group.)
Refs #851.
By passing in just the frontend identifier, we can hide some of the
implementation details, in this case the identifier of the Frontend
instance in the IoC container.
Since we are already providing the first and only argument
manually, we might as well instantiate the object manually.
Same effect, same coupling, less code.
This lets us register the former during installation, where the
latter is not yet registered.
That, in turn, means we can finally re-enable the StartSession
middleware in the installer app, which we need to log in the new
admin user when installation is complete.
Most things we need, we can instantiate directly.
This means we have to do less tweaking in service providers that
are meant to provide services to a complete Flarum application
(that has already been installed properly), to make them work with
the uninstalled app.
The uninstalled app (the "installer") can now do only the
bootstrapping it needs to build a light-weight web and console
application, respectively.
These are not necessary to be available so broadly. In fact, they
seem to make it too easy to use them, which has lead to some sub-
optimal architecture decisions.
Their equivalents have been moved to the classes where used.
Depending on the state of the Flarum installation (installed, not
installed, currently upgrading, maintenance mode), we should enable
different sets of service providers.
For example, during installation we should not resolve a setting
repository from the container. This new architecture lets us do so,
but we can easily (and cleanly) register a different implementation
during installation.
This should prevent problems such as #1370 in the future.
These are completely distinct functionalities, toggled through the
system-wide debug flag. By moving the selection of the middleware
to use to the place where the middleware pipe is built, we make
the middleware itself be unaware of these flags. The two classes
are more focused on what they are doing, with the constructor
dependencies clearly representing their requirements.
In addition, this means we can just use the HandleErrorsWithWhoops
middleware in the installer, which means we do not need to worry
about how to inject a SettingsRepositoryInterface implementation
when flarum is not yet set up.
