CoffeeCake

You might also consider having the member who is reporting this issue to you create a new account using a new pseudonym and retire the one that is the target of this individual. Also, consider enabling the 4.6 anonymity feature.

We have had this happen in the past--accidental flagging of a long term member with tens of thousands of content items. 
This is an excellent suggestion. I believe we made a modification to do just this.

The issue I have with delete content for spammers is there are no explicit safeguards to prevent this option for members of other groups from being banned. 
Not that I fear it would happen out of malice or intent but rather by accident or curiosity what happened if a moderator flagged someone as spammer who is a long time member?!
I would prefer that this option be only allow to work on  specific groups (newbies) not blankly across all groups -
It seems highly unlikely that a long term member would randomly start spamming a site, this to me indicates their account were compromised and other mitigation should be taken. Such as putting said account in timeout wiping out credentials and putting the last X number of posts in to a queue for review. 
 

Yes, this is one of its primary purposes. The data sent to IPS is used by other communities that have enabled the spam prevention service and have elected to use the return scores to address new account registrations.

Flagging as a spammer does do this if the 'delete' content option is selected.

We flagged a user as a spammer shortly after he registered, based on his first-post content.
The user and content have been hidden as is expected, but the user still shows in this block:

This detracts from the purpose of the block because it can (and will) fill up with spammers during an attack.

Maybe you need to clear your web browser's cache? @Jordan Invision has been teasing an amazing redesign of the IPS homepage that appears to be partially implemented.

Maybe you need to clear your web browser's cache? @Jordan Invision has been teasing an amazing redesign of the IPS homepage that appears to be partially implemented.

Maybe you need to clear your web browser's cache? @Jordan Invision has been teasing an amazing redesign of the IPS homepage that appears to be partially implemented.

Maybe you need to clear your web browser's cache? @Jordan Invision has been teasing an amazing redesign of the IPS homepage that appears to be partially implemented.

Maybe you need to clear your web browser's cache? @Jordan Invision has been teasing an amazing redesign of the IPS homepage that appears to be partially implemented.

IPS 4.6 version submitted to the marketplace.

I've had a LOT of spam registrations from both China and Russia.  It got to the point where I finally used the Cloudflare WAF to deny traffic from those two countries.  

We'd like to empower moderators to restrict private messaging as a consequence, yet still allow content to be posted/moderated in public areas of the site. Right now, a moderated member needs moderator approval before their public content is displayed, however these members can still use private messaging if it's otherwise enabled for their user groups. That's not always a right fit.
What we'd like is a new consequence option when issuing a warning that would allow us to select whether or not private messaging is enabled for that individual without having to grant access to the admin cp. We don't want to grant access to moderators to access the entire member record, and only give them the ability to enable/disable private message access as a consequence surrounding the warning system.
So, in other words, add the bolded option to warnings please:
Moderate Content until dd/mm/yyyy hh:mm:ss, indefinitely Restrict from posting private messages until dd/mm/yyyy hh:mm:ss, indefinitely Restrict from posting public content until dd/mm/yyyy hh:mm:ss, indefinitely Suspend from accessing the site until dd/mm/yyyy hh:mm:ss, indefinitely Many thanks!

After each major IPS release all of the developers are busy updating all of their existing marketplace and custom apps.  This particular release is all the more challenging as IPS and the developers need to ensure their code works with PHP 7.x and 8.x which adds to the complexity of coding and testing.
Most developers only have a few hours each week in which they can devote towards the marketplace as they have full-time jobs and many things that take up their time.  Also a handful of developers have left the marketplace in the past year or have had to deal with various personal issues that have prevented them from being available.
Most developers seem to be releasing updates with minimal additional functionality so I wouldn't be surprised if they will be busy again reviewing customer suggestions and releasing follow-up versions.  Things will settle down some in a few months after which time "some" of the developers might entertain doing custom projects.
The marketplace could benefit from a handful more developers but that's not such an easy thing as it requires a significant amount of time and effort to become sufficiently knowledgeable with the IPS codebase and programming environment as well as the cost of purchasing the suite and paying ongoing renewals. Selling 10 apps here and 20 apps there at 10 to 20 dollars isn't likely to be exceptionally enticing to join the marketplace.  
I would welcome the community and IPS to come together to make it more enticing for new marketplace developers and appreciating the efforts that the old-timers make on an ongoing basis.  
 
 

The 200 error code, in IPS land, is likely coming from your image manipulation software (imagemagik, gd). While @Jimi Wikman is right that a 200 response code for HTTP requests means "success," that's not what you're seeing here.
 

I'm hopeful this is an oversight that will be promptly addressed prior to release.

Okay after a bit more digging into the code, i see why this can happen.
it is any theme hook, that has an override for a template in it or aka "theme hook in php mode"
try{ if ( eval( "namespace IPS\\Theme;\n\n" . str_replace( array( ' extends _HOOK_CLASS_', 'parent::hookData()' ), array( '_tmp', 'array()' ), file_get_contents( $path . '/' . $data['file'] ) ) ) !== FALSE ) { $class = "IPS\\Theme\\" . $data['class'] . "_tmp"; $templateHooks = array_merge_recursive( $templateHooks, $class::hookData() ); } } catch ( \ParseError $e ) { } in php 8.0 it is now a fatal error to call a non existing parent class/method, in the latest php 7.4 it is a deprecated.
so since at this point, the hook in php mode isn't actually extending another class, it is blowing up. this is def an engineering issue on IPS side of things. so technically any theme hook in php mode, that eval and try to call a parent method that doesn't exist, will throw this fatal/warning in the current versions of php. we don't see it while IN_DEV cause templates are compiled differently there. 
i wonder now if it happens with class hooks, that get wrapped up by IPS try/catch block they place inside every method, even if the method doesn't exist in the parent.  
 

Void. 
You don't want to delete all traces of fraud, but rather stop the transaction.

From my point of view, situations like this call for an emergency email or front end push message to ALL admins. I installed the update on 5 sites and had no idea it had effectively deactivated sign-ups on all of them. (I don’t use quick-registration) And this includes sites with like 100 new members a day (and potential clients which might never come back). If I hadn’t seen this topic, the problem might have persisted for days, if not weeks. There isn’t even a backend warning. Having the main registration form working isn’t “optional” as the grey “optional update” link suggest, it’s absolutely CRUCIAL. 

Fixed your typo.
1. Have a test copy of your production environment. What does that mean?
Same version of OS, same version of PHP, same version of web server, same version of MySQL, same extensions, same configurations, different hostname, behind a firewall or otherwise secured. Not "kind of the same," or "almost the same," or "completely different." Same plugins, extensions, themes, languages, configuration for IPS Ensure things that interact with the outside world (payments processors, e-mail configurations, APIs, etc.) are pointed to corresponding test environments as well. You don't want real payments being processed or real e-mails being sent out from your test environment that affect your members. 2. Make changes in your test environment and document your changes carefully, noting the exact steps you took.
3. Test!
4. Have an issue in test? Investigate and open a ticket.
5. No issues, follow the same steps you documented in step 2 in your production environment.
If you're doing it any other way, you're gonna have a bad time.