This includes an API endpoint for fetching the list of possible
drivers and their configuration fields. In the future, this can
be extended to include more meta information about each field.
This adds an interface for mail drivers to implement, defining several
methods that we need throughout Flarum to configure, validate and use
the various email drivers we can support through Laravel.
More mail drivers can be added by `extend()`ing the container binding
"mail.supported_drivers" with an arbitrary key and the name of a class
that implements our new `DriverInterface`.
This will ensure that drivers added by extensions can be properly built
and validated, even in the frontend.
Refactored to use the Capsule Database manager for setting up the
Flarum (mysql) connection.
This will introduce the reconnector automatically, fixing #1740
This creates a dedicated test suite for integration tests. All of them
can be run independently, and there is no order dependency - previously,
all integration tests needed the installer test to run first, and they
would fail if installation failed.
Now, the developer will have to set up a Flarum database to be used by
these tests. A setup script to make this simple will be added in the
next commit.
Small tradeoff: the installer is NOT tested in our test suite anymore,
only implicitly through the setup script. If we decide that this is a
problem, we can still set up separate, dedicated installer tests which
should probably test the web installer.
Since this is not strictly speaking a domain invariant, but rather
specific to the user interface where passwords are not displayed, and
should therefore be entered twice to prevent mistakes going unnoticed,
this stuff should be checked in the frontend, not in the install steps.
Next step: Ensure that all domain-specific validation is done in the
installer's domain layer. This will ensure these validations cannot be
forgotten, and keep the frontends DRY.
Since we do not provide a development VM anymore, it does not make sense
to have "default" credentials etc.
To reproduce something similar, I'd suggest using a YAML or JSON file
together with the `--file` option.
This is probably the most complicated way I could find to fix#1587.
Jokes aside, this was done with a few goals in mind:
- Reduce coupling between the installer and the rest of Flarum's
"Application", which we are building during installation.
- Move the installer logic to several smaller classes, which can then
be used by the web frontend and the console task, instead of the
former hacking its way into the latter to be "DRY".
- Separate installer infrastructure (the "pipeline", with the ability
to revert steps upon failure) from the actual steps being taken.
The problem was conceptual, and would certainly re-occur in a similar
fashion if we wouldn't tackle it at its roots.
It is fixed now, because we no longer use the ExtensionManager for
enabling extensions, but instead duplicate some of its logic. That is
fine because we don't want to do everything it does, e.g. omit
extenders' lifecycle hooks (which depend on the Application instance
being complete).
> for each desired change, make the change easy (warning: this may be
> hard), then make the easy change
- Kent Beck, https://twitter.com/kentbeck/status/250733358307500032Fixes#1587.
This is important because extensions may wish to render post content
differently depending on Request factors such as the actor. For example,
an attachments extension might wish to hide attachments from guests.
This solution is a bit of a hack-job for now, but soon when we refactor
the API layer to use tobscure/json-api-server, and also refactor the
Formatter layer, it can be revised.
The event subscriber approach means that dependencies have to be
injected (and thus instantiated, along with all *their* dependencies) at
the time of registering event listeners - even when events are never
fired within a request's lifecycle.
This is unnecessary and causes more classes than necessary to be loaded.
In this case, we can explicitly register event listeners that will
resolve their dependencies when the event is fired, not before.
Refs #1578.
We had added a `storage/locale` directory to our skeleton, but we had
forgotten to hook it up with the translator. Enabling caching saves
parsing that locale YAML files on every pageload which should be good
for performance.
The locale cache will be cleared whenever an extension that uses the
`Locales` or `LanguagePack` extenders is enabled/disabled. If debug
mode is ON, then the caching mechanism will automatically check if any
of the loaded YAML files are dirty and update accordingly.
wrap() only adds a table prefix when referencing a column with a table
name (such as `foo.bar`) - when only a single identifier is provided, it
is assumed to be a column name, which does not need a prefix.
Fixes#1659.
- Simpler class naming:
Frontend\CompilerFactory → Frontend\Assets
Frontend\HtmlDocumentFactory → Frontend\Frontend
Frontend\HtmlDocument → Frontend\Document
- Remove AssetInterface and simply collect callbacks in Frontend\Assets
instead
- Remove ContentInterface because it serves no purpose (never type-
hinted or type-checked)
- Commit and add asset URLs to the Document via a content callback
instead of in the Document factory class itself
- Add translations and locale assets to Assets separate to the assets
factory, as non-forum/admin asset bundles probably won't want them
- Update Frontend Extender to allow the creation of new asset bundles
- Make custom LESS validation listener a standalone class instead of
extending RecompileFrontendAssets
The previous approach of joining the posts table into the main search
query was not scaling well. Searches on discuss.flarum.org were taking
~1.5 seconds which – a significant improvement over the pre-beta 8
search, but still not acceptable.
This new approach uses a much more efficient subquery join. Searches
on discuss.flarum.org now take mere milliseconds. The search result
ranking strategy has been further refined as well so that discussions
are ranked by the collective relevance of their posts.
This takes place only in the FallbackExceptionHandler. Having a custom
exception handler implies that a friendly message is displayed in the
API response, in which case we can bet that the exception won't need to
be "debugged" per se.
Having a custom view implies that a friendly message is displayed to
the user, in which case we can bet that the exception won't need to be
"debugged" per se.
This will prevent a notification from being seen by a user if its
subject is deleted or undergoes some kind of permission change (eg.
a discussion is moved into a private tag)
ref #1380
* fixed not being able to use master token because id column no longer holds key
* added flexibility of user_id column
* added tests to confirm the api keys actually work as intended
Seems the created_at column has no default value. This was always the case, at least that's what I can tell from a clean install and no migrations changing that default value.
```
$table->timestamp('created_at');
```
* Allow admins to see last online text
* Use viewLastSeenAt permission
* Move permission to UserSerializer, removed from ForumSerializer
* Remove extra comma from ForumSerializer to keep diff clean
* Add permission to new seed migration
* Remove AbstractOAuth2Controller
There is no reason to provide an implementation for a specific oAuth2
library in core; it's not generic enough (eg. auth-twitter can't use it).
This code could be moved into another package which auth extensions
depend on, but it's a negligible amount of relatively simple code that
I don't think it's worth the trouble.
* Introduce login providers
Users can have many login providers (a combination of a provider name
and an identifier for that user, eg. their Facebook ID).
After retrieving user data from a provider (eg. Facebook), you pass the
login provider details into the Auth\ResponseFactory. If an associated
user is found, a response that logs them in will be returned. If not, a
registration token will be created so the user can proceed to sign up.
Once the token is fulfilled, the login provider will be associated with
the user.
Permission to rename/hide/edit one's own discussion/post is only granted
if the user has permission to reply to the discussion. This makes sense
if you think of these actions as forms of "replying" to a discussion.
Fixes#1419 because suspended users do not have permission to reply to
discussions, therefore they will not be granted these "own" permissions.
By not letting PHP render the stack trace, we prevent displaying
sensitive information (such as the database credentials). Instead,
we display a simple line with the exception message.
In the console, the full exception can still be shown, as that is
a tool only for forum admins anyway.
Fixes#1421.
This is in preparation for fixing #1421 - it allows us to
encapsulate the exception handling in the server classes, so that
we can keep the skeleton (flarum/flarum) lean.
When loading notifications, $this->type was null and thus array_get
was returning an array instead of null. I assume this issue was
introduced in a Laravel version upgrade? Anyway, this fixes it.
By moving the DispatchRoute middleware into an `afterResolving`
callback, this will allow a new Middleware extender to add a `resolving`
callback to the appropriate container binding, removing the need for the
ConfigureMiddleware event.
The ConfigureMiddleware event has been deprecated and should be removed
in beta 9.
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.
