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.
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.
This method relies on the "view" being bound in the IoC container.
This is only guaranteed after all register() methods have run, thus
it should be done in boot().
Updating the Migration::addPermission helper table name means we need
to move the seed migration to after the table rename migration. We also
add a sanity check for each permission's group since the foreign key
will fail if the group doesn't exist. Of course, the only way to make
sure groups are seeded before permissions is to move them into another
migration.
I didn't think this change through and it's going to be too difficult
to implement right now. It can wait until we do the notifications
revamp. For now reverting back to the old structure, with the
`sender_id` column renamed to `from_user_id`.
* Make filenames and order more consistent
* Split foreign keys into their own migrations, add statements to ensure
data integrity prior to adding them
* Add renameColumns helper, use other helpers where possible
