I decided to put this in config.php because if cookie settings were to
be stored in the database and configured via admin UI, entering
incorrect settings could cause the admin session to be destroyed,
requiring manual database intervention to fix. But it's a good prompt
for discussion as to which kind of settings belong in config.php vs the
database. Thoughts?
Here, the order is relevant, because at this
point, the application has already been booted.
Hence, all boot() methods are called immediately,
which might depend on other service providers'
register() methods having run.
In this case, the DiscussionServiceProvider
depends on the Gate class being registered in the
container by the UserServiceProvider.
This class holds all information relevant to a local Flarum site,
such as paths and local configuration. From this information, it
is able to instantiate a Flarum\Foundation\Application instance,
which represents a Flarum installation's runtime.
This will also be useful for setting up e.g. multi-tenant
environments.
The various middleware can be registered in the service provider,
and the rest of the logic can all go through one single front
controller (index.php in flarum/flarum, and Flarum\Http\Server in
flarum/core).
This will also simplify the necessary server setup, as only one
rewrite rule remains.
They will probably be refactored away at a later stage (when we get
rid of the command bus). Until then, this lets us remove the
Flarum\Core namespace and actually feels quite clean.
* Introduce user display names
It is not uncommon for forums to be intergrated with sites where users
don't have a unique "handle" - they might just have their first name,
or a full name, which is not guaranteed to be unique.
This commit introduces the concept of "display names" for users. By
default display names are the same as usernames, but extensions may
override this and set them to something different. The important thing
is that all code should use `display_name` whenever intending to output
a human-readable name - `username` is reserved for cases where you want
to output a unique identifier (which may or may not be human-friendly).
The new "GetDisplayName" API is probably sub-optimal, but I didn't worry
too much because we can come up with something better in `next-back`.
ref #557
* Apply fixes from StyleCI
[ci skip] [skip ci]
Currently all of a post's replies are loaded in full whenever the post
is loaded, which is kind of overkill - we really just need to know that
they exist (and who posted them) in order to render the "X replied to
this" line.
This is useful for forums integrating with an external website (eg. a
WordPress site), so they can reference existing avatars directly.
For alternative storage locations (eg. S3) the best practice will still
be to store a relative path and then configure an external base "assets
URL" (this is not currently possible - TODO).
Given this change, I think it would probably make sense to rename the
column to `avatar_url` in the upcoming batch of database naming changes
- then it can contain either a relative or an absolute URL -
@franzliedke do you agree?
When running migrations for an extension without any migrations (eg.
BBCode), the migration notes for the previous extension were being
displayed, because the Migrator never had a chance to clear them.
* Update Client.php
Now forwarding exceptions from client to page in case debug mode is on. Fixes#1120.
* Update Client.php
Satisfying .. the unsatisfiable.
* Update Client.php
Satisfying again.
* flagrow/byobu#11 making posts and discussions private
* tested migrations and tested setting is_private on discussion and post manually
* added phpdoc for Post and Discussion and added the casting for these attributes
* satisfying styleci
* fixes for review
* added new private discussion event and included it in the access policy
* added new private post event and included it in the access policy
* Fix ListPostsController::applyFilters not receiving array if argument not present
* Whoops! Use `[]` instead of `array()`
* Update AbstractSerializeController.php
* Update ListPostsController.php
* Added option to hide the language selector in the header
* Added `hide_language_selector` Switch to BasicsPage
* Added `hideLanguageSelector` property to ForumSerializer
* Apparently fixed the "Add Extension" button locale.... someone must not have compiled their changes :P
* Changed hideLanguageSelector (and such) to showLanguageSelector
* Change `core.admin.basics.show_language_selector_heading` to be `_label`
* Change showLanguageSelector in ForumSerializer to be boolean, default: true
* Ooops! Remove console.log 🤦♂️
* Added `language` and `direction` properties to WebAppView
* Use properties `language` and `direction` in app.blade.php
* Added WebAppView::setDescription to set the meta description
* Whoops! Changed "ltr" to \'ltr\'. Thanks StyleCI :)
* Removed unnecessary `= null` for
* Changed `.. ? .. : ..` to `.. ?: ..`. Useful thing right there ;)
The way I read it, HTTP 405 is a generic statement about the
resource. Once a language pack is not the default, this is not
true anymore, so I figured 403 is more correct.
I want to make it a little more clear that we are checking exactly
for these two values. That may also help preventing further confusion
as to why we are not using empty() here.
Amendment to PR #1033.
* Fix dependency version constraint. (Reverts #1066.)
* Allow exceptions to be raised when dispatching middleware.
* Fix our error handler middleware (do not implement Stratigility's
error handler interface, catch exceptions instead).
See https://docs.zendframework.com/zend-stratigility/migration/to-v2/.
Closes#1069.
* Add session option to Rememberer class
* Update session login function to allow send additional data
* Add Remember me checkbox
* Cleanup login modal
This is a bit sloppy (might come up with a better solution yet), but since most events provide access to the actor but not the request, this was the easiest/quickest way to allow extensions to access the session.
Since extensions may add nested includes, we need to make sure they are eager-loaded to avoid excessive queries. For example, when the tags extension adds "tags" and "tags.state".
