TSP

I tried to change the image titles here: By editing the post, and double clicking the images, you get additional options. One of those options is "Image title", which on this community, and other cloud communities, is by default generated text by some AI recognition-service. I changed these image titles, but upon saving the post, the old AI-generated captions is still there on hover, even after a refresh. And if you edit the post again, you can see it's back to the AI generated captions when double clicking the images.

Nitpicking... but wouldn't uploads/logs/*.php be covered by uploads/*, so the former one is superfluous?

I currently send some datalayer-information in the themes of the forums I manage. I saw that you've implemented a datalayer-section and decided to take a peak at whether it would make sense for me to utilize that instead. Initial thoughts is that I'll likely just continue use my own code in our themes. The information we analyze the most in Google Analytics is these two things: Comparing guests vs those logged in Which sections are most popular and traffic change etc. for each section In your current implementation you only send information about the closest container. What I would suggest is that you also include the entire breadcrumb data in the default language. Here’s an example of information I provide, when inside a topic in A Test Category/A Test Forum/Subforum. I provide the same breadcrumb data if viewing the forum, but the controller within the location variable would be forums instead of topic. dataLayer = [{ 'adblocker': adblock, 'isLoggedIn': isLoggedIn, 'location': {app:"forums", module:"forums", controller:"topic"}, 'isContentPage': isContentPage, 'breadcrumb': ["A Test Category","A Test Forum","Subforum"], 'breadcrumbObj': {"section1":"A Test Category","section2":"A Test Forum","section3":"Subforum"}, 'breadcrumbPath': 'A Test Category/A Test Forum/Subforum', I have it duplicated a bit unnecessarily for … what was probably good reasons once upon a time. When you have a large community with a lot of sections that each contain numerous forums, and subforums to subforums etc., it makes more sense for us to look at all traffic across all the subforums in a section and then go further down into specific forums from there. As for my other suggestions it would be to include whether the visitor is logged in or not. Currently you only sort of provide this information if PII is enabled, but I would suggest you just provide an additional true/false field by default, and not having to enable all PII to get data on guests vs logged in.

Hi, The default for language string ensure_signature_restrictions is "Please ensure your signature complies with the following restrictions" I would suggest you throw in a reference to the guidelines when this message is shown too, which I've chosen to do in my translation. Reason was members sort of chose to misunderstand the page. My chosen translation would be this in english: Please ensure your signature complies with the <a href='{internal.app=core&module=system&controller=guidelines}'>guidelines</a> and the following restrictions

Problem turned out to be the task.php no longer being chmodded correctly and the form giving an error about that, which isn't the most visible error, especially when my attention is focused further down. This in turn causes the form to just return instead of saving any other values that still would be valid. But the values still appear as changed, since the form checks \IPS\Request

Turns out something very weird is going on with my installations. When I save a new value for a setting it "doesn't stick". It gives the impression the value has been saved after submit. No error message, the value is updated when the page reloads. But if I then proceed to reload the page, without resubmitting the form, it shows the old value still. I've cleared cache multiple times. No IN_DEV or other developer mode.

Hi, So I randomly discovered that after moving to a new server we had forgot to setup the folders we had configured for our disk template caching. I created the folders, set the owner:group to www-data:www-data and even set the chmod for it to 777. I resaved the settings, and it accepted the folder being readable and writable, but after browsing the community I noted that no cache files have been created in the folder. I also tried to deactivate the enable-setting, activate it again, and empty cache, but there is still nothing written to the folder. It doesn't seem to do anything. This has been tested on a test install running the latest version. Have you changed how this works? Is the cache files created dependent upon some other action than before? Do you have any ideas on what might be the problem?

Hi, Currently when a member group is unable to see who reacted to them, it also causes the reputation activity page on the profile to be disabled. I wish that you'll make this page available even for groups who can't see who reacted to them. Obviously without telling who gave the reaction Only show reactions given by a user when the user is viewing it's own profile

Okay, so which environments would you use Redis for? Besides, if Redis is already used for the caching, then I guess it would be best to use it for Data Storage too?

I'm wondering whether you still consider the following description to be true: The data storage method is used by various systems to save arbitrary data. If caching is enabled, using the MySQL Database provides the best performance for most environments, otherwise using the File System is usually best. I think a little while ago you introduced Redis as an option for the Data Storage part, so what are your experiences here and should the description maybe be updated?

Jeg er ikke interessert i å oversette noe annet enn offisielle applikasjoner eller sy sammen flere pakker. Jeg foreslår at du nesten bare tester. Jeg vil anta at den bare overskriver fraser/ord som er i språkpakken man importerer fra.

Til orientering ble språkpakken oppdatert til 3.6.7 i forrige uke og til 3.6.8 nå i dag. Du finner språkpakken som vanlig her, men den installeres jo nå fra markedsplassen i adminpanelet. Om du likevel ønsker å laste ned XML-filen så prøver jeg å huske holde den oppdatert på github.

When a topic is moved the read marker for that topic is reset, meaning it no longer remembers the last post you were reading. My suggestion would be to fix this, so the read position is kept for members, when the topic/item is moved. Are there any plans to address this, and could you explain the current challenges in solving this, if any?

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=

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

I submitted this as feedback last week, but it looks to be a bug. In any case you currently have javascript related to this behaviour that doesn't do anything in your default theme. In version 4.4, this was the HTML for the share link on posts in html/forums/front/topics/post.phtml: {{if $comment->mapped('first') }} <li><a class='ipsType_blendLinks' href='{$comment->item()->url()}' data-ipsTooltip title='{lang="share_this_post"}' data-ipsMenu data-ipsMenu-closeOnClick='false' id='elSharePost_{$comment->$idField}' data-role='shareComment'><i class='fa fa-share-alt'></i></a></li> {{else}} <li><a class='ipsType_blendLinks' href='{$comment->item()->url()->setQueryString( array( 'do' => 'findComment', 'comment' => $comment->$idField ) )}' data-ipsTooltip title='{lang="share_this_post"}' data-ipsMenu data-ipsMenu-closeOnClick='false' id='elSharePost_{$comment->$idField}' data-role='shareComment'><i class='fa fa-share-alt'></i></a></li> {{endif}} In version 4.5, you changed it to: {{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}} The notable change here is that you changed it from using data-ipsMenu to data-ipsDialog. In both version 4.4 and 4.5 you have the following javascript related to this share link on /dev/js/front/controllers/core/ips.core.comment.js inside the javascript code for the core.front.core.comment controller. this.on( 'menuOpened', '[data-role="shareComment"]', this.shareCommentMenu ); And further down: /** * User has clicked the share button within the comment; we'll select the text to make it easy to copy * * @param {event} e Event object * @param {object} data Event data object * @returns {void} */ shareCommentMenu: function (e, data) { if( data.menu ){ data.menu.find('input[type="text"]').get(0).select(); } }, I'm not sure what the fix would be here, as you don't seem to have a dialogOpened event and the click event would happen too early / not contain the information it needs to select the text. This is the fix, in the javascript, change the event initialization to: this.on( 'openDialog', '[data-role="shareComment"]', this.shareCommentMenu ); And then change the method shareCommentMenu to: shareCommentMenu: function (e, data) { if( data.dialog ){ data.dialog.find('input[type="text"]').get(0).select(); } }, (You may also want to rename the method from shareCommentMenu to shareCommentDialog)

@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)

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.

Currently the author badge on posts uses the language string "author". However, on the communities I manage in Norway, we would like this to get a different translation. But we obviously can't really change the author-string since the context of the author-string is so different in all the other areas the same string is used.

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

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:

Hello, Is there a shortcut for opening the link dialog in the editor? In the accessibility documentation for CKEditor it says Ctrl+L, but that doesn't do anything here.

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 also find the current behaviour here frustrating, as it's so much slower, and it happens quite often for the big boards I work on. I've often found ongoing COUNT(*)-queries to be the culprit, which is kind of ironic since the purpose of them is to figure out whether the table is so big that queries against them will take a long time or not. Could you at least lower the refresh time? It's currently 2 seconds and should ideally be instant. If instant isn't feasible, then at least let it be 1 second.