Martin A.

Glad you got it solved 🙂
 
Regarding the API issues; I received news last night that MapQuest have (rather silently) decided to close all their "open" APIs, which sadly included the API used by Community Map. While there might have been possible to use other API endpoints provided by MapQuest, I will not do so because of how they've handled this and their lack of communication. I assume none of you got any news about this, even though they should be able to see that you are actively using an API that's about to be shut down.
As of the next update Community Map will not use MapQuest. I am currently exploring the possibilities to host this on my own, as there is a pre-compiled database available that doesn't have the same requirements as previously mentioned. I'm gonna check this out some more over the weekend, and I will hopefully have a solution within reasonable time.

@Daniel F Great! While you're at it can you guys give a good look at this forum and check the other bugs? I've posted several ones (even easy ones like this one) and they were never acknowledged nor fixed.
 
Here's some random ones:
https://invisioncommunity.com/forums/topic/468507-bug-470-cannot-setup-extra-fields-in-downloads-to-be-included-in-topics/ https://invisioncommunity.com/forums/topic/468498-bug-470-the-setting-send-diagnostic-data-is-broken/ https://invisioncommunity.com/forums/topic/468464-bug-470-cms-database-setting-field-options-records-per-page-controls-also-comments-per-page/ https://invisioncommunity.com/forums/topic/468123-bug-470-blog-app-has-calendar-code-in-it/  
These are just some recent ones.

Martin has kindly provided an updated version of mmer map that can be unistalled.   If you install it then it overwrites the problem version, which can then be uninstalled.   Job done 😀

Glad you got it solved 🙂
 
Regarding the API issues; I received news last night that MapQuest have (rather silently) decided to close all their "open" APIs, which sadly included the API used by Community Map. While there might have been possible to use other API endpoints provided by MapQuest, I will not do so because of how they've handled this and their lack of communication. I assume none of you got any news about this, even though they should be able to see that you are actively using an API that's about to be shut down.
As of the next update Community Map will not use MapQuest. I am currently exploring the possibilities to host this on my own, as there is a pre-compiled database available that doesn't have the same requirements as previously mentioned. I'm gonna check this out some more over the weekend, and I will hopefully have a solution within reasonable time.

Update button now showing in AdminCP ... ran it,  and version is now correct

I have no idea what's going on with their services, but I'm looking for a replacement. 
Currently ruled out both Mapbox and Google for their limitations and pricing. I just stumbled across https://geocode.xyz/ now, and they do offer a free tier, although limited to one request per second. The location autocomplete becomes useless with such a limit, which is a bummer.
Other suggestions are much welcomed! If it weren't for the insane server requirements I could have set up something in AWS or a VPS. The API used now require 1TB for a full install and 64GB minimum RAM.
Just click "Fix automatically". The upgraded should have added that column. Happens sometimes.
No indication on the app overview that there's an upgrade available?

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;  

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;  

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;  

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;  

Try replacing the parent call (line 134) with this code instead:
# Get parent output (PHP 8 fix) $whosOnline = ''; if( \is_callable( 'parent::' . __FUNCTION__ ) ) { $whosOnline = \call_user_func_array( 'parent::' . __FUNCTION__, \func_get_args() ); }  

Thanks anyway.   Martin is still helping me so hopefully we will sort it.

Still makes the scanner worthless if we have to browse through 10+ pages of non-issues to find an actual issue.
Should also note that it scans disabled apps too, so I can't just disable Dev Toolbox to get rid of most of these log entries.

Technically speaking, as MP devs, we cannot until 4.8
Unless that is you add the third point to the marketplace version flags.
As it stands, a Marketplace 4.7 flag means PHP 7.4 and PHP 8. If we start throwing in PHP 8 specific stuff in our apps and people are hanging back on 4.7.2 or less it's going to be a bad time for a lot of people. I imagine the support discussions will go something like this:

Give us a 4.7.3+ flag and the Spidermen go away. Or don't and we laze about in the land of PHP 7.4 until Invision Community 4.8 comes along.

