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.
- split up deprecated and remaining user notification logic
- started building a test (needs work)
- created new Model for NotificationPreference
- created extender to register a NotificationChannel
- created extender to maintain UserPreferences
User preferences are still possible on the users table directly.
Registering a user preference allows for transformation to happen.
And provides easier accessors. Not sure we want this.
! tests need work.
* Updated PHP requirement to 7.2
* Set wikimedia less version to 1.8
* Indentation fix on composer json
* Revert "Set wikimedia less version to 1.8"
This reverts commit 22d862fd98.
This would be the only breaking change in beta.12. Let's stick to our
backwards compatibility promise / intentions as much as possible, even
if we assume the class has not been used anywhere.
This BC layer will be removed again for beta.13.
Refs #1975.
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.
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.
By commenting out the new methods on the `DriverInterface` and checking
for these methods' existence before calling them, old implementations in
extensions will not break right away.
This will be removed after beta.12 is released, giving extension authors
about two months time to update their extensions.
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.
