This little abstraction layer made it a bit easier to add a different title to a Note or Actor Feed Collection template, from whichever controller that uses it. Please, bear in mind, that abstract templates such as those found in Components\Collection, may act in a very 'declarative' way upon using them. This makes it difficult to dynamically choose what type of header is used without undergoing a mining operation in the likes of a pyramid of doom. Hence, this _little_ change.
[TWIG] Cards are now divided into blocks and macros, additional macros done, attachments page no longer inside cards directory
[CARDS][Navigation] Now using macros to create section, details, and nav elements
replies, conversation shows whole tree
[COMPONENTS][Feed] Added request to FormatNoteList event
Every single Note that was provided to FeedController::postProcess is
shown. This means, that even though the Feed is formatted to show only a
Note and its respective direct replies, those same replies are shown
individually again (and they get the chance to show their own direct
replies).
The Note list provided to FormatNoteList is reversed, and for every
index, the respective Note replies are filtered out of the original list.
The replies are then added as leafs of the current Note and added to the tree.
[PLUGINS][Favourite] Added complementary information on user action
[COMPONENTS][Conversation] Fixed AppendCardNote issue where cached query
would only act on Notes with depth > 1
[COMPONENTS][Posting] Call Conversation::assignLocalConversation upon
creating a new note
By using the AddExtraArgsToNoteContent event upon posting a Note, an
extra argument ('reply_to') is added before storing the aforementioned Note.
When storeLocalNote eventually creates the Note, the corresponding
Conversation is assigned.
If the source lacks capability of sending the reply_to metadata, it might be on the note content itself as a reference.
[ENTITY][Note] Documenting conversation/reply related functions. The entity Note reply_to shouldn't be trusted toknow whether or not the Note is a Conversation root. This will happen if a known remote user replies to an unknown remote user - within a known conversation.
Route for conversation added and Conversation Controller created.
[CONTROLLER][Conversation] Created ConversationShow function, will be used to render the conversation route page
[ENTITY][Note] Conversation id column added, this way a Note can have a direct relation with its respective conversation.
FeedController will only handle FormatNoteList if the should_format field is true.
This change was made to make the replies route feed possible, this route is added by the Conversation component. Since a reply isn't a conversation root, if the FeedController handled the FormatNoteList event, this feed wouldn't have any notes to display.
