All Astronauts

FYI this plugin (@version 6.0.1) is fine on 4.7.5 (Beta 1 at least) and PHP 8.0.x and PHP 8.1.6, even though it has not been flagged up for 4.7 compatibility. If you are running an earlier version that may have been the reason why.

If that is just group formatting that is already built in. Go to the Online Today settings, first option is display, and set it to the second option which adds group formatting.
'ot_widget_title' => '{# [1:Member][?:Members] Online Today}', The language string is ot_widget_title. Find that and edit as needed. IMPORTANT! Only edit the text, meaning the words member, members, and online today. Leave the rest alone as that language string is parsed based on the number of members - 1 member being singular, all other numbers given being plural. If you get rid of anything else there you will break things.
Not really - there are settings you can change though:

Next release, probably before Xmas - I mean, probably much sooner, but it's good to hedge. It's already running locally but fit and finish matters. I am also getting around to some of the drudge work, handling some of the errors that pop up when people hold this app wrong.

At the moment, we create blocks for some ad units, so we can use php to check cookies etc, but you can't use things like {block="my_block_key"} in the advertisements at the moment. So, we end up placing them manually into the templates. 
So, if it were possible to use those inside ads, and place them using your app it would be very useful for us. 

Never heard back from you so submitted a new version that I doubly verified is fine on PHP 8 - no changes that I know of but still...
If you still have problems after the file is approved (SSSR 7.2.1) then give a yell back at me.

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.

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.

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.

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?

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.

First come, first served. PMs only. And I will need ACP access and your ears and eyes. Maybe a bit o' brain too. The thing covers the plugins and this app but I would like a volunteer for testing before submitting. If what I just wrote is confusing, you are probably not who I am looking for...

First come, first served. PMs only. And I will need ACP access and your ears and eyes. Maybe a bit o' brain too. The thing covers the plugins and this app but I would like a volunteer for testing before submitting. If what I just wrote is confusing, you are probably not who I am looking for...

Thanks, I have fixed this for an upcoming release.

Just want to put this bug in your ears, especially with the code checker now in place and the possibility it will get strict along these lines in the future. Apologies if this has already been noted recently (or way in the past) - have not looked too deeply here.
I've noticed more than a few instances of functions defined as static public instead of public static in code; mine and yours. Your source files have a couple (4?), your apps more, but I was more puzzled why my app and plugin hooks had a bunch as this isn't a thing I normally do.
As an example, a hook on baseCss() is routinely static public in the hook. So I looked and your method is clearly public static. So to test I just opened up the dev center and added a baseCss() hook, and it appends into the hook as static public.
I've probably never given this a moment's notice but with the checker forcing us to really work over the syntax it's kinda all jumps out now. Yes, I know, you are allowed to do this, it's 
"fine", but it's also not PSR kosher and if you start forcing this level of strictness through with the checker - well, at least give everyone fair warning before turning that on.
I'm changing them as I find them but having the dev center push these functions into the hooks correctly would be nice to have eventually.

I've removed the offending file completely and submitted a new version to the marketplace.
That said, the original point still stands. If a hook is extending a non-existent file, it still should not be flagged.

I agree and we'll improve this in a future release.

FWIW I re-engineered this this evening. Just about, if not, every username link, and userphoto can be targeted with CSS via data attributes [data-online="online"] and [data-online="offline"]
This will allow you guys who can do CSS to do things - even more so once the :has pseudo class gets supported (this will allow you to format a parent item that has a child with x,y or z - but this will still be awhile before we see this in wide support)
Anyways, I'm going to try and add some of the requests in and then we can talk about what's possible.
Note that if the userphoto or userlinks in this new system are generated with data (userLinkFromData, userPhotoFromData templates specifically) the online status is determined by a task running every five minutes to get that status. Given how online status is determined, and how it lingers, I doubt this is a big deal - just FYI.

Looking at the orig. plugin it didn't do most of that.
It did PMs (that's an easy add), but none of the other stuff you listed that I can tell. In fact, my supporting all application comment and review areas already far exceeds what the original did, unless I'm missing something.
So, what you are looking for is support on the content items themselves? Some of that is doable but it is all one at a time stuff by and large. Not only that but due to how activity stream and search results are pushed out, there would be (under the current model) loading the member objects for the members for each item to check if they are online or not (those links are not member objects but just created on the fly with basic data such as member id, member name, etc.)
I can see a somewhat universal (like, possibly everywhere) way around this though but still would need some thought. Especially if the solution to hooking everything everywhere is to just target the basic user photo and user link templates but that risks spillover in places unwanted. Not a lot of engineering at all, but it would be a sideways approach different than all the usual stuff we've done with this. Hmmm...
Shoot me a PM with some specific screenshots - I'm going to try and tackle some of the earlier requests here first, plus people are coming out of the wood work with "recreate this please!" requests due to all this old stuff going dark in a month or two (including two or three plugins that are required on a site I'm currently doing work for that I had no idea were in that pile so...)
 
 

1. ✔️
2. ✔️
3.  but also ✔️

Only getting my morning coffee now,  support topic will be up shortly.
And @Genestoy that other thing will be submitted in a few hours.  Might be the tightest, most efficient, plugin I've done.