The default XHR error handler produce an alert which is appropriate to the response status code. It can be overridden per-request (by specifying the `errorHandler` option) so that the alert can be suppressed or displayed in a different position (e.g. inside a modal).
ref #118
We now use Symfony's Translation component. Yay! We get more powerful pluralisation and better a fallback mechanism. Will want to implement the caching mechanism at some point too. The API is replicated in JavaScript, which could definitely use some testing.
Validators have been refactored so that they are decoupled from models completely (i.e. they simply validate arrays of user input). Language packs should include Laravel's validation messages.
ref #267
- Reorganised all namespaces and class names for consistency and structure. Following PSR bylaws (Abstract prefix, Interface/Trait suffix).
- Move models into root of Core, because writing `use Flarum\Core\Discussion` is nice. Namespace the rest by type. (Namespacing by entity was too arbitrary.)
- Moved some non-domain stuff out of Core: Database, Formatter, Settings.
- Renamed config table and all references to "settings" for consistency.
- Remove Core class and add url()/isInstalled()/inDebugMode() as instance methods of Foundation\Application.
- Cleanup, docblocking, etc.
- Improvements to HTTP architecture
- API and forum/admin Actions are now actually all the same thing (simple PSR-7 Request handlers), renamed to Controllers.
- Upgrade to tobscure/json-api 0.2 branch.
- Where possible, moved generic functionality to tobscure/json-api (e.g. pagination links). I'm quite happy with the backend balance now re: #262
- Improvements to other architecture
- Use Illuminate's Auth\Access\Gate interface/implementation instead of our old Locked trait. We still use events to actually determine the permissions though. Our Policy classes are actually glorified event subscribers.
- Extract model validation into Core\Validator classes.
- Make post visibility permission stuff much more efficient and DRY.
- Renamed Flarum\Event classes for consistency. ref #246
- `Configure` prefix for events dedicated to configuring an object.
- `Get` prefix for events whose listeners should return something.
- `Prepare` prefix when a variable is passed by reference so it can be modified.
- `Scope` prefix when a query builder is passed.
- Miscellaneous improvements/bug-fixes. I'm easily distracted!
- Increase default height of post composer.
- Improve post stream redraw flickering in Safari by keying loading post placeholders with their IDs. ref #451
- Use a PHP JavaScript minification library for minifying TextFormatter's JavaScript, instead of ClosureCompilerService (can't rely on external service!)
- Use UrlGenerator properly in various places. closes#123
- Make Api\Client return Response object. closes#128
- Allow extensions to specify custom icon images.
- Allow external API/admin URLs to be optionally specified in config.php. If the value or "url" is an array, we look for the corresponding path inside. Otherwise, we append the path to the base URL, using the corresponding value in "paths" if present. closes#244
Spent quite a while looking into the best solution here and ended up going with three separate classes. Thanks to @Luceos for the PR that got this rolling (#518). My reasoning is:
- The task of routing and URL generation is independent for each section of the app. Take Flarum\Api\Users\IndexAction for example. I don't want to generate a URL to a Flarum route... I specifically want to generate a URL to an API route. So there should be a class with that specific responsibility.
- In fact, each URL generator is slightly different, because we need to add a certain prefix to the start (e.g. /api)
- This also allows us to get rid of the "flarum.api" prefix on each route's name.
- It's still DRY, because they all extend a base class.
At the same time, I could see no reason this needed to be "interfaced", so all of the classes are concrete.
Goes a long way to fixing #123 - still just a few places left remaining with hardcoded URLs.
Previously, clicking the "mark all notifications as read" button would individually mark each of the visible notifications as read. Since we now always show a badge with the number of unread notifications, we need to make sure that all notifications (not just the visible ones) can be marked as read. Otherwise it would be possible to get stuck with an unread badge there.
This commit adds a new API endpoint which marks *all* of a user's notifications as read. The JSON-API spec doesn't cover this kind of thing (updating all instances of a certain resource type), so I'm a bit unsure regarding what the endpoint should actually be. For now I've gone with POST /notifications/read, but I'm open to suggestions.
ref #500
Some providers (e.g. Twitter) don't expose user email addresses, so it
turns out we can't use that as the sole form of identification/account
matching.
This commit introduces a new `auth_tokens` table which stores arbitrary
attributes during the sign up process. For example, when Twitter is
authenticated, a new auth token containing the user's Twitter ID will
be created. When sign up is completed with this token, that Twitter ID
will be set as an attribute on the user's account.
Anti-spam extensions may automatically hide the first post in a
discussion, and thus we had to implement smarter permissions so
discussions with zero posts wouldn't be visible to users other than the
author/mods. This change allows those hidden posts to be restored again.
- Allow users to see their own posts, even if they have been hidden by
someone else
- Don't require hiding a post to be necessarily attributed to a user
- Hide discussions with zero posts, unless the user can edit posts, or
they are the discussion author
We can't do this using the ValidatesBeforeSave trait because the
password has been hashed by then. Instead, we must validate the
original password as it comes in.
Implemented our own migration repository + migrator (based on Laravel's
stuff) so that we can keep track of which migrations have been run for
core and per-extension. That way we can simple call the migrator to
upgrade core/extensions, and to uninstall extensions.
Parsing the post content makes it non-empty (`<t></t>`), so we don't
parse it if it is empty. Also delete a created discussion if the first
post was invalid.
closesflarum/core#224
The activity system we were using was built around a separate table.
Whenever the user posted something, or deleted a post, we would sync
the table. The advantage of this was that we could aggregate activity
of all different types very efficiently.
It turns out that it came with a huge disadvantage: there was no
efficient way to enforce permissions on activity. If a user posted
something in a private tag, everyone could still see it on their
activity feed. My stopgap solution was to only sync activity for posts
that are viewable by guests, but that was way too limited.
It also turns out that aggregating activity of different types is
really not that useful, especially considering most of it is the user
making posts. So I've gotten rid of that whole overly-complicated
system, and just made the user profile display separate lists of posts
and discussions, retrieved from those respective APIs. The discussions
page is an actual discussion list too, which is pretty cool.
It's still technically possible to aggregate different activity types
(basically just aggregate API responses together), but we can do that
later if there's a need for it.
This is probably my favourite commit of the day :)
- Fix composer crashing/not showing alert on error
- Make a general ValidationException which takes an array of field ⇒
messages to be outputted nicely by the API
