Since we'll be encouraging (requiring?) people to include an "en" translation in extensions they want to put on the Marketplace, we should have a further fallback to "en" if it can't find translations in the forum's default language. That way if people only use extensions from the Marketplace, they'll hardly ever see any key names.
Thanks to @dcsjapan for the suggestion.
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
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
Core assets are copied into the root/assets directory on installation.
The contents of an "assets" directory within any extension is copied into root/assets/extensions/{name}/ whenever the extension is enabled, and deleted whenever the extension is uninstalled.
Still needs to be refactored
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.