Getting lots of logs for classes I have that extends global classes, such as \Exception, \DateTime, etc.
You would have seen this yourself if you hadn't excluded your own code from being scanned 🙂
The class \Braintree\Transaction\AddressDetails extends \Braintree\Transaction\Instance, but the parent class couldn't be loaded. The class \IPS\core\api\GraphQL\Types\ProfileFieldGroupType extends \IPS\core\api\GraphQL\Types\ObjectType, but the parent class couldn't be loaded. A class in an app extends the class \IPS\Node\Api\GraphQL\ObjectType for which no file /home/sites/dev/www/473b3/system/Node/Api/GraphQL/ObjectType/ObjectType.php exists! The method scanner skipped comparing that file to any of its subclasses The class \IPS\nexus\Hosting\Exception extends \RuntimeException, but the parent class couldn't be loaded. The class \IPS\nexus\CommissionRule\Iterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Symfony\Component\Finder\Iterator\SizeRangeFilterIterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Laminas\EventManager\Exception\DomainException extends \DomainException, but the parent class couldn't be loaded. The class \PHPMailer\PHPMailer\Exception extends \Exception, but the parent class couldn't be loaded.  
And it doesn't understand imports.
The class \IPS\toolbox\Slasher extends \IPS\toolbox\Singleton, but the parent class couldn't be loaded. The class \IPS\toolbox\modules\admin\build\build extends \IPS\toolbox\modules\admin\build\Controller, but the parent class couldn't be loaded. use IPS\Dispatcher\Controller; <...> class _build extends Controller {  
Would also be nice if there was a way to trigger the full compatibility scan without having to create an issue in a hook in order to see what's wrong. Two of my apps were disabled in this update, but the block on the support page said everything was fine. After creating an issue with a hook it would tell me the arguments for getItemsWithPermissions was incorrect in the full scan popup.
The system log fills up with ~15 pages of the above log entries whenever I hit the support page. Going through all that in order to see what could have triggered the scanner is not gonna happen.

Bump. These are serious issues that are triggering lots of useless logs for many websites. While in theory I could stop using aliases (but this is not a viable solution to this problem), there is no way I can stop using classes like \RuntimeException.

Happy Hump Day! Sort of… 
I have a bit of news to share with you: this will be my last Hump Day as I am stepping down from Invision Community. 😢 
I am transitioning to a new role at Amazon. I’ll be creating content and engagement solutions for AWS. 
I’d like to take a moment to thank this community for welcoming me with open arms. When I first started my journey as an Invision Community team member, I focused on community advocacy and connecting clients with the team. We quickly realized my, um... exuberance was better suited in marketing and sales. 
Creating content around Invision Community opened my eyes even further to how brilliantly crafted this platform is and the team behind it.
I've also genuinely enjoyed communicating with industry professionals every day who showed interest in adding a community component to their business.
So many incredible Achievements (😏) happened along the way; I’m grateful I was a part of Invision Community’s success as we blazed through the 20-year anniversary. 🎉 
Now, you won’t be rid of me entirely. My own community, BreatheHeavy, will still remain on the Invision Community platform. I look forward to staying connected with all of you here!
Thank you for engaging and interacting with me these last few years. 
Please feel free to PM me here if you have any feedback, questions or well wishes. 😃 
I want to give a special thanks to @Charles for being my mentor and seeing potential in me (even when I didn't). 
And before I go, here’s a list of updates and changes made to the platform in the last seven days:
 

Thank you, 🙏 
-Jordan
 

\IPS\Content\Search\Index::i()->index( $record ); This will add or update the item.

That's very possible.  Those files are used as part of a local cache.  Personally if possible, I would just set your backup job to exclude the entire directory.  IPB will generate those files as needed if they don't exist.  

Getting lots of logs for classes I have that extends global classes, such as \Exception, \DateTime, etc.
You would have seen this yourself if you hadn't excluded your own code from being scanned 🙂
The class \Braintree\Transaction\AddressDetails extends \Braintree\Transaction\Instance, but the parent class couldn't be loaded. The class \IPS\core\api\GraphQL\Types\ProfileFieldGroupType extends \IPS\core\api\GraphQL\Types\ObjectType, but the parent class couldn't be loaded. A class in an app extends the class \IPS\Node\Api\GraphQL\ObjectType for which no file /home/sites/dev/www/473b3/system/Node/Api/GraphQL/ObjectType/ObjectType.php exists! The method scanner skipped comparing that file to any of its subclasses The class \IPS\nexus\Hosting\Exception extends \RuntimeException, but the parent class couldn't be loaded. The class \IPS\nexus\CommissionRule\Iterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Symfony\Component\Finder\Iterator\SizeRangeFilterIterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Laminas\EventManager\Exception\DomainException extends \DomainException, but the parent class couldn't be loaded. The class \PHPMailer\PHPMailer\Exception extends \Exception, but the parent class couldn't be loaded.  
And it doesn't understand imports.
The class \IPS\toolbox\Slasher extends \IPS\toolbox\Singleton, but the parent class couldn't be loaded. The class \IPS\toolbox\modules\admin\build\build extends \IPS\toolbox\modules\admin\build\Controller, but the parent class couldn't be loaded. use IPS\Dispatcher\Controller; <...> class _build extends Controller {  
Would also be nice if there was a way to trigger the full compatibility scan without having to create an issue in a hook in order to see what's wrong. Two of my apps were disabled in this update, but the block on the support page said everything was fine. After creating an issue with a hook it would tell me the arguments for getItemsWithPermissions was incorrect in the full scan popup.
The system log fills up with ~15 pages of the above log entries whenever I hit the support page. Going through all that in order to see what could have triggered the scanner is not gonna happen.

This is not about the app scanner specifically, sort of... It's more the case of the App Scanner exposing a long-term issue (it's not been a real problem until now).
Given how long the 4 series has been out in the wild, there is a LOT of relic code laying about. I'm talking about applications with sources directories/files that are no longer used and leftover stuff in the interface directories.
Naturally, the App Scanner is now flagging a lot of this stuff - at least at the log level. That's not a big deal but the hitch is this: If I remove interface files and directories, or source files and directories, from my application and upload the new version, the upgrade process does not iterate through what's in the updated app versus what's on the server. So the relic directories and files remain, and the scanner is finding them and flagging them (again, just logs for now as far as I can tell).
Self-hosted people can deal with this easily enough - just get on the server and delete the files and directories. That's not a viable solution for CIC users.
If you want us to write out the code on upgrades to nuke these things I'm sure we can do that. I'm equally sure that's the last thing you want us to code up and throw at your CIC infrastructure.
Thoughts?

Getting lots of logs for classes I have that extends global classes, such as \Exception, \DateTime, etc.
You would have seen this yourself if you hadn't excluded your own code from being scanned 🙂
The class \Braintree\Transaction\AddressDetails extends \Braintree\Transaction\Instance, but the parent class couldn't be loaded. The class \IPS\core\api\GraphQL\Types\ProfileFieldGroupType extends \IPS\core\api\GraphQL\Types\ObjectType, but the parent class couldn't be loaded. A class in an app extends the class \IPS\Node\Api\GraphQL\ObjectType for which no file /home/sites/dev/www/473b3/system/Node/Api/GraphQL/ObjectType/ObjectType.php exists! The method scanner skipped comparing that file to any of its subclasses The class \IPS\nexus\Hosting\Exception extends \RuntimeException, but the parent class couldn't be loaded. The class \IPS\nexus\CommissionRule\Iterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Symfony\Component\Finder\Iterator\SizeRangeFilterIterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Laminas\EventManager\Exception\DomainException extends \DomainException, but the parent class couldn't be loaded. The class \PHPMailer\PHPMailer\Exception extends \Exception, but the parent class couldn't be loaded.  
And it doesn't understand imports.
The class \IPS\toolbox\Slasher extends \IPS\toolbox\Singleton, but the parent class couldn't be loaded. The class \IPS\toolbox\modules\admin\build\build extends \IPS\toolbox\modules\admin\build\Controller, but the parent class couldn't be loaded. use IPS\Dispatcher\Controller; <...> class _build extends Controller {  
Would also be nice if there was a way to trigger the full compatibility scan without having to create an issue in a hook in order to see what's wrong. Two of my apps were disabled in this update, but the block on the support page said everything was fine. After creating an issue with a hook it would tell me the arguments for getItemsWithPermissions was incorrect in the full scan popup.
The system log fills up with ~15 pages of the above log entries whenever I hit the support page. Going through all that in order to see what could have triggered the scanner is not gonna happen.

The spam service is returning code 4, which means the account is a known spammer. This is based on the email and/or his IP. 
Is he using a VPN by any chance?

Getting lots of logs for classes I have that extends global classes, such as \Exception, \DateTime, etc.
You would have seen this yourself if you hadn't excluded your own code from being scanned 🙂
The class \Braintree\Transaction\AddressDetails extends \Braintree\Transaction\Instance, but the parent class couldn't be loaded. The class \IPS\core\api\GraphQL\Types\ProfileFieldGroupType extends \IPS\core\api\GraphQL\Types\ObjectType, but the parent class couldn't be loaded. A class in an app extends the class \IPS\Node\Api\GraphQL\ObjectType for which no file /home/sites/dev/www/473b3/system/Node/Api/GraphQL/ObjectType/ObjectType.php exists! The method scanner skipped comparing that file to any of its subclasses The class \IPS\nexus\Hosting\Exception extends \RuntimeException, but the parent class couldn't be loaded. The class \IPS\nexus\CommissionRule\Iterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Symfony\Component\Finder\Iterator\SizeRangeFilterIterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Laminas\EventManager\Exception\DomainException extends \DomainException, but the parent class couldn't be loaded. The class \PHPMailer\PHPMailer\Exception extends \Exception, but the parent class couldn't be loaded.  
And it doesn't understand imports.
The class \IPS\toolbox\Slasher extends \IPS\toolbox\Singleton, but the parent class couldn't be loaded. The class \IPS\toolbox\modules\admin\build\build extends \IPS\toolbox\modules\admin\build\Controller, but the parent class couldn't be loaded. use IPS\Dispatcher\Controller; <...> class _build extends Controller {  
Would also be nice if there was a way to trigger the full compatibility scan without having to create an issue in a hook in order to see what's wrong. Two of my apps were disabled in this update, but the block on the support page said everything was fine. After creating an issue with a hook it would tell me the arguments for getItemsWithPermissions was incorrect in the full scan popup.
The system log fills up with ~15 pages of the above log entries whenever I hit the support page. Going through all that in order to see what could have triggered the scanner is not gonna happen.

Getting lots of logs for classes I have that extends global classes, such as \Exception, \DateTime, etc.
You would have seen this yourself if you hadn't excluded your own code from being scanned 🙂
The class \Braintree\Transaction\AddressDetails extends \Braintree\Transaction\Instance, but the parent class couldn't be loaded. The class \IPS\core\api\GraphQL\Types\ProfileFieldGroupType extends \IPS\core\api\GraphQL\Types\ObjectType, but the parent class couldn't be loaded. A class in an app extends the class \IPS\Node\Api\GraphQL\ObjectType for which no file /home/sites/dev/www/473b3/system/Node/Api/GraphQL/ObjectType/ObjectType.php exists! The method scanner skipped comparing that file to any of its subclasses The class \IPS\nexus\Hosting\Exception extends \RuntimeException, but the parent class couldn't be loaded. The class \IPS\nexus\CommissionRule\Iterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Symfony\Component\Finder\Iterator\SizeRangeFilterIterator extends \FilterIterator, but the parent class couldn't be loaded. The class \Laminas\EventManager\Exception\DomainException extends \DomainException, but the parent class couldn't be loaded. The class \PHPMailer\PHPMailer\Exception extends \Exception, but the parent class couldn't be loaded.  
And it doesn't understand imports.
The class \IPS\toolbox\Slasher extends \IPS\toolbox\Singleton, but the parent class couldn't be loaded. The class \IPS\toolbox\modules\admin\build\build extends \IPS\toolbox\modules\admin\build\Controller, but the parent class couldn't be loaded. use IPS\Dispatcher\Controller; <...> class _build extends Controller {  
Would also be nice if there was a way to trigger the full compatibility scan without having to create an issue in a hook in order to see what's wrong. Two of my apps were disabled in this update, but the block on the support page said everything was fine. After creating an issue with a hook it would tell me the arguments for getItemsWithPermissions was incorrect in the full scan popup.
The system log fills up with ~15 pages of the above log entries whenever I hit the support page. Going through all that in order to see what could have triggered the scanner is not gonna happen.