TSP

It's also redundant when referring to a post within a topic - the title is displayed twice, with different formatting each time.

I would like for the embeds to contain a reference to the author name of the embedded content as before. In the previous version this would be contained within the title ("X replied to …")
I understand you currently reference the author with the avatar, however this is not enough information in most cases to understand who the author is. 
I hope you can consider adding the author name to these embeds, as it's something I've received feedback on from members, and I think it can be placed together with the date of when it was posted. 
For reference, example of embeds as they look now: 
In previous versions this was the look of embeds:


 

In version 4.4 you had a dedicated share link easily accessible on posts, which you've now moved within the ellipsis menu. 
When you clicked the share button in the previous version it would open the share dialog and the link text would already be selected so you could quickly copy it, this no longer happens.
So two suggestions: 
When you click the share link in the ellipsis menu, please auto-select the link text Bonus: add a "copy to paste"-button next to the input field 

After an upgrade to 4.5 we experienced a significant number of queries against our reputation index table that slowed our performance. A number of users also started reporting that they could no longer view any forums, as they would never load. 
Please reply to my summary in the bottom of this post. 
Below you can see both an example of a very slow query and the explain result for that query. As you can see it needs to do a where-statement on more than 13 million rows. 
SELECT * FROM `ibf_core_reputation_index` AS `core_reputation_index` WHERE rep_class='IPS\\forums\\Topic\\Post' AND ( item_id IN(1427817,1422962,1256153,1427714,1283836,1427156,1326714,1102313,1069811,1284132,1234402,914294,1315147,1424425,1262919,1296796,1292774,1402927,1260889,886634,1419146,1424086,1424395,1264620,1174675) ); +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | 1 | SIMPLE | core_reputation_index | NULL | ref | rep_class,leaderboard | rep_class | 403 | const | 13110152 | 50.00 | Using where | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+  
Upon investigating I found the culprit to be the new expanded view mode in forums for the topic listing. 
When the expanded view mode is selected you set $getReactions to true and call the "Content Table Helper". Line 90 in applications/forums/modules/front/forums/forums.php:
$getReactions = $getFirstComment = $getFollowerCount = (boolean) ( \IPS\forums\Forum::getMemberListView() === 'snippet' ); /* Init table (it won't show anything until after the password check, but it sets navigation and titles) */ $table = new \IPS\Helpers\Table\Content( 'IPS\forums\Topic', $forum->url(), $where, $forum, NULL, 'view', isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, NULL, $getFirstComment, $getFollowerCount, $getReactions );  
In system/Helpers/Table/Content.php you run the following query on line 409:
foreach( \IPS\Db::i()->select( '*', 'core_reputation_index', array( 'rep_class=? AND ' . \IPS\Db::i()->in( 'item_id', $itemIds ), $class::$commentClass ) ) as $react ) { $reactions[ $react['item_id'] ][] = $react; }  
You do this in order to show this reaction-thingy in the bottom corner of the first post when the expanded view mode is selected: 

 
Summary and concerns: 
It seems to be intentional that you want to aggregate which reactions have been used within the topic. At first I thought the reactions were connected to the first post, but it's not and upon clicking on it, it makes a topic request with extra parameters. For example /?do=showReactions&reaction=3&item=1
I would argue it's not at all obvious that it refers to an aggregate of reactions across the entire item. 
Either way, you seem to have chosen the worst possible method to get that aggregate data for a very small thing. 
Your first way of attempting to solve this would maybe be to add yet another index on the core_reputation_index table. One index that might improve the situation could be aggregate_item_lookup (rep_class, item_id, reaction). And also change the query to do a distinct query or grouped count query on those columns to figure out which reactions have been used within the topic.
BUT, even with such an index the query would probably still be problematic for us. We have more than a 1000 topics in total with more than 1000 posts in them, of which 128 of them have been active during the last 30 days. 
In any case, this small bit of extra information in an alternate viewing mode is causing a lot more overhead against the database table than it's worth. In my opinion it would be best to simply choose to let this like information be tied to only the first post or remove this bit of information alltogether. 

