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?
* 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.
