All Astronauts

data-ipsLightbox-group='g{$indexData['index_id']}' Elasticsearch never returns that in the $indexItem array.
IN_DEV this will Whoops with missing array element when using Streams or Search.
Live it functions but image groupings are broken. Quoting @Martin A. "meat mixed with stats" (lamb chops with hard drive metrics to be precise)
The images will display correctly in the snippet, but when you lightbox them out and navigate through them, with a data-lightboxgroup="g" value instead of "g12345" its grabbing all the images on the page and you can navigate through them all.
Apparently, (@Martin A. looked here as we troubleshot this just now), MySQL is clear here and returns the index_id in the array.
If anyone here is having problems and selfhosts (and is using Elastic) you can patch this by changing the template bit there from index_id to index_object_id (or index_item_index_id perhaps) which is present in the $indexItem array returned via Elastic.
This can either be patched in the code to return the correct bit in the array if Elastic is present, or one can hack at the template like we did. There's also the smallest of possibilities of a collision between different apps returning the same item_ids but that's something for IPS to hash out if/when this gets patched.
Locally this is Elastic 7.2.0 if this matters.

data-ipsLightbox-group='g{$indexData['index_id']}' Elasticsearch never returns that in the $indexItem array.
IN_DEV this will Whoops with missing array element when using Streams or Search.
Live it functions but image groupings are broken. Quoting @Martin A. "meat mixed with stats" (lamb chops with hard drive metrics to be precise)
The images will display correctly in the snippet, but when you lightbox them out and navigate through them, with a data-lightboxgroup="g" value instead of "g12345" its grabbing all the images on the page and you can navigate through them all.
Apparently, (@Martin A. looked here as we troubleshot this just now), MySQL is clear here and returns the index_id in the array.
If anyone here is having problems and selfhosts (and is using Elastic) you can patch this by changing the template bit there from index_id to index_object_id (or index_item_index_id perhaps) which is present in the $indexItem array returned via Elastic.
This can either be patched in the code to return the correct bit in the array if Elastic is present, or one can hack at the template like we did. There's also the smallest of possibilities of a collision between different apps returning the same item_ids but that's something for IPS to hash out if/when this gets patched.
Locally this is Elastic 7.2.0 if this matters.

data-ipsLightbox-group='g{$indexData['index_id']}' Elasticsearch never returns that in the $indexItem array.
IN_DEV this will Whoops with missing array element when using Streams or Search.
Live it functions but image groupings are broken. Quoting @Martin A. "meat mixed with stats" (lamb chops with hard drive metrics to be precise)
The images will display correctly in the snippet, but when you lightbox them out and navigate through them, with a data-lightboxgroup="g" value instead of "g12345" its grabbing all the images on the page and you can navigate through them all.
Apparently, (@Martin A. looked here as we troubleshot this just now), MySQL is clear here and returns the index_id in the array.
If anyone here is having problems and selfhosts (and is using Elastic) you can patch this by changing the template bit there from index_id to index_object_id (or index_item_index_id perhaps) which is present in the $indexItem array returned via Elastic.
This can either be patched in the code to return the correct bit in the array if Elastic is present, or one can hack at the template like we did. There's also the smallest of possibilities of a collision between different apps returning the same item_ids but that's something for IPS to hash out if/when this gets patched.
Locally this is Elastic 7.2.0 if this matters.

Looked more like that was an issue where they used IPS 4.4 themes while using PHP 8.
That is what this is tho. PHP 8 doesn't allow unparanthesized nested ternaries, while PHP 7 did.

Sorry, you're right, this requires the parse_mobile_..... method to work!
I'll see if we can simplify this, I don't think that we really need it for simple PWA notifications.

EDIT: In looking further…. I found this third party resource in the marketplace.  This looks to be what might be installed based on your screenshot.
If so, you would need to ask the author why they’re not honoring hidden groups. 

Edit again… looks like our posts crossed!  Glad you figured it out. 

Oh, sorry, I completely forgot that! I solved: the third party resource is the plugin "Group Name Indicator" by All Astronauts, now I set the plugin correctly. Thank you! 

It looks like this is something your server administrator has set up to block ZIP/archives that have Java script files in them. See https://sanesecurity.com/foxhole-databases/ - The virus error message is a bit mis-leading, but it's how the database flags the file for ClamAV to reject.
I also want to post a reminder than developer tools should never be used on a live or publicly accessible website.

Thanks! Will set to 300 🙂 I wish, I had 2000 visitors / day 😄 

Likely further out, we've still a fair amount of work to do with PHP 8.1 [and PHP 8.2]. The timeline on the PHP Supported Versions page would be a good one to follow.

Community in the Cloud, the IPS hosted version of the software which you are on.
@IPS - CIC would make for a really good use of your built-in Word Expansion feature on this site.
And as @opentype said, it's not the best clarity anymore - instead of explicitly stating the app and major feature available per-package, it's abstracted out with marketing-speak. When viewing the options on the pricing page you'll notice a number of options are actually clickable and expandable. You'll get more details there.
 

Community in the Cloud, the IPS hosted version of the software which you are on.
@IPS - CIC would make for a really good use of your built-in Word Expansion feature on this site.
And as @opentype said, it's not the best clarity anymore - instead of explicitly stating the app and major feature available per-package, it's abstracted out with marketing-speak. When viewing the options on the pricing page you'll notice a number of options are actually clickable and expandable. You'll get more details there.
 

@EvanDC Strange. PM me ACP access and I can take a peek. The current version of PCI does not get flagged by the PHP 8 checker in 4.7.5, and there are no change notes in 4.7.6 that would indicate something breaking. And that's the only direct reason I can think of to have the app disabled.
No matter, PM me creds and I'll poke it with a stick.

Let me brain this a bit...

Yes. Added to list.
Pretty sure this was it. I'm also NOT sure why this didn't go into the 4.7 KS. I'll have to look back...
For what you are asking, I'm not sure what actually... Did you just want to change the topic's author?

Shouldn't.  The ads are still loaded entirely via the IPS methods. All the permission checks and such,  all IPS.

I see it now. $postBeforeRegister used to be = NULL in the method variables and it no longer is; just passed through.
Strange the scanner doesn't catch this like you said; stranger still it working just fine here.
🤷‍♂️
I'll pop another version off.
 

I see it now. $postBeforeRegister used to be = NULL in the method variables and it no longer is; just passed through.
Strange the scanner doesn't catch this like you said; stranger still it working just fine here.
🤷‍♂️
I'll pop another version off.
 

It was 6.0.1 and the signature for the registration methods has wrong parameters default values and is using public instead of private.
No error in the PHP Scanner, not sure why. There is a ton of log entries pointing to the hook of this plugin, that’s why I got there.