In order to troubleshoot high mysql load I would usually start by running the mysql query "SHOW FULL PROCESSLIST" to see if any/which queries have been running for a very long time.
Without more information it's very difficult to know, but you could test this if you have a very big community that uses reactions and are on version 4.5: disable the new topic list view. I reported a performance issue with this new view yesterday. 
You find it in the general forum settings. Deselect the setting "Members can choose" beneath the setting "Default topic list view", make sure you have selected the Condensed topic list View.
Using ACP search to find it: I was unable to search directly for the setting in the admin cp search, but you can search for "view" and then click "[Forums] Default forum view" in the result, it will take you to the same page (but the selected setting is not what you'll change)

In order to troubleshoot high mysql load I would usually start by running the mysql query "SHOW FULL PROCESSLIST" to see if any/which queries have been running for a very long time.
Without more information it's very difficult to know, but you could test this if you have a very big community that uses reactions and are on version 4.5: disable the new topic list view. I reported a performance issue with this new view yesterday. 
You find it in the general forum settings. Deselect the setting "Members can choose" beneath the setting "Default topic list view", make sure you have selected the Condensed topic list View.
Using ACP search to find it: I was unable to search directly for the setting in the admin cp search, but you can search for "view" and then click "[Forums] Default forum view" in the result, it will take you to the same page (but the selected setting is not what you'll change)

After an upgrade to 4.5 we experienced a significant number of queries against our reputation index table that slowed our performance. A number of users also started reporting that they could no longer view any forums, as they would never load. 
Please reply to my summary in the bottom of this post. 
Below you can see both an example of a very slow query and the explain result for that query. As you can see it needs to do a where-statement on more than 13 million rows. 
SELECT * FROM `ibf_core_reputation_index` AS `core_reputation_index` WHERE rep_class='IPS\\forums\\Topic\\Post' AND ( item_id IN(1427817,1422962,1256153,1427714,1283836,1427156,1326714,1102313,1069811,1284132,1234402,914294,1315147,1424425,1262919,1296796,1292774,1402927,1260889,886634,1419146,1424086,1424395,1264620,1174675) ); +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | 1 | SIMPLE | core_reputation_index | NULL | ref | rep_class,leaderboard | rep_class | 403 | const | 13110152 | 50.00 | Using where | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+  
Upon investigating I found the culprit to be the new expanded view mode in forums for the topic listing. 
When the expanded view mode is selected you set $getReactions to true and call the "Content Table Helper". Line 90 in applications/forums/modules/front/forums/forums.php:
$getReactions = $getFirstComment = $getFollowerCount = (boolean) ( \IPS\forums\Forum::getMemberListView() === 'snippet' ); /* Init table (it won't show anything until after the password check, but it sets navigation and titles) */ $table = new \IPS\Helpers\Table\Content( 'IPS\forums\Topic', $forum->url(), $where, $forum, NULL, 'view', isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, NULL, $getFirstComment, $getFollowerCount, $getReactions );  
In system/Helpers/Table/Content.php you run the following query on line 409:
foreach( \IPS\Db::i()->select( '*', 'core_reputation_index', array( 'rep_class=? AND ' . \IPS\Db::i()->in( 'item_id', $itemIds ), $class::$commentClass ) ) as $react ) { $reactions[ $react['item_id'] ][] = $react; }  
You do this in order to show this reaction-thingy in the bottom corner of the first post when the expanded view mode is selected: 

 
Summary and concerns: 
It seems to be intentional that you want to aggregate which reactions have been used within the topic. At first I thought the reactions were connected to the first post, but it's not and upon clicking on it, it makes a topic request with extra parameters. For example /?do=showReactions&reaction=3&item=1
I would argue it's not at all obvious that it refers to an aggregate of reactions across the entire item. 
Either way, you seem to have chosen the worst possible method to get that aggregate data for a very small thing. 
Your first way of attempting to solve this would maybe be to add yet another index on the core_reputation_index table. One index that might improve the situation could be aggregate_item_lookup (rep_class, item_id, reaction). And also change the query to do a distinct query or grouped count query on those columns to figure out which reactions have been used within the topic.
BUT, even with such an index the query would probably still be problematic for us. We have more than a 1000 topics in total with more than 1000 posts in them, of which 128 of them have been active during the last 30 days. 
In any case, this small bit of extra information in an alternate viewing mode is causing a lot more overhead against the database table than it's worth. In my opinion it would be best to simply choose to let this like information be tied to only the first post or remove this bit of information alltogether. 

The path to this setting is in the Community tab, second tab from top to bottom. Forums > Settings > Default topic list view
By the way, thank you. The performance of the forum was horrible, until I disabled it.

After an upgrade to 4.5 we experienced a significant number of queries against our reputation index table that slowed our performance. A number of users also started reporting that they could no longer view any forums, as they would never load. 
Please reply to my summary in the bottom of this post. 
Below you can see both an example of a very slow query and the explain result for that query. As you can see it needs to do a where-statement on more than 13 million rows. 
SELECT * FROM `ibf_core_reputation_index` AS `core_reputation_index` WHERE rep_class='IPS\\forums\\Topic\\Post' AND ( item_id IN(1427817,1422962,1256153,1427714,1283836,1427156,1326714,1102313,1069811,1284132,1234402,914294,1315147,1424425,1262919,1296796,1292774,1402927,1260889,886634,1419146,1424086,1424395,1264620,1174675) ); +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | 1 | SIMPLE | core_reputation_index | NULL | ref | rep_class,leaderboard | rep_class | 403 | const | 13110152 | 50.00 | Using where | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+  
Upon investigating I found the culprit to be the new expanded view mode in forums for the topic listing. 
When the expanded view mode is selected you set $getReactions to true and call the "Content Table Helper". Line 90 in applications/forums/modules/front/forums/forums.php:
$getReactions = $getFirstComment = $getFollowerCount = (boolean) ( \IPS\forums\Forum::getMemberListView() === 'snippet' ); /* Init table (it won't show anything until after the password check, but it sets navigation and titles) */ $table = new \IPS\Helpers\Table\Content( 'IPS\forums\Topic', $forum->url(), $where, $forum, NULL, 'view', isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, NULL, $getFirstComment, $getFollowerCount, $getReactions );  
In system/Helpers/Table/Content.php you run the following query on line 409:
foreach( \IPS\Db::i()->select( '*', 'core_reputation_index', array( 'rep_class=? AND ' . \IPS\Db::i()->in( 'item_id', $itemIds ), $class::$commentClass ) ) as $react ) { $reactions[ $react['item_id'] ][] = $react; }  
You do this in order to show this reaction-thingy in the bottom corner of the first post when the expanded view mode is selected: 

 
Summary and concerns: 
It seems to be intentional that you want to aggregate which reactions have been used within the topic. At first I thought the reactions were connected to the first post, but it's not and upon clicking on it, it makes a topic request with extra parameters. For example /?do=showReactions&reaction=3&item=1
I would argue it's not at all obvious that it refers to an aggregate of reactions across the entire item. 
Either way, you seem to have chosen the worst possible method to get that aggregate data for a very small thing. 
Your first way of attempting to solve this would maybe be to add yet another index on the core_reputation_index table. One index that might improve the situation could be aggregate_item_lookup (rep_class, item_id, reaction). And also change the query to do a distinct query or grouped count query on those columns to figure out which reactions have been used within the topic.
BUT, even with such an index the query would probably still be problematic for us. We have more than a 1000 topics in total with more than 1000 posts in them, of which 128 of them have been active during the last 30 days. 
In any case, this small bit of extra information in an alternate viewing mode is causing a lot more overhead against the database table than it's worth. In my opinion it would be best to simply choose to let this like information be tied to only the first post or remove this bit of information alltogether. 

I would like for the embeds to contain a reference to the author name of the embedded content as before. In the previous version this would be contained within the title ("X replied to …")
I understand you currently reference the author with the avatar, however this is not enough information in most cases to understand who the author is. 
I hope you can consider adding the author name to these embeds, as it's something I've received feedback on from members, and I think it can be placed together with the date of when it was posted. 
For reference, example of embeds as they look now: 
In previous versions this was the look of embeds:


 

After an upgrade to 4.5 we experienced a significant number of queries against our reputation index table that slowed our performance. A number of users also started reporting that they could no longer view any forums, as they would never load. 
Please reply to my summary in the bottom of this post. 
Below you can see both an example of a very slow query and the explain result for that query. As you can see it needs to do a where-statement on more than 13 million rows. 
SELECT * FROM `ibf_core_reputation_index` AS `core_reputation_index` WHERE rep_class='IPS\\forums\\Topic\\Post' AND ( item_id IN(1427817,1422962,1256153,1427714,1283836,1427156,1326714,1102313,1069811,1284132,1234402,914294,1315147,1424425,1262919,1296796,1292774,1402927,1260889,886634,1419146,1424086,1424395,1264620,1174675) ); +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+ | 1 | SIMPLE | core_reputation_index | NULL | ref | rep_class,leaderboard | rep_class | 403 | const | 13110152 | 50.00 | Using where | +----+-------------+-----------------------+------------+------+-----------------------+-----------+---------+-------+----------+----------+-------------+  
Upon investigating I found the culprit to be the new expanded view mode in forums for the topic listing. 
When the expanded view mode is selected you set $getReactions to true and call the "Content Table Helper". Line 90 in applications/forums/modules/front/forums/forums.php:
$getReactions = $getFirstComment = $getFollowerCount = (boolean) ( \IPS\forums\Forum::getMemberListView() === 'snippet' ); /* Init table (it won't show anything until after the password check, but it sets navigation and titles) */ $table = new \IPS\Helpers\Table\Content( 'IPS\forums\Topic', $forum->url(), $where, $forum, NULL, 'view', isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, isset( \IPS\Request::i()->rss ) ? FALSE : TRUE, NULL, $getFirstComment, $getFollowerCount, $getReactions );  
In system/Helpers/Table/Content.php you run the following query on line 409:
foreach( \IPS\Db::i()->select( '*', 'core_reputation_index', array( 'rep_class=? AND ' . \IPS\Db::i()->in( 'item_id', $itemIds ), $class::$commentClass ) ) as $react ) { $reactions[ $react['item_id'] ][] = $react; }  
You do this in order to show this reaction-thingy in the bottom corner of the first post when the expanded view mode is selected: 

 
Summary and concerns: 
It seems to be intentional that you want to aggregate which reactions have been used within the topic. At first I thought the reactions were connected to the first post, but it's not and upon clicking on it, it makes a topic request with extra parameters. For example /?do=showReactions&reaction=3&item=1
I would argue it's not at all obvious that it refers to an aggregate of reactions across the entire item. 
Either way, you seem to have chosen the worst possible method to get that aggregate data for a very small thing. 
Your first way of attempting to solve this would maybe be to add yet another index on the core_reputation_index table. One index that might improve the situation could be aggregate_item_lookup (rep_class, item_id, reaction). And also change the query to do a distinct query or grouped count query on those columns to figure out which reactions have been used within the topic.
BUT, even with such an index the query would probably still be problematic for us. We have more than a 1000 topics in total with more than 1000 posts in them, of which 128 of them have been active during the last 30 days. 
In any case, this small bit of extra information in an alternate viewing mode is causing a lot more overhead against the database table than it's worth. In my opinion it would be best to simply choose to let this like information be tied to only the first post or remove this bit of information alltogether. 

I would like for the embeds to contain a reference to the author name of the embedded content as before. In the previous version this would be contained within the title ("X replied to …")
I understand you currently reference the author with the avatar, however this is not enough information in most cases to understand who the author is. 
I hope you can consider adding the author name to these embeds, as it's something I've received feedback on from members, and I think it can be placed together with the date of when it was posted. 
For reference, example of embeds as they look now: 
In previous versions this was the look of embeds:


 

I discussed this briefly with @Daniel F and @Martin A. a week ago, but I'm creating this topic to make sure it's not forgotten and it can hopefully be added to some todo-list for a future version.
I realize there might be good reason for why you've done something like you've done, but in that case I would happy to hear about the reasoning and maybe get some discussion on it.
Example 1: Badges
This is part of your template code in forums/front/topics/post.phtml:
<div class='ipsResponsive_hidePhone ipsComment_badges'> <ul class='ipsList_reset ipsFlex ipsFlex-jc:end ipsFlex-fw:wrap ipsGap:2 ipsGap_row:1'> {{if ! $comment->isFirst() and $comment->author()->member_id AND $comment->author()->member_id == $item->author()->member_id}} <li><strong class="ipsBadge ipsBadge_large ipsComment_authorBadge">{lang="author"}</strong></li> {{endif}} {{if $comment->author()->hasHighlightedReplies()}} <li><strong class='ipsBadge ipsBadge_large ipsBadge_highlightedGroup'>{expression="\IPS\Member\Group::load( $comment->author()->member_group_id )->name" raw="true"}</strong></li> {{endif}} {{if ( $comment->item()->isSolved() and $comment->item()->mapped('solved_comment_id') == $comment->pid )}} <li><strong class='ipsBadge ipsBadge_large ipsBadge_positive ipsBadge_reverse'><i class='fa fa-check'></i> {lang="this_is_a_solved_post"}</strong></li> {{endif}} {{if $comment->isFeatured()}} <li><strong class='ipsBadge ipsBadge_large ipsBadge_popular'>{lang="this_is_a_featured_post"}</strong></li> {{endif}} {{if ( settings.reputation_enabled and settings.reputation_highlight and $comment->reactionCount() >= settings.reputation_highlight ) }} <li><strong class='ipsBadge ipsBadge_large ipsBadge_popular'>{lang="this_is_a_popular_post"}</strong></li> {{endif}} </ul> </div> I have a plugin where I want to remove the "Author"-badge in some circumstances. In order to do this, I have to choose the following hook point and do a replace: div[data-controller='core.front.core.comment'] div.ipsComment_badges > ul > li > strong.ipsComment_authorBadge
The problem here is that the element I really would want to target is the li-element, but I can't. The consequence is that I leave an empty li-element behind and this creates extra spacing in the theme (which may or not be visible depending on whether there's another badge next to it)
My solution to this is: 
public function post( $item, $comment, $editorName, $app, $type, $class='' ) { $return = parent::post( $item, $comment, $editorName, $app, $type, $class ); return str_replace( "<li>\n<!-- Post anonymously: removed author-badge -->\n</li>", '<!-- Post anonymously: removed author-badge and empty li-tag -->', $return ); } But this will more likely be something that will cause issues on an upgrade.
It would be better if there was a getBadges()-function that would provide the badges and I could override. 
Example 2: Ellipsis menu and/or moderation tools:
You also have an awful lot of logic in your templates that has to do with moderation tools. Look at all this stuff, from the same template: 
<ul id='elControls_{$comment->$idField}_menu' class='ipsMenu ipsMenu_narrow ipsHide'> {{if $comment->canReportOrRevoke() === TRUE}} <li class='ipsMenu_item'><a href='{$comment->url('report')}' data-ipsDialog data-ipsDialog-remoteSubmit data-ipsDialog-size='medium' data-ipsDialog-flashMessage='{lang="report_submit_success"}' data-ipsDialog-title="{lang="report_post"}" data-action='reportComment' title='{lang="report_content"}'>{lang="report"}</a></li> {{endif}} {{if $comment->mapped('first') }} <li class='ipsMenu_item'><a href='{$comment->item()->url()}' title='{lang="share_this_post"}' data-ipsDialog data-ipsDialog-size='narrow' data-ipsDialog-content='#elSharePost_{$comment->$idField}_menu' data-ipsDialog-title="{lang="share_this_post"}" d='elSharePost_{$comment->$idField}' data-role='shareComment'>{lang="share"}</a></li> {{else}} <li class='ipsMenu_item'><a href='{$comment->item()->url()->setQueryString( array( 'do' => 'findComment', 'comment' => $comment->$idField ) )}' title='{lang="share_this_post"}' data-ipsDialog data-ipsDialog-size='narrow' data-ipsDialog-content='#elSharePost_{$comment->$idField}_menu' data-ipsDialog-title="{lang="share_this_post"}" id='elSharePost_{$comment->$idField}' data-role='shareComment'>{lang="share"}</a></li> {{endif}} {{if $comment->canEdit() || ( !$comment->mapped('first') and ( $comment->canPromoteToSocialMedia() || $comment->item()->canSolve() || $comment->canDelete() || $comment->canHide() || $comment->canUnhide() || $comment->canSplit() || $item->canFeatureComment() || $item->canUnfeatureComment() || ( $comment->hidden() == -2 AND \IPS\Member::loggedIn()->modPermission('can_manage_deleted_content') ) ) )}} <li class='ipsMenu_sep'><hr></li> {{endif}} {{if $comment->canEdit()}} {{if $comment->mapped('first') and $comment->item()->canEdit()}} <li class='ipsMenu_item'><a href='{$comment->item()->url()->setQueryString( 'do', 'edit' )}'>{lang="edit"}</a></li> {{else}} <li class='ipsMenu_item'><a href='{$comment->url('edit')}' data-action='editComment'>{lang="edit"}</a></li> {{endif}} {{endif}} {{if $comment->hidden() == -2 AND \IPS\Member::loggedIn()->modPermission('can_manage_deleted_content')}} <li class='ipsMenu_item'><a href='{$comment->url('restore')->csrf()}' data-confirm data-confirmSubMessage='{lang="restore_as_visible_desc"}'>{lang="restore_as_visible"}</a></li> <li class='ipsMenu_item'><a href='{$comment->url('restore')->csrf()->setQueryString( 'restoreAsHidden', 1 )}' data-confirm data-confirmSubMessage='{lang="restore_as_hidden_desc"}'>{lang="restore_as_hidden"}</a></li> <li class='ipsMenu_item'><a href='{$comment->url('delete')->csrf()->setQueryString( 'immediately', 1 )}' data-confirm data-confirmSubMessage='{lang="delete_immediately_desc"}'>{lang="delete_immediately"}</a></li> {{else}} {{if $comment instanceof \IPS\Content\Hideable}} {{if !$comment->hidden() and $comment->canHide()}} <li class='ipsMenu_item'><a href='{$comment->url('hide')->csrf()}' data-ipsDialog data-ipsDialog-title="{lang="hide"}">{lang="hide"}</a></li> {{elseif $comment->hidden() and $comment->canUnhide()}} <li class='ipsMenu_item'><a href='{$comment->url('unhide')->csrf()}'>{lang="unhide"}</a></li> {{endif}} {{endif}} {{if $comment->canSplit()}} <li class='ipsMenu_item'><a href='{$comment->url('split')}' data-action='splitComment' data-ipsDialog data-ipsDialog-title="{lang="split_to_new" sprintf="\IPS\Member::loggedIn()->language()->addToStack( $item::$title )"}">{lang="split"}</a></li> {{endif}} {{if $comment->canDelete()}} <li class='ipsMenu_item'><a href='{$comment->url('delete')->csrf()->setPage('page',\IPS\Request::i()->page)}' data-action='deleteComment' data-updateOnDelete="#commentCount">{lang="delete"}</a></li> {{endif}} {{if $comment->isFeatured() AND $item->canUnfeatureComment()}} <li class='ipsMenu_item'><a href='{$comment->url('unfeature')->csrf()->setPage('page',\IPS\Request::i()->page)}' data-action="unrecommendComment">{lang="unrecommend_content"}</a></li> {{endif}} {{if !$comment->isFeatured() AND $item->canFeatureComment()}} <li class='ipsMenu_item'><a href='{$comment->url('feature')->csrf()->setPage('page',\IPS\Request::i()->page)}' data-ipsDialog data-ipsDialog-title='{lang="recommend_post"}' data-ipsDialog-remoteSubmit data-ipsDialog-size='medium' data-action="recommendComment">{lang="recommend_content"}</a></li> {{endif}} {{if ( ! $comment->mapped('first') and $comment->canPromoteToSocialMedia() )}} <li class='ipsMenu_item'>{template="promoteLink" app="core" group="global" params="$comment"}</li> {{endif}} {{endif}} </ul> In my opinion a lot of this logic should rather come from new and more sentralized functions like: $comment->getModeratorOptions() or something that would return a list of prepared <a>-elements or an array or object with the necessary components to also set things like 'data-ipsDialog' etc. for some items. 

I discussed this briefly with @Daniel F and @Martin A. a week ago, but I'm creating this topic to make sure it's not forgotten and it can hopefully be added to some todo-list for a future version.
I realize there might be good reason for why you've done something like you've done, but in that case I would happy to hear about the reasoning and maybe get some discussion on it.
Example 1: Badges
This is part of your template code in forums/front/topics/post.phtml:
<div class='ipsResponsive_hidePhone ipsComment_badges'> <ul class='ipsList_reset ipsFlex ipsFlex-jc:end ipsFlex-fw:wrap ipsGap:2 ipsGap_row:1'> {{if ! $comment->isFirst() and $comment->author()->member_id AND $comment->author()->member_id == $item->author()->member_id}} <li><strong class="ipsBadge ipsBadge_large ipsComment_authorBadge">{lang="author"}</strong></li> {{endif}} {{if $comment->author()->hasHighlightedReplies()}} <li><strong class='ipsBadge ipsBadge_large ipsBadge_highlightedGroup'>{expression="\IPS\Member\Group::load( $comment->author()->member_group_id )->name" raw="true"}</strong></li> {{endif}} {{if ( $comment->item()->isSolved() and $comment->item()->mapped('solved_comment_id') == $comment->pid )}} <li><strong class='ipsBadge ipsBadge_large ipsBadge_positive ipsBadge_reverse'><i class='fa fa-check'></i> {lang="this_is_a_solved_post"}</strong></li> {{endif}} {{if $comment->isFeatured()}} <li><strong class='ipsBadge ipsBadge_large ipsBadge_popular'>{lang="this_is_a_featured_post"}</strong></li> {{endif}} {{if ( settings.reputation_enabled and settings.reputation_highlight and $comment->reactionCount() >= settings.reputation_highlight ) }} <li><strong class='ipsBadge ipsBadge_large ipsBadge_popular'>{lang="this_is_a_popular_post"}</strong></li> {{endif}} </ul> </div> I have a plugin where I want to remove the "Author"-badge in some circumstances. In order to do this, I have to choose the following hook point and do a replace: div[data-controller='core.front.core.comment'] div.ipsComment_badges > ul > li > strong.ipsComment_authorBadge
The problem here is that the element I really would want to target is the li-element, but I can't. The consequence is that I leave an empty li-element behind and this creates extra spacing in the theme (which may or not be visible depending on whether there's another badge next to it)
My solution to this is: 
public function post( $item, $comment, $editorName, $app, $type, $class='' ) { $return = parent::post( $item, $comment, $editorName, $app, $type, $class ); return str_replace( "<li>\n<!-- Post anonymously: removed author-badge -->\n</li>", '<!-- Post anonymously: removed author-badge and empty li-tag -->', $return ); } But this will more likely be something that will cause issues on an upgrade.
It would be better if there was a getBadges()-function that would provide the badges and I could override. 
Example 2: Ellipsis menu and/or moderation tools:
You also have an awful lot of logic in your templates that has to do with moderation tools. Look at all this stuff, from the same template: 
<ul id='elControls_{$comment->$idField}_menu' class='ipsMenu ipsMenu_narrow ipsHide'> {{if $comment->canReportOrRevoke() === TRUE}} <li class='ipsMenu_item'><a href='{$comment->url('report')}' data-ipsDialog data-ipsDialog-remoteSubmit data-ipsDialog-size='medium' data-ipsDialog-flashMessage='{lang="report_submit_success"}' data-ipsDialog-title="{lang="report_post"}" data-action='reportComment' title='{lang="report_content"}'>{lang="report"}</a></li> {{endif}} {{if $comment->mapped('first') }} <li class='ipsMenu_item'><a href='{$comment->item()->url()}' title='{lang="share_this_post"}' data-ipsDialog data-ipsDialog-size='narrow' data-ipsDialog-content='#elSharePost_{$comment->$idField}_menu' data-ipsDialog-title="{lang="share_this_post"}" d='elSharePost_{$comment->$idField}' data-role='shareComment'>{lang="share"}</a></li> {{else}} <li class='ipsMenu_item'><a href='{$comment->item()->url()->setQueryString( array( 'do' => 'findComment', 'comment' => $comment->$idField ) )}' title='{lang="share_this_post"}' data-ipsDialog data-ipsDialog-size='narrow' data-ipsDialog-content='#elSharePost_{$comment->$idField}_menu' data-ipsDialog-title="{lang="share_this_post"}" id='elSharePost_{$comment->$idField}' data-role='shareComment'>{lang="share"}</a></li> {{endif}} {{if $comment->canEdit() || ( !$comment->mapped('first') and ( $comment->canPromoteToSocialMedia() || $comment->item()->canSolve() || $comment->canDelete() || $comment->canHide() || $comment->canUnhide() || $comment->canSplit() || $item->canFeatureComment() || $item->canUnfeatureComment() || ( $comment->hidden() == -2 AND \IPS\Member::loggedIn()->modPermission('can_manage_deleted_content') ) ) )}} <li class='ipsMenu_sep'><hr></li> {{endif}} {{if $comment->canEdit()}} {{if $comment->mapped('first') and $comment->item()->canEdit()}} <li class='ipsMenu_item'><a href='{$comment->item()->url()->setQueryString( 'do', 'edit' )}'>{lang="edit"}</a></li> {{else}} <li class='ipsMenu_item'><a href='{$comment->url('edit')}' data-action='editComment'>{lang="edit"}</a></li> {{endif}} {{endif}} {{if $comment->hidden() == -2 AND \IPS\Member::loggedIn()->modPermission('can_manage_deleted_content')}} <li class='ipsMenu_item'><a href='{$comment->url('restore')->csrf()}' data-confirm data-confirmSubMessage='{lang="restore_as_visible_desc"}'>{lang="restore_as_visible"}</a></li> <li class='ipsMenu_item'><a href='{$comment->url('restore')->csrf()->setQueryString( 'restoreAsHidden', 1 )}' data-confirm data-confirmSubMessage='{lang="restore_as_hidden_desc"}'>{lang="restore_as_hidden"}</a></li> <li class='ipsMenu_item'><a href='{$comment->url('delete')->csrf()->setQueryString( 'immediately', 1 )}' data-confirm data-confirmSubMessage='{lang="delete_immediately_desc"}'>{lang="delete_immediately"}</a></li> {{else}} {{if $comment instanceof \IPS\Content\Hideable}} {{if !$comment->hidden() and $comment->canHide()}} <li class='ipsMenu_item'><a href='{$comment->url('hide')->csrf()}' data-ipsDialog data-ipsDialog-title="{lang="hide"}">{lang="hide"}</a></li> {{elseif $comment->hidden() and $comment->canUnhide()}} <li class='ipsMenu_item'><a href='{$comment->url('unhide')->csrf()}'>{lang="unhide"}</a></li> {{endif}} {{endif}} {{if $comment->canSplit()}} <li class='ipsMenu_item'><a href='{$comment->url('split')}' data-action='splitComment' data-ipsDialog data-ipsDialog-title="{lang="split_to_new" sprintf="\IPS\Member::loggedIn()->language()->addToStack( $item::$title )"}">{lang="split"}</a></li> {{endif}} {{if $comment->canDelete()}} <li class='ipsMenu_item'><a href='{$comment->url('delete')->csrf()->setPage('page',\IPS\Request::i()->page)}' data-action='deleteComment' data-updateOnDelete="#commentCount">{lang="delete"}</a></li> {{endif}} {{if $comment->isFeatured() AND $item->canUnfeatureComment()}} <li class='ipsMenu_item'><a href='{$comment->url('unfeature')->csrf()->setPage('page',\IPS\Request::i()->page)}' data-action="unrecommendComment">{lang="unrecommend_content"}</a></li> {{endif}} {{if !$comment->isFeatured() AND $item->canFeatureComment()}} <li class='ipsMenu_item'><a href='{$comment->url('feature')->csrf()->setPage('page',\IPS\Request::i()->page)}' data-ipsDialog data-ipsDialog-title='{lang="recommend_post"}' data-ipsDialog-remoteSubmit data-ipsDialog-size='medium' data-action="recommendComment">{lang="recommend_content"}</a></li> {{endif}} {{if ( ! $comment->mapped('first') and $comment->canPromoteToSocialMedia() )}} <li class='ipsMenu_item'>{template="promoteLink" app="core" group="global" params="$comment"}</li> {{endif}} {{endif}} </ul> In my opinion a lot of this logic should rather come from new and more sentralized functions like: $comment->getModeratorOptions() or something that would return a list of prepared <a>-elements or an array or object with the necessary components to also set things like 'data-ipsDialog' etc. for some items. 

