Make the Request available to the Formatter\Rendering event

[tobyzerner]

Make the Request available to the Formatter\Rendering event.

This is important because extensions may wish to render post content
differently depending on Request factors such as the actor. For example,
an attachments extension might wish to hide attachments from guests.

This solution is a bit of a hack-job for now, but soon when we refactor
the API layer to use tobscure/json-api-server, and also refactor the
Formatter layer, it can be revised.

Confirmed

• Frontend changes: tested on a local Flarum installation.
• Backend changes: tests are green (run php vendor/bin/phpunit).

[franzliedke]

Can you explain the use case in more detail? It does feel very icky to introduce dependencies to HTTP-level classes in our core domain code.

[tobyzerner]

Use-cases:

1. An attachments extension allows embedding of attachments within post content. However the forum admin has decided to only allow logged-in users to download attachments. So if you are viewing the post as a guest, the post should be rendered with "log in to download this attachment" instead of the attachment preview/download link.

2. (My client's use case) Users on a forum have display names as their full name (eg. Toby Zerner). However for privacy reasons we don't want search engines to be indexing full names. So for guests, the display name shown in @mentions should be altered to only show the initial of the last name (eg. @Toby Z).

Basically, I'm arguing that rendering a post's content is intrinsically a request/actor-dependent process, just like serialising the rest of the post data is. The parsed post content is part of the core domain, but actually rendering it is a presentation-level event.

[franzliedke]

Okay, but both of these examples only need the actor, not the request, right?

[tobyzerner]

Well yes, but I think the concept of an actor is still HTTP-level rather than domain. Take example use-case 1 but instead of being logged in you need to enter a password which sets a session flag to true. (I did something like this for another client who wanted certain tags to be password-protected.)

API serializers should definitely be receiving the whole request (the equivalent in tobscure/json-api-server does) and by extension rendering should as well.

[franzliedke]

Well, then, looking forward to json-api-servers and more extenders. 😀