Afrodude

To be honest, I can't see this IPS platform as remaining a sustainable one for the small communities out there. The asking price for everything is way too high and now that the marketplace devs have adopted this teat-latching subscription model, all I see happening is that when "new" IPS things come out they break the old things that were working just fine and then we are expected to pay again for something that hasn't really changed other than to comply with those other things that didn't need to change in the first place. 
It's a form of software socialism and I have come to the end of my tolerance thereof. 

Loading the alerts list is taking a lot of time as it's checking the mt_alert for every single alert that is owned by the current user. As all our alerts are pretty much sent from the same account that's ~25 queries, each taking 2.5-3 seconds. Looks like there should be an index for alert_enabled in core_alerts as well.
And why's an alert sent to a single user still active after the alert is viewed (and replied to when required)? AFAIK there's no way for the user to see this again. 
# Time: 221116 8:34:55 # Query_time: 3.358027 Lock_time: 0.000015 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587695; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=177; # Time: 221116 8:34:59 # Query_time: 3.350071 Lock_time: 0.000019 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587699; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=176; # Time: 221116 8:35:02 # Query_time: 3.022629 Lock_time: 0.000013 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587702; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=173; # Time: 221116 8:35:05 # Query_time: 2.857855 Lock_time: 0.000020 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587705; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=167; # Time: 221116 8:35:07 # Query_time: 2.593997 Lock_time: 0.000013 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587707; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=165; # Time: 221116 8:35:10 # Query_time: 2.959022 Lock_time: 0.000020 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587710; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=164; # Time: 221116 8:35:13 # Query_time: 2.626848 Lock_time: 0.000024 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587713; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=163; # Time: 221116 8:35:16 # Query_time: 2.797712 Lock_time: 0.000959 Rows_sent: 1 Rows_examined: 6017771 SET timestamp=1668587716; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=160; # Time: 221116 8:35:18 # Query_time: 2.512759 Lock_time: 0.000010 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587718; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=155; # Time: 221116 8:35:19 # Query_time: 2.802615 Lock_time: 0.000012 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587719; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=177; # Time: 221116 8:35:21 # Query_time: 2.917076 Lock_time: 0.000010 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587721; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=176; # Time: 221116 8:35:24 # Query_time: 2.744089 Lock_time: 0.000262 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587724; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=173; # Time: 221116 8:35:27 # Query_time: 2.998646 Lock_time: 0.000011 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587727; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=167; # Time: 221116 8:35:30 # Query_time: 2.818053 Lock_time: 0.000013 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587730; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=165; # Time: 221116 8:35:33 # Query_time: 2.563267 Lock_time: 0.003858 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587733; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=164; # Time: 221116 8:35:35 # Query_time: 2.827758 Lock_time: 0.000272 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587735; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=163; # Time: 221116 8:35:38 # Query_time: 2.910577 Lock_time: 0.000010 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587738; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=160; # Query_time: 3.039357 Lock_time: 0.000010 Rows_sent: 1 Rows_examined: 6017772 SET timestamp=1668587741; /*database::username::IPS\core\Alerts\_Alert::membersRepliedCount:227*/ SELECT COUNT(*) FROM `core_message_topics` WHERE mt_alert=155;  

Thanks, I will look into this and fix it in the next version!

@GaryI did it very fast, but perhaps something like this where everything can be readable. 

I believe it's time to improve the look of the profile area especially user and group names.

Everything looks nice in the profile area but these two. I know that you guys do can better and can make an amazing improvement in here. 🙂 @Ehren

It would be nice if you guys add Moderating with personal alerts to Hide and Lock on Status update.

Invision has SearchAction implemented, but the search box does not appear in Google results.

According to Google's documentation, it should be like this:
<script type='application/ld+json'> { "@context": "http://www.schema.org", "publisher": "https://invisioncommunity.com/#organization", "@type": "WebSite", "@id": "https://invisioncommunity.com/#website", "mainEntityOfPage": "https://invisioncommunity.com/", "name": "Invision Community", "url": "https://invisioncommunity.com/", "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://invisioncommunity.com/search/?q={query}" }, "query-input": "required name=query" } } </script> not like this:
<script type='application/ld+json'> { "@context": "http://www.schema.org", "publisher": "https://invisioncommunity.com/#organization", "@type": "WebSite", "@id": "https://invisioncommunity.com/#website", "mainEntityOfPage": "https://invisioncommunity.com/", "name": "Invision Community", "url": "https://invisioncommunity.com/", "potentialAction": { "type": "SearchAction", "query-input": "required name=query", "target": "https://invisioncommunity.com/search/?q={query}" } } </script>

I second this. It would be great to have this feature 

If you turn off this setting on any Moderators group, this group wouldn't be able to lock any topic. 
 
 

Thank you IPS for this new feature especially @Daniel F
I myself love it, and we hope to have some improvements. 
My suggestion is to add "Alerts Saved Actions" where you can add saved titles to use and pick from whenever you send an alert to members instead typing them each time you are sending an alert. 
 

You cannot use stock replies for alert title dear. 

I believe you misunderstand my suggestion, and you mixed between Alert title and Alert Content. 

