TSP

I agree. I love the auto-expand editor for simple posts, but whenever I make longer posts and want to apply formatting it becomes tedious if I want to do something else than underline, italic and bold (ctrl + u/i/b) further down in the post.
Now I need to select text, scroll up, choose a style, scroll down to see how it looks, scroll up to do changes, scroll down to review again etc. Sometimes I might even be confused as to what I have currently selected and need to scroll down just to double check that.
So I would want some solution here, but I personally like the auto-expand up until the point I wish to apply formatting. So a solution for me would not be to have the editor area be a fixed height.
So either fixed toolbar (could be minimized until clicked or hovering some toggle button) or a toggle that would allow me to make the editor a fixed height temporarily would be preferred solutions.

This issue is resolved for our upcoming 4.6 release.
 

@Rikki @Ehren
Safari 10 and 11 apparently have an issue with the use of rgb() / rgba() in combination with --css-variables within certain CSS properties like border and box-shadow. I found one specific bug in your default theme that you can fix, other than that I just want to make you aware of this, as I had to spend quite a lot of time debugging this myself. 
After an upgrade from 4.4 I got a number of complaints about how there was now a grey circle covering the reaction button and the number of likes. People reported having the issue on desktop, mobile and tablet. Initially I was unable to reproduce and started to ask for more details. One of the users provided me with a user agent string which led me to reproduce the issue and discovering another one.
This image displays two of the issues I found in our theme:

 
This image displays how it looked in Safari 9(!), Safari 12+ and other browsers:

How to reproduce issue 1 on a community: 
You need to be logged in with a member account that's able to give reactions, and: 
The reaction setup: In my case only the standard like-reaction is enabled, all other reactions disabled. We use the upvote-image for the like-reaction. Reaction display is set to Overall reaction value.
Reproduced with: Browserstack -> Mac -> High Sierra -> Safari 11.1 (or other environments with Safari 10 or 11)
Please note: only issue 1 can be reproduced in the default theme, but I'm also mentioning my second issue just to provide an additional example. 
Cause/solution for Issue 1 / Bug in default theme) Grey circle covering like button and reaction value
This is caused by the following CSS rule in applications/core/dev/css/global/framework/engagement.css
a.ipsReact_reaction:after { position: absolute; top: 50%; width: 70px; height: 70px; border-radius: 50%; content: ''; display: block; opacity: 1; pointer-events: none; box-shadow: inset 0 0 0 35px rgba( var(--theme-text_color), 0 ); } More specifically the issue is with the box-shadow line at the bottom. Unless I'm missing something, this rule is the equivalent of:
box-shadow: inset 0 0 0 35px transparent;
Changing the value of box-shadow to "inset 0 0 0 35px transparent" at least fixes the issue. But I guess this might affect the animation styles you have further below in the same stylesheet. I don't know what a better solution would be, but I at least think you should make sure that the reaction button and reaction value are available in Safari 10 and 11, which they are not currently. 
Cause/solution for Issue 2) Black color instead of lighter border color around posts
So the second issue was caused by custom CSS from me, but I'm including it since it highlights the rgb/rgba problem with another CSS property as well. 
My CSS-rule was: 
article.ipsComment { border: 1px solid rgb(var(--theme-ehm_grey2)); border-radius: 10px; } The solution here was to instead use border-style and border-width and then add:
border-color: rgb(var(--theme-ehm_grey2));
So rgb() + --css-var worked within the value of the border-color property, but not within the border property.
Note that if you do not use a variable within rgb for the border-property, then it would also use the correct color: border: 1px solid rgb(235,235,235); 
Meaning it's the combination of rgb/rgba-function and --css-variables that is causing the issue. Not the rgb-function on it's own
In summary / other findings / questions:
1) Safari 10 and 11 apparently have an issue with the use of rgb() / rgba() in combination with --css-variables within certain properties. In most cases it probably doesn't cause too much trouble, but I think you should at least fix the reaction styling issue and also just be aware of this issue. 
2) I personally found it very weird this issue is not in Safari 9. It seems it worked as it should Safari 9, then they broke it for Safari 10&11, before it was fixed again for Safari 12 and newer. Unless you have some kind of compatibility CSS rules or javascript that kicks in for Safari 9 but not 10/11?
3) I did a quick search on google about this and found a note about this from 2018 in another software project: https://github.com/ionic-team/ionic-framework/issues/16123
They gave an alternate way to debug and solve this (which I haven't tested myself): 
 

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)

Hello, 
I haven't had time to update or test this on 4.5 yet. I don't know when either unfortunately

