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
- Get rid of Bootstrap (except we still rely on some JS)
- Use BEM class names
- Rework variables/theme config
- Fix various bugs, including some on mobile
The CSS is still not ideal – it needs to be cleaned up some more. But
that can be a focus for after beta.
- Use JSX for templates
- Docblock/comment everything
- Mostly passes ESLint (still some work to do)
- Lots of renaming, refactoring, etc.
CSS hasn't been updated yet.
- Return all discussion post IDs from API requests which add/remove
posts, so the post stream updates appropriately. Related to #146
- Always unload posts that are two pages away, no matter how fast
you’re scrolling
- Retrieve posts from cache instead of reloading them
- Fix various bugs. Maybe #152, needs confirmation
- Use contextual namespaces within Flarum\Core
- Clean up and docblock everything
- Refactor Activity/Notification blueprint stuff
- Refactor Formatter stuff
- Refactor Search stuff
- Upgrade to JSON-API 1.0
- Removed “addedPosts” and “removedPosts” relationships from discussion
API. This was used for adding/removing event posts after renaming a
discussion etc. Instead we should make an additional request to get all
new posts
Todo:
- Fix Extenders and extensions
- Get rid of repository interfaces
- Fix other bugs I’ve inevitably introduced
Most of #137 done.
- Use FastClick to make everything feel more responsive
- Use transforms for animations to make them silky smooth
- Style the drawer the same as the header to keep things simple
- Revert to fixed composer, but allow it to be minimised
- Add a separate notifications page for mobile so it’s easy to go back
- Add indicator to the menu button when there are unread notifications
- Close the drawer when navigating away
- Make dropdowns/modals scrollable
- Many other mobile tweaks and bug fixes
Didn’t take much care to keep CSS clean, due to #103
Ditched the idea of having language packs as extensions. Reasoning:
1. Because we use machine keys for translations (rather than English
keys), extensions need to be able to define default translations. If
English translations are to be included in extensions and not in a
language pack extension, then it doesn’t make sense to have other
languages as language pack extensions. Inconsistency → complexity.
2. Translations should maintain version parity with their respective
extensions. There’s no way to do this if extension translations are
external to the extension.
Instead, localisation will be a core effort, as well as a per-extension
effort. Translators will be encouraged to send PRs to core + extensions.
In core, each locale has a directory containing three files:
- translations.yml
- config.js: contains pluralisation logic for the JS app, as well as
moment.js localisation if necessary
- config.php: contains pluralisation logic for the PHP app
Extensions can use the Flarum\Extend\Locale extender to add/override
translations/config to a locale.
Asset compilation has been completely refactored with a better
architecture. Translations + config.js are compiled and cached for the
currently active locale.
It works but it’s not the most pretty thing in the world. @franzliedke
Would be great if you could take a look at the whole formatting API and
work your magic on it sometime… my brain is fried!