I have my own hooks to add additional spam filter rules, and I imagine I'm not alone. I want them to be able to take advantage of showing the reason that the post got mod queued, but there's no easy way to do that, because the post ID is only available after it's saved, and there's no suitable hook point in \IPS\Content::checkProfanityFilters between saving and constructing the approval entry.
It would make me much happier if you replaced the switch statement on line 773 with either:
A method call that we can hook Or fall back to setting $log->held_data = ["match" => $filtersMatched["match"]] Or just always do that, and drop the logic to choose between the cases entirely You already made Approval itself hookable by pulling availableReasons out into a method (though why it's necessary to have it at all is a bit confusing to me), so this feels like an unfortunate oversight.
I believe the image hold log in \IPS\Content::shouldTriggerProfanityFilters on line 639-643 is also going to hit the issue with the post ID not being available yet, but I obviously don't pay enough to be able to test that. The changes suggested here should make that code easier to unify with the rest of the cases.

This was fixed for an upcoming release 

The upgrade step for 4.7.0 Beta 3 (107004) add a core_image_scanner_logs table in the database but a fresh 4.7.4 install doesn't have such table.
 
A quick mass search in the files returns 2 result: the one above adding the table in 4.7.0 Beta 3, and the other is actually to drop the table but in the 4.6.13 Beta 1 upgrade instead.
I guess the query to drop the table was added to the wrong step/file? 🤨

I would certainly assume so 😂

The best solution would be to get rid of the Font Awesome 4 completely and replace the icons with the SVG or a better newer framework.
FA4 icons are unequal, i.e. they have different heights.
FA:

SVG:

 

I wish this future is nearby not 10 years from now. 🙂

Just an FYI that I have split this from the previous topic you posted under as the issues were unrelated. 🙂

Has no one noticed that these icons are crooked? I mean, they're not centered 😛 @Ehren

A simple code does the trick:
.ipsBadge.ipsBadge_icon.ipsBadge_small i { vertical-align: middle; }

Thanks @SeNioR-
A large UI sweep will be done in the future and will address things like this. I've been keeping note of small bugs like this one and I've been adding them to my todo list, so feel free to continue reporting things if you notice them 🙂

The issue still occurs on version 4.7.4.

Thanks. That was fast!!1
@Daniel F = 

Thanks @opentype
Despite an easy solution (changing the overflow), it's a bit of a tough bug to fix because buttons are currently designed to have truncated text if they're too wide for their parent.
I'll potentially change this in a future version since it's not really ideal to truncate a button/CTA, but I'll fix this issue in the next update with the following code since it's less likely to break existing button layouts:
.ipsButton:has(.ipsNotificationCount){ overflow: visible; }  

Thanks, I have fixed this for an upcoming release.

After upgrading the server of one of our communities from PHP 7.4 to 8.1 I found the following error message popping up a lot: 
TypeError: count(): Argument #1 ($value) must be of type Countable|array, string given in /www/system/Data/Cache.php:151 This was caused by some custom code being referenced in a custom theme which requested a value with \IPS\Data\Cache::getWithExpire. This is how that function looks currently: 
<?php public function getWithExpire( $key, $fallback=FALSE ) { if ( !isset( $this->$key ) ) { throw new \OutOfRangeException; } $data = $this->$key; if( \count( $data ) and isset( $data['value'] ) and isset( $data['expires'] ) ) { // ... } else { unset( $this->$key ); throw new \OutOfRangeException; } } After some debugging I found that $data was indeed a string, and thus can't be counted. My first thought was that you should change from \count( $data ) to \is_array( $data ) in this function, which I still think you should, but the next mystery was to figure out why it would be a string, since you always expect it to be an array, and I used the regular storeWithExpire to save to Cache.

I found the culprit to be former abundance of caution, or what might have been a good reason at the time I implemented it (many many years ago): My code would first request the cache key from \IPS\Data\Cache::getWithExpire. If it didn't find it saved in Cache or it was expired, it would move on to check \IPS\Data\Store, with a 1/15 chance of unsetting it in \IPS\Data\Store to prevent the value from "never" being updated. If it didn't find it in any of them, then it would request the value from an external source and save it to both Data\Cache and Data\Store.
But if both methods utilizes Redis, then it means the second method will just overwrite the cache entry that the first one saved. Data\Cache stores an array to the cache key in Redis, but then Data\Store would immediately overwrite the same cache entry with a string. 
You can reproduce with this code: 
<?php require_once 'init.php'; $cacheKey = 'storeItPlease3'; $saveToCache = 'Hello world :-) | ' . date(DATE_RFC2822); $expire = \IPS\DateTime::ts( time() + 60 ); try { $cached = \IPS\Data\Cache::i()->getWithExpire( $cacheKey, TRUE ); echo $cached . "\n"; } catch ( \OutOfRangeException $e ) { try { $cached = \IPS\Data\Store::i()->{$cacheKey}; echo "Found in store: {$cached}\n"; if ( rand(1, 15) == 15 ) { unset(\IPS\Data\Store::i()->{$cacheKey}); } } catch(\OutOfRangeException $e2) { echo "Couldn't find in Data\Store!\n"; } echo "Didn't find {$cacheKey}. Write it!\n"; \IPS\Data\Cache::i()->storeWithExpire( $cacheKey, $saveToCache, $expire, TRUE ); \IPS\Data\Store::i()->{$cacheKey} = $saveToCache; } While I understand this kind of situation arising being rare and you probably don't expect people using both methods simultaneously like this, I thought I would still make you aware of it in case you encounter similar reported issues in the future and maybe make some changes to your code. Having a key name be the same in both Store and Cache could also happen by accident, although I guess the chance is rare.
 
Consider use is_array() rather than, or in addition to count() in \IPS\Data\Cache::getWithExpire (Do you even need that first check, maybe it's enough with the isset()-calls?)
  Consider prepending or appending to the cache key for one of the storage methods to differentiate entries in Redis saved by Store and Cache
(Alternatively document that one shouldn't use a key for Store that's already used by Cache or vice versa)