TSP

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?

Could you please make the Developer Connection into a regular forum with the best answer feature instead, if anything? I've been annoyed about this for years, and find that it seems to limit the activity/engagement and is frustrating to read topics.

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

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.

Hello, In 4.5 if you create a announcement with the option "Floating bar at the top of the page" it no longer sticks to the top down the entire page. It only sticks inside the section with the header and navigation. In 4.4 it followed you down along the entire page, which is what I would expect to still be the case.

I'm moving the search box to be on the same line as the top breadcrumb. When doing so I noticed a difference in the HTML markup between the list items that were already there and added by javascript when you click "More options…" When you open the search on this community, the first item is: <li> <span class="ipsSideMenu_item ipsSideMenu_itemActive" data-ipsmenuvalue="all"> <input type="radio" name="type" value="all" checked="" id="elQuickSearchRadio_type_all"> <label for="elQuickSearchRadio_type_all" id="elQuickSearchRadio_type_all_label">Everywhere</label> </span> </li> And the Topics-item has the same HTML. However, when you click "More options" other options become available. Here is the HTML for one of them: <li> <a href="#" class="ipsSideMenu_item" data-ipsmenuvalue="cms_pages_pageitem"> <input type="radio" name="type" value="cms_pages_pageitem" id="elQuickSearchRadio_type_cms_pages_pageitem"> <label for="elQuickSearchRadio_type_cms_pages_pageitem" id="elQuickSearchRadio_type_cms_pages_pageitem_label">Pages</label> </a> </li> The difference to note here is that for the first items there is a <span>-tag wrapping the items, while in the ones added by JS it's a <a>-element. I presume this is a bug as I can't think of a reason it would be intentional.