If install flarum in the site's root directory, it seems nothing
is wrong because the server software will trim the path, but if
install flarum in a sub directory, the font file of fontawesome
will not load correctly.
* When clicking "refresh" button for discussion list (on homepage) refresh notifications
* When clicking forum title (on homepage) refresh notifications
This seems to be pretty standard. Can just run `vendor/bin/phpunit` without any arguments. Removes the need for `composer test` (which is not ideal anyway as it removes colours from the output).
Closes#268. Not going to bother with a preview SVG or anything fancy for now – we can think about that as part of #746. Right now it's just good to finally get this functionality in!
Also need to think about apple-touch-icon, msTile stuff, and social sharing image. Not sure if this is all too much for core, but it's definitely too much for the current Appearance page layout. Again, something to think about as part of #746.
Code is a bit rough around the edges, but figured there's not much point in using the command bus properly since #870.
components/font-awesome is ~8 MB smaller than fortawesome/font-awesome because it excludes all examples/docs. Reducing dependency filesize will be important when we want to package up a .zip for distribution.
Extensions may wish to add attributes/content to all posts, regardless of type, by extending methods on the Post component. Now the subclasses will not overwrite, but rather append to, these additions.
Previously a discussion was classified on the front-end as "hidden" if it had zero posts. This was technically a correct statement as the discussion would not be visible to the public... but it also meant that a discussion with zero posts (like one awaiting approval) was impossible for the OP to delete/hide (i.e. indicate that they made a mistake and they don't want the discussion to be approved).
Extensions can add default column values in their migrations, but Eloquent doesn't know about this when it first saves a model to the database.
This is useful in flarum-ext-approval where the default value for is_approved on the posts table is true.
This helps to fix a bug in flarum-ext-tags where a user could not rename or edit the tags of their own discussion if it was in a restricted tag. This was due to the order of GetPermission event listeners – the logic that determines that a user *can't* perform an action because of a restrictive tag was running before (and thus instead of) the logic that determines that a user *can* edit their own stuff.
The solution is to change the "catch-all" methods on Policies to "after" instead of "before" – that is, they will run only if the per-ability methods return null.
We also simplify the GetPermission event by passing the model as a sole "argument", as I can't imagine any cases where we'll need more than one argument.
- Introduce the concept of "required permissions" - basically a permission dependency tree. In order for a group to be granted one permission, they must also have another.
- Improve redraw performance by not building dropdown menu contents until dropdown is opened
ref #904
