The test from the previous commit proves this works as intended. :)
This is one more step in trying to avoid the widespread usage of the
`Application` godclass.
Refs #2055.
- Give them a fixed width (independent of font library)
- Center the icons in their column
- De-emphasize the icons by applying a muted color
Fixes#2016, closes#2018.
This avoids injecting the Application god class and assembling default
file locations in multiple places.
In addition, we no longer use the `MountManager` for these uploads. It
only added complexity (by moving tmp files around) and will not be
available in the next major release of Flysystem.
Note: Passing PSR upload streams to Intervention Image requires an
explicit upgrade of the library. (Very likely, users have already
updated to the newer versions, as the old constraint allowed it, but
we should be explicit for correctness' sake.)
Instead of converting the uploaded file object to an UploadedFile
instance from Symfony, because the latter is compatible with
Laravel's validation, let's re-implement the validation for the
three rules we were using.
The benefit: we can now avoid copying the uploaded file to a
temporary location just to do the wrapping.
In the next step, we will remove the temporary file and let the
uploader / Intervention Image handle the PSR stream directly.
* Made the console command system extender-friendly
* Added console extender
* Added ConsoleTestCase to integration tests
* Added integration tests for console extender
* Marked event-based console extension system as deprecated
* Moved trimming command output of whitespace into superclass
* Renamed 'add' to 'command'
* Added special processing for laravel commands
* Code style fixes
* More style fixes
* Fixed $this->container
No need for breaking backwards compatibility here - encapsulating the
logic for `getAttributes()` in one place turns out to be quite useful.
Refs #1931.
We need to get rid of this god class, as Laravel's Application contract
gets even bigger with 5.8. To avoid having to add all these methods, we
should try to stop using it where we can.
This gives extension authors time to add the new `getAttributes()`
method to their `BlueprintInterface` implementations.
The layer itself is easy to remove in beta.14.
This separates sending each individual mail, thus hardening the app.
There are still many improvements possible in this code, e.g. chaining
these commands, making emails just another notification type and
listening to the Notify event instead. We can postpone this to a later
stable release.
Forces notifications into a dedicated SendNotificationsJob and passed
to the queue.
- One static method re-used in the job ::getAttributes, is that okay or
use a trait?
- Do we want to use this solution and refactor into a better Hub after
stable, postpone this implementation or use it in b11?
The getEnabled method returns all extensions (previously) enabled, yet manually
uninstalled through composer. This does not reference the exact, current state
of the forum. getEnabledExtensions returns a list where the getEnabled list
is filtered on the extensions found in the composer installed.json file.
There are two more API integration tests that explicitly add the
"Authorization" header right now:
- `Flarum\Tests\integration\api\authentication\WithApiKeyTest`
- `Flarum\Tests\integration\api\csrf_protection\RequireCsrfTokenTest`
These two specifically test authentication, so in those cases the
explicitness seems desirable.
I feel this makes the parameters a bit more clear, does not rely on
inheritance (you can only inherit from one class, but we might want more
of these helpers in the future), and has less side effects (e.g. no
creation and, more importantly, deletion of users in the database).
Refs #2052.
