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.
* 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.
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.
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 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".
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.
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.
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 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.
