Because extensions can have dependencies injected, a RouteCollection could potentially be instantiated, and thus the ConfigureRoutes event would be called before extensions have had a chance to subscribe to it. Instead, we instantiate the RouteCollection on demand, but only populate it when the application boots.
This means that the expensive minification process will only be run for a file if it hasn't before. Greatly speeds up extension enabling/disabling.
Also:
- Don't check file last modification times in production for a bit of extra perf.
- Only flush CSS when theme settings are changed. This speeds up the page reload a bit.
- 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.
Also add an API to let extensions define additional default route
options.
Allowing default routes with parameters (e.g. /d/123) is very difficult
because of the way Mithril routing works, and it doesn't have a
convincing use-case to justify the trouble. So I've removed the custom
input altogether.
closes#427
- 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
A good start I think, but still some work to do. If we go ahead with
https://github.com/flarum/core/issues/132#issuecomment-117507974 (which
I am in favour of), we can extract the entity-related stuff into some
smaller service providers (e.g. discussion repo, an event listener,
permissions, and gambits stuff could all go in
Flarum\Core\Discussions\DiscussionsServiceProvider).
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
Only preloading data for basic requests w/o query params, at least for
the moment - if we have to preload for something like
/?q=test&sort=newest, we end up having to duplicate a whole lot of
logic between JS/PHP.
All routes are now stored in a RouteCollection, which is then used
for dispatching by the (reusable) RouterMiddleware.
This change also entails moving all routes to the service providers.
This may be changed again later, and is done for convenience reasons
right now.
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.
- In order to be consistent with the Ember/LESS naming scheme, renamed
Flarum\Web to Flarum\Forum.
- Moved common classes into Flarum\Support so that Flarum\Admin doesn’t
depend on Flarum\Forum. Also moved Actor into Flarum\Support as it
doesn’t belong in the domain.