Btw, super minor, but also notice in the if
data-ipsDialog-title="{lang="share_this_post"}" d='elSharePost_{$comment->$idField}' should be id=, instead of d=

I've logged a bug report to have this checked into, thanks.

Hello, 
Would like to propose that you add an option to have the option "Let others see that I follow this", when following items, deselected by default. 
Some users are very privacy oriented and see no reason this is enabled by default as they have to deselect it every time. This should then also affect the "Follow item" checkbox in the reply forms. 
Thanks for the consideration

When sending a warning, the popup dialog covers the entire content you clicked from, including who the warning is going to. There's nothing in the box that tells you who is receiving the message, nor that shows you the content itself so you can reference both in the message to moderators or to the member.
This is some first class nonsense. I have the memory of a goldfish left out of water for a day and a half, and can't remember how many letters or numbers or whatever a person had in their display name to address them properly, nor can I grab quotes of text from the content easily to reference.
Please fix this UX oversight. K. thx. bai.

@Rikki @Ehren
Safari 10 and 11 apparently have an issue with the use of rgb() / rgba() in combination with --css-variables within certain CSS properties like border and box-shadow. I found one specific bug in your default theme that you can fix, other than that I just want to make you aware of this, as I had to spend quite a lot of time debugging this myself. 
After an upgrade from 4.4 I got a number of complaints about how there was now a grey circle covering the reaction button and the number of likes. People reported having the issue on desktop, mobile and tablet. Initially I was unable to reproduce and started to ask for more details. One of the users provided me with a user agent string which led me to reproduce the issue and discovering another one.
This image displays two of the issues I found in our theme:

 
This image displays how it looked in Safari 9(!), Safari 12+ and other browsers:

How to reproduce issue 1 on a community: 
You need to be logged in with a member account that's able to give reactions, and: 
The reaction setup: In my case only the standard like-reaction is enabled, all other reactions disabled. We use the upvote-image for the like-reaction. Reaction display is set to Overall reaction value.
Reproduced with: Browserstack -> Mac -> High Sierra -> Safari 11.1 (or other environments with Safari 10 or 11)
Please note: only issue 1 can be reproduced in the default theme, but I'm also mentioning my second issue just to provide an additional example. 
Cause/solution for Issue 1 / Bug in default theme) Grey circle covering like button and reaction value
This is caused by the following CSS rule in applications/core/dev/css/global/framework/engagement.css
a.ipsReact_reaction:after { position: absolute; top: 50%; width: 70px; height: 70px; border-radius: 50%; content: ''; display: block; opacity: 1; pointer-events: none; box-shadow: inset 0 0 0 35px rgba( var(--theme-text_color), 0 ); } More specifically the issue is with the box-shadow line at the bottom. Unless I'm missing something, this rule is the equivalent of:
box-shadow: inset 0 0 0 35px transparent;
Changing the value of box-shadow to "inset 0 0 0 35px transparent" at least fixes the issue. But I guess this might affect the animation styles you have further below in the same stylesheet. I don't know what a better solution would be, but I at least think you should make sure that the reaction button and reaction value are available in Safari 10 and 11, which they are not currently. 
Cause/solution for Issue 2) Black color instead of lighter border color around posts
So the second issue was caused by custom CSS from me, but I'm including it since it highlights the rgb/rgba problem with another CSS property as well. 
My CSS-rule was: 
article.ipsComment { border: 1px solid rgb(var(--theme-ehm_grey2)); border-radius: 10px; } The solution here was to instead use border-style and border-width and then add:
border-color: rgb(var(--theme-ehm_grey2));
So rgb() + --css-var worked within the value of the border-color property, but not within the border property.
Note that if you do not use a variable within rgb for the border-property, then it would also use the correct color: border: 1px solid rgb(235,235,235); 
Meaning it's the combination of rgb/rgba-function and --css-variables that is causing the issue. Not the rgb-function on it's own
In summary / other findings / questions:
1) Safari 10 and 11 apparently have an issue with the use of rgb() / rgba() in combination with --css-variables within certain properties. In most cases it probably doesn't cause too much trouble, but I think you should at least fix the reaction styling issue and also just be aware of this issue. 
2) I personally found it very weird this issue is not in Safari 9. It seems it worked as it should Safari 9, then they broke it for Safari 10&11, before it was fixed again for Safari 12 and newer. Unless you have some kind of compatibility CSS rules or javascript that kicks in for Safari 9 but not 10/11?
3) I did a quick search on google about this and found a note about this from 2018 in another software project: https://github.com/ionic-team/ionic-framework/issues/16123
They gave an alternate way to debug and solve this (which I haven't tested myself): 
 

PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.

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 

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: