This extender implements several methods for extending the new error
handling stack implemented in #1843.
Most use-cases should be covered, but I expect some challenges for more
complex setups. We can tackle those once they come up, though. Basic
use-cases should be covered.
Fixes#1781.
This is better than the current system, as it adds transliteration rules
for special characters, rather than just throwing all of them away.
For languages that cannot be transliterated to ASCII in a reasonable
manner, more possible improvements are outlined in #194.
The forum title is already used as the display name for the sender email address, so having it in the subject is just a duplication and waste of space.
Implements the remove, insertBefore, insertAfter and replace
functionality for middlewares.
The IoC container now holds one array of middleware (bindings) per
frontend stack - the extender operates on that array, before it is
wrapped in a middleware "pipe".
Fixes#1957, closes#1971.
Test the request, not a controller (implementation detail). This also
focuses on the observable behavior instead of hacking our way into the
middleware pipeline in order to observe internal behavior.
The authenticated user is now determined by looking at the API response
to compare permissions and (non-)existing JSON keys.
Support the old format (a simple list of available fields), in addition
to the new format (a map from field names to their types + metadata).
This will be removed after beta.12 is released.
This extends our boot exception handling block to also catch and format
all exceptions that could be thrown while building our request handler,
i.e. the middleware stack handling requests.
The only exceptions that would now not be handled in this way could be
raised by Zend's `RequestHandlerRunner` and its delegates, which we
should be able to rely on.
Exceptions on request execution will be handled by the error handler in
the middleware stack.
Fixes#1607.
Adding a proxy callStatic on our simple implementation of the Manager class allows passing through calls like `forever()` to the underlying cache driver instance.
When users have external avatar urls (for instance: in a SSO environment where the avatar is provided by another domain), color thief fails to get the avatar dominant color because the canvas would be tainted.
Following the instructions here (https://lokeshdhakar.com/projects/color-thief/ on the "Does it work if the image is hosted on another domain?"), adding an `image.crossOrigin = 'Anonymous';` solves the issue.
Tested on my forum which before suffered from a JS error and works fine (without this fix, the canvas remain in the `body` while an script error is thrown by color thief)
We decided it is better to have a less intelligent search (that does not
match search terms in titles) for some people than a bad-performing
search for everyone.
We will revisit the search performance topic in the next release cycle,
possibly with larger changes around indexing.
Refs #1738, #1741, #1764.
We accept that this may be desired by forum owners and will offer an
extension to enable this feature. By default, we will not make any
assumptions and simply adopt the web's and browsers' default behavior.
Fixes#859.
- Extract a method for email address generation
- Consistent types
- No docblocks for types where superfluous
- Tweak console output
- Don't inherit from integration test's base class in unit test
- Fix base url when is appended with a script filename
- Add default base url http://flarum.local when CLI wizard used
- Remove some code duplication
- Add minor improvement to the UX when CLI wizard used
- Add tests
- Extract base url normalisation into its own value object
In flarum/core#1854, I changed the implementation of `assertCan()` to be
more aware of the user's log-in status. I came across this when unifying
our API's response status code when actors are not authenticated or not
authorized to do something.
@luceos rightfully had to tweak this again in ea84fc4, because the
behavior changed for one of the few API endpoints that checked for a
permission that even guests can have.
It turns out having this complex behavior in `assertCan()` is quite
misleading, because the name suggests a simple permission check and
nothing more.
Where we actually want to differ between HTTP 401 and 403, we can do
this using two method calls, and enforce it with our tests.
If this turns out to be problematic or extremely common, we can revisit
this and introduce a method with a different, better name in the future.
This commit restores the method's behavior in the last release, so we
also avoid another breaking change for extensions.
This test would have failed without commit ea84fc4. Next, I will revert
that commit and most of my PR #1854, so we need this test to ensure the
API continues to behave as desired.
This fixes a regression from #1843 and #1854. Now, the frontend again
shows the proper "Incorrect login details" message instead of "You
do not have permission to do that".
Refs #1788
TypeError: t.showDeletionAlert is not a function
at onSuccess(./src/forum/utils/UserControls.js:104:12)
Also, don't override 'this' param with user object for editAction
attempts to load the s9e Renderer from the wrong cache. It has
to be saved locally so that it can be properly loaded using
the spl auto register functionality.
* Add test job with PHP 7.3, MySQL & custom prefix
* Add prefix MariaDB test
* Add PHP 7.4 to tests
* Remove PHP 7.4 from tests
This reverts commit 270cba2f5f.
This will cause the right error (HTTP 401) to be thrown whenever
we're checking for a specific permission, but the user is not even
logged in. Authenticated users will still get HTTP 403.
HTTP 401 should be used when logging in (i.e. authenticating) would make
a difference; HTTP 403 is reserved for requests that fail because the
already authenticated user is not authorized (i.e. lacking permissions)
to do something.
...not based on status code.
To simplify this logic, we now use the same error "type" both when
routes are not found and specific models are not found. One exception is
ours, one is from Laravel, but for the purposes of error handling they
should be treated the same.
Fixesflarum/core#1641.
The error handling middleware now expects an array of reporters.
Extensions can register new reporters in the container like this:
use Flarum\Foundation\ErrorHandling\Reporter;
$container->tag(NewReporter::class, Reporter::class);
Note that this is just an implementation detail and will be hidden
behind an extender.
This separates the error registry (mapping exception types to status
codes) from actual handling (the middleware) as well as error formatting
(Whoops, pretty error pages or JSON-API?) and reporting (log? Sentry?).
The components can be reused in different places (e.g. the API client
and the error handler middleware both need the registry to understand
all the exceptions Flarum knows how to handle), while still allowing to
change only the parts that need to change (the API stack always uses the
JSON-API formatter, and the forum stack switches between Whoops and
pretty error pages based on debug mode).
Finally, this paves the way for some planned features and extensibility:
- A console error handler can build on top of the registry.
- Extensions can register new exceptions and how to handle them.
- Extensions can change how we report exceptions (e.g. Sentry).
- We can build more pretty error pages, even different ones for
exceptions having the same status code.
This reverts commit f8061bbca1.
We will keep this fallback in place, to avoid unnecessary breakage of
backwards compatibility for extension authors.
Removal is planned for the final 0.1 release.
- Use existing `selectRaw()` method to avoid using the global `app()`
helper as a service locator, which hides dependencies.
- Do the same for the join.
- The `Expression` is necessary to prevent the aliased column from being
prefixed with the database table prefix, if configured.
* Integration tests: Memoize request handler as well
This is useful to send HTTP requests (or their PSR-7 equivalents)
through the entire application's middleware stack (instead of
talking to specific controllers, which should be considered
implementation detail).
* Add tests for CSRF token check
* Integration tests: Configure vendor path
Now that this is possible, make the easy change...
* Implement middleware for CSRF token verification
This fixes a rather large oversight in Flarum's codebase, which was that
we had no explicit CSRF protection using the traditional token approach.
The JS frontend was actually sending these tokens, but the backend did
not require them.
* Accept CSRF token in request body as well
* Refactor tests to shorten HTTP requests
Multiple tests now provide JSON request bodies, and others copy cookies
from previous responses, so let's provide convenient helpers for these.
* Fixed issue with tmp/storage/views not existing, this caused tmpname to notice.
Fixed csrf test that assumed an access token allows application access, which is actually api token.
Improved return type hinting in the StartSession middleware
* Using a different setting key now, so that it won't break tests whenever you re-run them once smtp is set.
Fixed, badly, the test to create users etc caused by the prepareDatabase flushing all settings by default.
* added custom view, now needs translation
Fixed csrf test that assumed an access token allows application access, which is actually api token.
Improved return type hinting in the StartSession middleware
This fixes a rather large oversight in Flarum's codebase, which was that
we had no explicit CSRF protection using the traditional token approach.
The JS frontend was actually sending these tokens, but the backend did
not require them.
This is useful to send HTTP requests (or their PSR-7 equivalents)
through the entire application's middleware stack (instead of
talking to specific controllers, which should be considered
implementation detail).
This lets us or anyone modify the path from where dependencies (usually
installed into /vendor by Composer) are loaded. We need to be able to
tweak this in our integration tests, where the application code under
test needs access to certain dependencies.
Since these files are part of the same package, there is no need
to assume a Composer context to load these from. Instead, we can
just load them via the path relative to the current PHP file.
This assumption may break in certain environments, and it is
already broken when running (integration) tests.
custom_less is NULL or unavailable in the database. We cannot rely
on this value to exist or is incorrectly set to null and thus
completely bricking the app.
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.
We are still testing the installation logic, but not testing the
actual CLI task. I would love to do that, but IMO we first need to
find a way to do this fully from the outside, by invoking and
talking to the installer through the shell.
Because acceptance tests are easier to do when fully decoupled from
the application. (After all, they are intended to save us from
breaking things when changing code; and we cannot prove that when
we change the tests at the same time.)
It might be easier to start with acceptance tests for the web
installer, though.
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.
Passing an array to dropForeign does not mean dropping multiple indices,
but rather dropping a key on multiple tables.
Passing a string means that this string will be interpreted as index
name, not as name of the indexed column. Passing an array with one
string is therefore correct, in order to benefit from automatic index
name generation.
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 is to be used for formatting buttons and the like. Although it is
displayed in the controls area at the moment, it is conceptually
different and may be relocated to the top of the text editor in the
future.
- Change preview icon to Font Awesome Regular instead of Solid
- Give the preview button a tooltip
- Change submit button icon to paper plane (shown on mobile)
- Tweak mobile header button touch target
- Scroll overflowing text editor controls horizontally
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
fixes#1480
This is a suggestion to improve clarification of what a feature request on our issue tracker should entail.
Changes made:
- uppercased "IMPORTANT" instead of a "Note" to clarify the importance of the comment
- removed the "serious" related information, because users often have no scale to rate seriousness against
- brought more attention to approval by a core developer or argumentation and implementation by moving that to the front
Refactor Frontend + Asset code
- Use Laravel's Filesystem component for asset IO, meaning theoretically
assets should be storable on S3 etc.
- More reliable checking for asset recompilation when debug mode is on,
so you don't have to constantly delete the compiled assets to force
a recompile. Should also fix issues with locale JS files being
recompiled with the same name and cached.
- Remove JavaScript minification, because it will be done by Webpack
(exception is for the TextFormatter JS).
- Add support for JS sourcemaps.
- Separate frontend view and assets completely. This is an important
distinction because frontend assets are compiled independent of a
request, whereas putting together a view depends on a request.
- Bind frontend view/asset factory instances to the container (in
service providers) rather than subclassing. Asset and content
populators can be added to these factories – these are simply objects
that populate the asset compilers or the view with information.
- Add RouteHandlerFactory functions that make it easy to hook up a
frontend controller with a frontend instance ± some content.
- Remove the need for "nojs"
- Fix cache:clear command
- Recompile assets when settings/enabled extensions change
Casting an object to an array does not have the intended effect of
wrapping the object in an array. Instead we need to explicitly check
if the returned value is an array or not.
* Run extenders exported by extensions
* Add some basic extenders
* Patch Mithril as the very first thing so extension code can run safely
* Load the payload into the app before booting extensions
* Setup default routes before booting extensions
In the future we may have multiple Formatters, so by moving the config
callback to its own instance method we can leave the constructor
available to specify which formatter (like Assets and Routes). This
format also allows for other methods to be added.
Additionally, this adds logic to automatically flush the Formatter cache
whenever the extension is enabled or disabled.
* Replace gulp with webpack and npm scripts for JS compilation
* Set up Travis CI to commit compiled JS
* Restructure `js` directory; only one instance of npm, forum/admin are "submodules"
* Refactor JS initializers into Application subclasses
* Maintain partial compatibility API (importing from absolute paths) for extensions
* Remove minification responsibility from PHP asset compiler
* Restructure `less` directory
Mostly, we only need a database connection, instead of one of
Laravel's "connection resolvers".
Again, this makes our life easier during installation, where
we already instantiate a database connection. We can now use
that to instantiate our own Migrator class, instead of using
the IoC container to build one.
This removes the funky auto-injection capability from migration
closures. While technically removing a feature, this means we do
not need a fully-wired IoC container e.g. during installation.
Instead, all migration closures simply receive a schema builder
object (which is what most of them were already doing anyway).
This finally adopts the new standardized interfaces instead of the
work-in-progress ones with the `Interop\` prefix.
Since we have now updated to PHP 7.1, we can also use Stratigility
3.0 as the middleware dispatcher.
This will be the last PHP requirement upgrade for a while, at least
until stable (and therefore until the next major release).
We have decided to do this now, for the following reasons:
- We want to support MariaDB (and the compatible release of
doctrine/dbal requires 7.1 as well).
- We prefer to upgrade to Laravel 5.6 sooner rather than later.
- Using the PSR-15 middleware standard is easier this way, as we do
not have to switch from zend-stratigility to another PSR-15
implementation. (Stratigility v3, which implements the final
standard, requires 7.1.)
* added CreatePostControllerTest
* added DeleteDiscussionControllerTest
* added ListDiscussionControllerTest
* added TokenControllerTest
* minor improvement to policy, no need for Carbon object there, added ShowDiscussionControllerTest
* added showDiscussionControllerTest but cant make Guests view the discussion created by a user
* viewing for guests tested, we might need factories
* part one of adding tests, updating core
* Apply fixes from StyleCI
[ci skip] [skip ci]
* we need xdebug for code coverage, and hhvm was already removed
* forgot about the sidecar for mysql completely 🤦
* gitignore removed this installed json we need to fake that we have extensions
* using reguarded closure
Without this, the new version of Stratigility complained about no
response being returned. Old versions were more graceful here, but
this is certainly more correct.
Now we have two extenders:
- `Extend\LanguagePack` is the "convention over configuration" loader
for complete language packs.
- `Extend\Locales` can be used to load files (by locale) from a given
directory - useful for extensions that bring along their own locales
in multiple different languages.
Refs #851.
With this change, session objects are no longer instantiated
globally, but instead created within a middleware during the
request lifecycle.
In addition, session garbage collection is integrated with
the already existing middleware for this purpose.
Symfony's component relies on PHP's native session functionality, which
is not ideal. It automatically sets its own cookie headers, resulting in
this issue: https://github.com/flarum/core/issues/1084#issuecomment-364569953
The Illuminate component is more powerful and has a simpler API for
extension with other drivers and such, and fits in nicely with other
components we use (the majority of which are from Illuminate).
The gathering and execution of extenders can actually be done here
in the `Extension` class. This way, the `ExtensionManager` only
deals with the question of which extensions are enabled, the
`Extension` class actually extends the core application, and the
service provider simply calls a method, without having to know
about internals.
* Update FontAwesome to v5.0.6
* Adapt DiscussionListItem-count icon to match FontAwesome 5 syntax
* Change icon name to match FontAwesome 5.0.6 fas icon
* Add font type prefix parameter to icon helper
* Add Enable Icon Prefix to show icon in Extension Page
* Fix invalid icon behavior
* Change icon name to match FontAwesome 5.0.6 far icon
* Use iconPrefix property on component
* Use full icon class name
* Update icon helper docblock
* Full icon class syntax
Exceptions thrown while attempting to dispatch routes are now informing the exact value that was incorrect; url for not found routes and the method when the method was invalid.
* 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. :-)
* 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.
Using .dev as a TLD for local development is discouraged, as at
least Chrome now enforces HTTPS for these domains.
As far as I know, by default, the MySQL root user does not have
a password on many platforms. I use it this way on my local
machine, and this makes it convenient to setup a local copy.
This prevents garbage collection to randomly break the installer:
before installation, the models that are being accessed have no
database connection.
Now, the middleware is only mounted into the forum's middleware
stack. I want API requests to have stable performance, and the
forum middleware stack is only mounted when Flarum is installed.
* Prevent saving invalid custom less
* Fix formatting
* Fix formatting again
* Move custom less format check to its own listener
* Move listener to AdminServiceProvider
* Rename listener method
ref #1025#1238. This should prevent the frontend from crashing when
opening the notifications menu, but we still need to make sure
notifications are deleted properly when subjects are deleted.
Currently not user-customizable. Just needed to display statistics for a
client, so figured I'd make a start at this. Nothing too fancy for now,
but I'm sure some people will be happy to have this information at their
fingertips.
There is a Mithril bug which causes context.retain to be ineffective for
children nodes. https://github.com/MithrilJS/mithril.js/issues/1300
Thus, we have to assume that the children nodes (like the textarea)
may be recreated and thus we need to update its height on each redraw.
fixes#948
- Don't scroll to the bottom of the discussion when selecting "Reply"
from the menu if the composer is in full screen mode (ie. on mobile).
ref #1271
- After posting a reply, scroll to the end of the discussion
- Reduce the textarea height - previously it was 100vh, but this doesn't
account for the height of the iOS keyboard, so I've just arbitrarily
chosen 300px instead. There may be a better solution for this.
ref #1269
I believe the constant overlay of a loading div may be what's causing
the iOS cursor issues. This commit removes the fade animation so that
we can simply set display to none, which will hopefully fix the issue.
#1074 changed the input type for these fields to "color", but it turns
out the browser support for this input type sucks (they give you a very
limited color picker, and make it hard to input hex codes).
Not sure why this started happening now, but the admin navigation
dropdown wasn't receiving its children properly. This commit fixes a
flaw in our Mithril patch and allows an array of children to be passed
in the normal JSX way, rather than as an attribute.
* 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.
* Introduce user display names
It is not uncommon for forums to be intergrated with sites where users
don't have a unique "handle" - they might just have their first name,
or a full name, which is not guaranteed to be unique.
This commit introduces the concept of "display names" for users. By
default display names are the same as usernames, but extensions may
override this and set them to something different. The important thing
is that all code should use `display_name` whenever intending to output
a human-readable name - `username` is reserved for cases where you want
to output a unique identifier (which may or may not be human-friendly).
The new "GetDisplayName" API is probably sub-optimal, but I didn't worry
too much because we can come up with something better in `next-back`.
ref #557
* Apply fixes from StyleCI
[ci skip] [skip ci]
Currently all of a post's replies are loaded in full whenever the post
is loaded, which is kind of overkill - we really just need to know that
they exist (and who posted them) in order to render the "X replied to
this" line.
This is useful for forums integrating with an external website (eg. a
WordPress site), so they can reference existing avatars directly.
For alternative storage locations (eg. S3) the best practice will still
be to store a relative path and then configure an external base "assets
URL" (this is not currently possible - TODO).
Given this change, I think it would probably make sense to rename the
column to `avatar_url` in the upcoming batch of database naming changes
- then it can contain either a relative or an absolute URL -
@franzliedke do you agree?
Howdy! We're really excited that you are interested in contributing to Flarum. Before submitting your contribution, please take a moment and read through the [Contributing Guidelines](https://github.com/flarum/flarum/blob/master/CONTRIBUTING.md).
about: "I have a suggestion (and may want to implement it!)"
---
<!--
IMPORTANT: Feature requests on this GitHub issue tracker are only accepted in case they have been approved by a core developer or contain extensive argumentation and directions for implementation. For all other feature requests, ideas and feedback please post in the Flarum Community: https://discuss.flarum.org/t/feedback.
-->
## Feature Request
**Is your feature request related to a problem? Please describe.**
A clear and concise description of what the problem is. eg. I have an issue when [...]
**Describe the solution you'd like**
A detailed description of your proposed solution. Include:
- How the feature would work/behave
- Any potential drawbacks
- Maybe a screenshot, design, or example code
**Justify why this feature belongs in Flarum's core, rather than in a third-party extension**
Consider who this change will be useful to –most Flarum forums, or just a few?
**Describe alternatives you've considered**
A clear and concise description of any alternative solutions or features you've considered.
IMPORTANT: We applaud pull requests, they excite us every single time. As we have an obligation to maintain a healthy code standard and quality, we take sufficient time for reviews. Please do create a separate pull request per change/issue/feature; we will ask you to split bundled pull requests.
-->
**Fixes #0000**
**Changes proposed in this pull request:**
<!-- fill this out, mention the pages and/or components which have been impacted -->
**Reviewers should focus on:**
<!-- fill this out, ask for feedback on specific changes you are unsure about -->
**Screenshot**
<!-- include an image of the most relevant user-facing change, if any -->
**Confirmed**
- [ ] Frontend changes: tested on a local Flarum installation.
- [ ] Backend changes: tests are green (run `composer test`).
**Required changes:**
- [ ] Related documentation PR: (Remove if irrelevant)
- [ ] Related core extension PRs: (Remove if irrelevant)
During the beta phase, we will only patch security vulnerabilities in the latest beta release.
## Reporting a Vulnerability
If you discover a security vulnerability within Flarum, please send an email to security@flarum.org so we can address it promptly.
We will get back to you as time allows.
Discussions may commence internally, so you may not hear back immediately.
When reporting a vulnerability, please provide your GitHub username (if available), so that we can invite you to collaborate on a [security advisory on GitHub](https://help.github.com/en/articles/about-maintainer-security-advisories).
- New `hasPermission()` helper method for `Group` objects ([9684fbc](https://github.com/flarum/core/commit/9684fbc4da07d32aa322d9228302a23418412cb9))
- Expose supported mail drivers in IoC container ([208bad3](https://github.com/flarum/core/commit/208bad393f37bfdb76007afcddfa4b7451563e9d))
- More test for some API endpoints ([1670590](https://github.com/flarum/core/commit/167059027e5a066d618599c90164ef1b5a509148))
- The `Formatter\Rendering` event now receives the HTTP request instance as well ([0ab9fac](https://github.com/flarum/core/commit/0ab9facc4bd59a260575e6fc650793c663e5866a))
- More and better validation in installer UIs
- Check and enforce minimum MariaDB ([7ff9a90](https://github.com/flarum/core/commit/7ff9a90204923293adc520d3c02dc984845d4f9f))
- Revert publication of assets when installation fails ([ed9591c](https://github.com/flarum/core/commit/ed9591c16fb2ea7a4be3387b805d855a53e0a7d5))
- Benefit from Laravel's database reconnection logic in long-running tasks ([e0becd0](https://github.com/flarum/core/commit/e0becd0c7bda939048923c1f86648793feee78d5))
- The "vendor path" (where Composer dependencies can be found) can now be configured ([5e1680c](https://github.com/flarum/core/commit/5e1680c458cd3ba274faeb92de3ac2053789131e))
### Changed
- Performance: Actually cache translations on disk ([0d16fac](https://github.com/flarum/core/commit/0d16fac001bb735ee66e82871183516aeac269b7))
- Allow per-site extenders to override extension extenders ([ba594de](https://github.com/flarum/core/commit/ba594de13a033480834d53d73f747b05fe9796f8))
- Do not resolve objects from the IoC container (in service providers and extenders) until they are actually used
- Replace event subscribers (that resolve objects from the IoC container) with listeners (that resolve lazily)
- Use custom service provider for Mail component ([ac5e26a](https://github.com/flarum/core/commit/ac5e26a254d89e21bd4c115b6cbd40338e2e4b4b))
- Update to Laravel 5.7, revert custom logic for building database index names
- Refactored installer, extracted Installation class and pipeline for reuse in CLI and web installers ([790d5be](https://github.com/flarum/core/commit/790d5beee5e283178716bc8f9901c758d9e5b6a0))
- Use whitelist for enabling pre-installed extensions during installation ([4585f03](https://github.com/flarum/core/commit/4585f03ee356c92942fbc2ae8c683c651b473954))
- Update minimum MySQL version ([7ff9a90](https://github.com/flarum/core/commit/7ff9a90204923293adc520d3c02dc984845d4f9f))
### Fixed
- Signing up via OAuth providers was broken ([67f9375](https://github.com/flarum/core/commit/67f9375d4745add194ae3249d526197c32fd5461))
- Group badges were overlapping ([16eb1fa](https://github.com/flarum/core/commit/16eb1fa63b6d7b80ec30c24c0e406a2b7ab09934))
- API: Endpoint for uninstalling extensions returned an error ([c761802](https://github.com/flarum/core/commit/c76180290056ddbab67baf5ede814fcedf1dcf14))
- Documentation links in installer were outdated ([b58380e](https://github.com/flarum/core/commit/b58380e224ee54abdade3d0a4cc107ef5c91c9a9))
- Event posts where counted when aggregating user posts ([671fdec](https://github.com/flarum/core/commit/671fdec8d0a092ccceb5d4d5f657d0f4287fc4c7))
- Admins could not reset user passwords ([c67fb2d](https://github.com/flarum/core/commit/c67fb2d4b6a128c71d65dc6703310c0b62f91be2))
- Several down migrations were invalid
- Validation errors on reset password page resulted in HTTP 404 ([4611abe](https://github.com/flarum/core/commit/4611abe5db8b94ca3dc7bf9c447fca7c67358ee3))
-`is:unread` gambit generated an invalid query ([e17bb0b](https://github.com/flarum/core/commit/e17bb0b4331f2c92459292195c6b7db8cde1f9f3))
- Entire forum was breaking when the `custom_less` setting was missing from the database ([bf2c5a5](https://github.com/flarum/core/commit/bf2c5a5564dff3f5ef13efe7a8d69f2617570ce6))
- Dropdown icon was not showing in user card when on user page ([12fdfc9](https://github.com/flarum/core/commit/12fdfc9b544a27f6fe59c82ad6bddd3420cc0181))
- Requests were missing the `original*` attributes, which broke installations in subfolders ([56fde28](https://github.com/flarum/core/commit/56fde28e436f52fee0c03c538f0a6049bc584b53))
- Special characters such as `%` and `_` could return incorrect results ([ee3640e](https://github.com/flarum/core/commit/ee3640e1605ff67fef4b3d5cd0596f14a6ae73c9))
- FontAwesome component package changed paths in version 5.9.0 ([5eb69e1](https://github.com/flarum/core/commit/5eb69e1f59fa73fdfd5badbf41a05a6a040e7426))
- Some server environments had problems accessing the system-wide tmp path for storing JS file maps ([54660eb](https://github.com/flarum/core/commit/54660ebd6311f9ea142f1b573263d0d907400786))
- Content length of posts.content was not migrated to mediumText in 2017 ([590b311](https://github.com/flarum/core/commit/590b3115708bf94a9c7f169d98c6126380c7056e))
- An error occurred when going to the previous route if there was no previous route found ([985b87da](https://github.com/flarum/core/commit/985b87da6c9942c568a1a192e2fdcfde72e030ee))
### Removed
-`php flarum install --defaults` - this was meant to be used in our old development VM ([44c9109](https://github.com/flarum/core/commit/44c91099cd77138bb5fc29f14fb1e81a9781272d))
- Obsolete `id` attributes in JSON-API responses ([ecc3b5e](https://github.com/flarum/core/commit/ecc3b5e2271f8d9b38d52cd54476d86995dbe32e) and [7a44086](https://github.com/flarum/core/commit/7a44086bf3a0e3ba907dceb13d07ac695eca05ea))
- Fix live output in `migrate:reset` command ([f591585](https://github.com/flarum/core/commit/f591585d02f8c4ff0211c5bf4413dd6baa724c05))
- Fix search with database prefix ([7705a2b](https://github.com/flarum/core/commit/7705a2b7d751943ef9d0c7379ec34f8530b99310))
- Fix invalid join time of admin user created by installer ([57f73c9](https://github.com/flarum/core/commit/57f73c9638eeb825f9e336ed3c443afccfd8995e))
- Ensure InnoDB engine is used for all tables ([fb6b51b](https://github.com/flarum/core/commit/fb6b51b1cfef0af399607fe038603c8240800b2b), [6370f7e](https://github.com/flarum/core/commit/6370f7ecffa9ea7d5fb64d9551400edbc63318db))
- Fix dropping foreign keys in `down` migrations ([57d5846](https://github.com/flarum/core/commit/57d5846b647881009d9e60f9ffca20b1bb77776e))
- Fix discussion list scroll position not being maintained when hero is not visible ([40dc6ac](https://github.com/flarum/core/commit/40dc6ac604c2a0973356b38217aa8d09352daae5))
- Fix empty meta description tag ([88e43cc](https://github.com/flarum/core/commit/88e43cc6940ee30d6529e9ce659471ec4fb1c474))
- Remove empty attributes on `<html>` tag ([796b577](https://github.com/flarum/core/commit/796b57753d34d4ea741dbebcbc550b17808f6c94))
**[Flarum](https://flarum.org/) is a delightfully simple discussion platform for your website.** It's fast and easy to use, with all the features you need to run a successful community. It is designed to be:
* **Fast and simple.** No clutter, no bloat, no complex dependencies. Flarum is built with PHP so it’s quick and easy to deploy. The interface is powered by Mithril, a performant JavaScript framework with a tiny footprint.
* **Beautiful and responsive.** This is forum software for humans. Flarum is carefully designed to be consistent and intuitive across platforms, out-of-the-box.
* **Powerful and extensible.** Customize, extend, and integrate Flarum to suit your community. Flarum’s architecture is amazingly flexible, with a powerful Extension API.
## Installation
This repository contains Flarum's core code. If you want to set up a forum, visit the [Flarum skeleton repository](https://github.com/flarum/flarum).
## Contributing
Flarum is open-source and we would love your help building it! Please read the [Contributing Guide](https://github.com/flarum/flarum/blob/master/CONTRIBUTING.md) to learn how you can help.
Thank you for considering contributing to Flarum! Please read the **[Contributing guide](https://flarum.org/docs/contributing.html)** to learn how you can help.
## Security Vulnerabilities
If you discover a security vulnerability within Flarum, please send an e-mail to [security@flarum.org](mailto:security@flarum.org). All security vulnerabilities will be promptly addressed. More details can be found in our [security policy](https://github.com/flarum/core/security/policy).
## License
Flarum is open-source software licensed under the [MIT License](https://github.com/flarum/flarum/blob/master/LICENSE).
// If a tooltip was provided for buttons without additional content, we also
// use this tooltip as text for screen readers
if(attrs.title&&!this.props.children){
attrs['aria-label']=attrs.title;
}
// If nothing else is provided, we use the textual button content as tooltip
if(!attrs.title&&this.props.children){
attrs.title=extractText(this.props.children);
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