Why is this not possible already? We can merge topics, close them, sticky them, delete them - but there is no way to choose topics from a result set when searching and move them to another category. There really should be a way to do this from a result set that contains topics.

It would really speed up the process of moving topics when new forums are created.

If one request times out in the JS upgrader, it falls back to the considerably slower HTML-based upgrader. Could there not be some logic to retry the request a couple of times, ideally with a bit of backoff (if it's an nginx or transport layer error it's probably a timeout, and retrying will then hit the case where the task is already done), rather than making the upgrade experience suck? At worst, the HTML upgrader shouldn't have delays between redirects - as soon as the response comes back it is ready to receive another request.
It's reasonably easy to work around by just deleting the mr parameter from the URL, but that relies on me paying attention to the upgrader.

That's a @Charles thing. I'm not allowed near servers, right @TSP?

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

Someone deserves a raise! 
I'm working on an upgrade to 4.5 now where I'm updating a custom theme, and as a result I saw that this bit of feedback has finally been resolved 😄
Sorry for the bump, but I had a slight squeal of joy as I saw this, as it has been one of those annoying little pet peeves I've had with the default theme for some years now. 

Thanks I've posted an internal bug report to get this checked.

XRegExp is 135KB when minified as part of root_library.js (that whole bundle is only 383KB, so it's a significant chunk), but it's only used in two places:
In ipsautolink/plugin.js, it's just used to evaluate a native JS regex, which I believe is totally unnecessary (use this.urlRegex.test(text) instead!) In ips.search.results.js, where it's just used to replace using a native JS regex (use $(this).text().replace(new RegExp(...), '...') instead, as you do for each subsequent replacement in that chain) (while you're at it, why does that code replace with HTML, HTML escape everything, then selectively unescape the content you just added?!) Removing those two places that don't, to my understanding, utilise the library in any meaningful way would allow you to slim down the site by a not-insignificant amount, and make certain people happy.