* Improve fulltext gambit
* Only search in visible posts
This change relies on the `visibility-scoping` branch to be merged.
* Change posts table to use InnoDB engine
Doing a JOIN between an InnoDB table (discussions) and a MyISAM table
(posts) is very very (very) bad for performance. FULLTEXT indexes are
fully supported in InnoDB now, and it is a superior engine in every
other way, so there is no longer any reason to be using MyISAM.
* Use ::class
* Only search for comment posts
* Add fulltext index to discussions.title
* Fix migration not working if there is a table prefix
* Update frontend appearance
* Apply fixes from StyleCI
[ci skip] [skip ci]
* Show search result excerpts on mobile
This fixes an issue where unapproved discussions (via
flarum-ext-approval) that were rejected became invisible to the user.
This solution is imperfect and some more substantial thought into how
flarum-ext-approval works is required in the future.
* Overhaul the way model visibility scoping works
- Previously post visibility scoping required concrete knowledge of the
parent discussion, ie. you needed a Discussion model on which you
would call `postsVisibleTo($actor)`. This meant that to fetch posts
from different discussions (eg. when listing user posts), it was a
convoluted process, ultimately causing #1333.
Now posts behave like any other model in terms of visibility scoping,
and you simply call `whereVisibleTo($actor)` on a Post query. This
scope will automatically apply a WHERE EXISTS clause that scopes the
query to only include posts whose discussions are visible too. Thus,
fetching posts from multiple discussions can now be done in a single
query, simplifying things greatly and fixing #1333.
- As such, the ScopePostVisibility event has been removed. Also, the
rest of the "Scope" events have been consolidated into a single event,
ScopeModelVisibility. This event is called whenever a user must have
a certain $ability in order to see a set of discussions. Typically
this ability is just "view". But in the case of discussions which have
been marked as `is_private`, it is "viewPrivate". And in the case of
discussions which have been hidden, it is "hide". etc.
The relevant API on AbstractPolicy has been refined, now providing
`find`, `findPrivate`, `findEmpty`, and `findWithPermission` methods.
This could probably do with further refinement and we can re-address
it once we get around to implementing more Extenders.
- An additional change is that Discussion::comments() (the relation
used to calculate the cached number of replies) now yields "comments
that are not private", where before it meant "comments that are
visible to Guests". This was flawed because eg. comments in non-public
tags are technically not visible to Guests.
Consequently, the Approval extension must adopt usage of `is_private`,
so that posts which are not approved are not included in the replies
count. Fundamentally, `is_private` now indicates that a discussion/
post should be hidden by default and should only be visible if it
meets certain criteria. This is in comparison to non-is_private
entities, which are visible by default and may be hidden if they don't
meet certain criteria.
Note that these changes have not been extensively tested, but I have
been over the logic multiple times and it seems to check out.
* Add event to determine whether a discussion `is_private`
See https://github.com/flarum/core/pull/1153#issuecomment-292693624
* Don't include hidden posts in the comments count
* Apply fixes from StyleCI (#1350)
Event priorities are no longer in Laravel - see dbbfc62bef
Updated the AbstractPolicy terminology to reflect the new behaviour,
which is that there is no guarantee that the catch-all methods will run
after all specific methods have run globally. This behaviour is only
guaranteed within the policy.
Turns out Container::call() does not work with invokable classes.
Thus, we need to wrap callables in a custom extender class to
support injecting any resolvable type-hint automatically.
Refs #851.
This simplifies the API and gives extension developers more
flexibility, for a) maintaining backwards compatibility, and
b) doing advanced stuff that extenders do not allow.
Note that only extenders are guaranteed to work across
different versions of Flarum (once the API surface is stable).
See the discussion in https://github.com/flarum/core/pull/1335.
This makes it more consistent with other existing extenders,
while also making registration of multiple routes more
comfortable for extension developers, and likely slightly
more performant. :-)
The change introduced in #1033 transformed any identification attribute returned from an OAuth provider to just a default value.
When the identification attribute used by the provider is the email or username, this allowed the user to supply a different email or username and still getting an already-enabled account with the credentials he entered.
Skipping attributes with an existing value makes no sense here because it's a always a fresh user and values from AbstractOAuth2Controller::getIdentification() should always be enforced.
* Add Custom Footer HTML
Straight copy from Custom Header HTML
* Move Custom Footer HTML to exactly before `</body>` tag.
* Fix invalid class name
* Append CustomFooterHTML when preparing the view.
* Some consistency in placing the variable
* Manage Composer height in a separate class with overridable methods
* Use a computed method
* Keep everything in Composer.js
* Drop usage of computed property for the Composer height
Because the Composer height also depends on the page height and is rarely called without position, height or page height changing anyway
Loading the activated extensions now means retrieving an array of
extenders (classes that implement a certain type of extension of a core
feature in Flarum).
For now, the only existing extender is the Compat extender which is used
to handle old-style bootstrappers that simply return a closure that
receives all of its dependencies via auto injection.
In the future, extensions will be able to return an array of extender
instances from their bootstrapper instead. These extender classes will
be implemented in the next step.
