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.
- Use Symfony's Session component to work with sessions, instead of a custom database model. Separate the concept of access tokens from sessions once again.
- Extract common session/remember cookie logic into SessionAuthenticator and Rememberer classes.
- Extract AuthenticateUserTrait into a new AuthenticationResponseFactory class.
- Fix forgot password process.
- Use cookies + CSRF token for API authentication in the default client. This mitigates potential XSS attacks by making the token unavailable to JavaScript. The Authorization header is still supported, but not used by default.
- Make sensitive/destructive actions (editing a user, permanently deleting anything, visiting the admin CP) require the user to re-enter their password if they haven't entered it in the last 30 minutes.
- Refactor and clean up the authentication middleware.
- Add an `onhide` hook to the Modal component. (+1 squashed commit)
If the version in the settings table mismatches the code version, then we return a 503 error for all requests coming through index.php and api.php, while admin.php serves up a form prompting for the database password which will run outstanding migrations.
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
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.
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.
- 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.
- Extract shared Ember components into a “flarum-common” ember-cli
addon. This can be used by both the forum + admin Ember apps, keeping
things DRY
- Move LESS styles into their own top-level directory and do a similar
thing (extract common styles)
- Add LESS/JS compilation and versioning to PHP (AssetManager)
- Set up admin entry point
(Theoretical) upgrade instructions:
- Delete everything in [app_root]/public
- Set up tooling in forum/admin Ember apps (npm install/update, bower
install/update) and then build them (ember build)
- php artisan vendor:publish
- Upgrade flarum/flarum repo (slight change in a config file)
- If you need to trigger a LESS/JS recompile, delete the .css/.js files
in [app_root]/public/flarum. I set up LiveReload to do this for me when
I change files in less/ or ember/
Todo:
- Start writing admin app!
- Remove bootstrap/font-awesome from repo and instead depend on their
composer packages? Maybe? (Bower is not an option here)
