Safety1st

@Square Wheels Now I understand that the footer is 🙂

Do you have some kind of caching enabled (for example: Cloudflare)? If so guests might still be getting the cached page (which bypasses the server), while logged-in members get the disk full error since they hit the server.

There's no need for a 3rd party app!
You can add custom HTML code to the end of the </body> tag by adding it to the footer HTML field.

Thank you for your feedback

@Pablo BJB Also as part of your troubleshooting, it might be helpful to take a look at some bot control mechanisms.
CloudFlare Turnstile : 
https://www.cloudflare.com/products/turnstile/
And also the CloudFlare free plan: https://www.cloudflare.com/plans/
CloudFlare free plan should help with some website performance issues (DDOS / others). The $20 / month (paid yearly) or $25 per month (paid monthly) might be worth it based on your use case [Your sysadmin will probably have more technical info on this]
While CloudFlare Turnstile doesn't require the user to do anything (like other captcha's make the user select images), I haven't had first hand experience with it. Some reddit reviews say some good things about Turnstile. Since it's free, might be worth trying to see if the bot problem is mitigated. Alternatively you can also consider other popular captcha services. [Again you sysadmin will have latest on the ground reliability and usefulness of these captcha services. If and when you choose to deploy any bot mitigation service, do consider monitoring the end result (website usability, forum users feedback and whether they like it or not, or if the captcha becomes a major friction point / pain for your users) and then re-evaluate.]
Good luck with your troubleshooting. 
 
 

We have released a patch for this issue. To apply, please go to AdminCP > Support > 1st (or top left) box will have a "Optional Patch Available" link. Click it and follow the instructions.

We have released a patch for this issue. To apply, please go to AdminCP > Support > 1st (or top left) box will have a "Optional Patch Available" link. Click it and follow the instructions.

With the way it works now when someone likes a content you post (topic, post, file, image, etc), it shows up in your profile's activity, and you can also look up all the reputation a user has received in their profile.
 
For example, if you look at my profile right now, you'll see this item in it:
A list of reputations given and received is also available on this page: https://invisioncommunity.com/profile/145950-teraßyte/reputation/?type=forums_topic_post&change_section=1
If you follow a link from there, and the post is anonymous, you'll be able to figure out who made the post.
 
It doesn't work like this right now, it's a function that IPS would need to implement in the framework. I guess you can ask for this topic moved to the Feedback forum instead.
 
And no, it's not possible to create a custom modification to change this behavior, either. Because of the way reputation is currently implemented (traits), it's not possible to overload/extend the necessary code.

Here you are - https://forum.invisionize.pl/files/file/918-dp45-disable-indexing/

I asked in his board for his plans. The post was quickly deleted and not answered.

The problem is that Invisioneer automatically opts you into every single thing possible. The default should be opt-in, not opt-out. Took me a week to unsubscribe from everything.

If you use the "optimized" option it's automatically generated. That's as long as you don't have a robots.txt file on the server itself. In that case, the request isn't rerouted and the static file is provided.

IP addresses recycle so it is completely possible it could have been used by a regular user at one point and a spammer. Simply because the IP address is the same, does not indicate a security issue.
It also is completely possible that the user's credentials were leaked in another site's attack, and that user uses the same credentials on many sites, so the botnet was able to log in as them. 
Both of which are not security concerns in our software. We would recommend enabling Two Factor Authentication if you're concerned about this.

Everything is set up to work as a normal email server, and works as it should.
I don't understand what you mean by "drop emails"? 
The mail that I get (as shown above) is the mail server saying there is no mail account on that address, because the spammer have used an email that doesn't exist. Thus I (as in the admin of the site) am sent an email every time these emails won't reach their destination.
So basically I wonder if there's a way to turn off the "Did you forget to submit your content?" email, or a better solution to this behavior?
 

To clarify on this. The message shows because our software is actually being allowed to run those functions. So its not so much a case of whether or not they are disabled. It's a case of finding why they are not disabled

None that I can think of without editing the code/database.
 
I managed locally by temporarily altering the code to disable the json_decode line and saving the settings page.
Updating the setting's default value in the DB and clearing the caches from ACP should work too.

@Safety1st I sent you a PM. 👍

Please note: we do not recommend editing the core files. Any issues (whether visual, data, etc...) which are encountered by doing so are at your own risk. Some errors may only be resolved by restoring from a backup from prior to when the edits were made so be sure to take full, proper backups prior to doing anything.
This is not anything directly related to terabyte but just a generalized comment to any modification.

Please ensure that you are creating new topics for different issues, as this can help in ensuring you get the correct information at any given time.
With this, I would also need examples of the problem. It may be, for example, the user has registered and the spam level that has been ascertained, is at a level whereby your setting dictate they need admin validation

Languages Flags on Board Top by @Adriano Faria

After a fresh install, going to "ACP > System > SETTINGS > Web App" throws a TypeError:
TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given (0) #0 path\to\system\Dispatcher\Controller.php(118): IPS\core\modules\admin\settings\_webapp->manage() #1 path\to\applications\core\modules\admin\settings\webapp.php(39): IPS\Dispatcher\_Controller->execute() #2 path\to\system\Dispatcher\Dispatcher.php(153): IPS\core\modules\admin\settings\_webapp->execute() #3 path\to\admin\index.php(13): IPS\_Dispatcher->run() #4 {main}  
The issue is this code:
/* And finally, additional manifest and livetile details */ $manifestDetails = json_decode( \IPS\Settings::i()->manifest_details, TRUE ); $form->add( new \IPS\Helpers\Form\YesNo( 'configure_manifest', \count( $manifestDetails ) > 0, FALSE, array( 'togglesOn' => array( 'manifest_shortname', 'manifest_fullname', 'manifest_description', 'manifest_defaultapp', 'manifest_themecolor', 'manifest_bgcolor', 'manifest_display', 'manifest_custom_url_toggle' ), ) ) );  
The problem is that $manifestDetails at this point is NULL because the json encoded data is wrongly using square brackets:
["cache_key":1692875360] Instead of curly brackets:
{"cache_key":1692875360}

Thank you! That issue is still open with our developers, I'm afraid.
You can use the * as a wildcard so *@mail.ru would work.

Why do you need to review every single member who registers? Why not just do email validation and moderate the users first post if you're worried about someone coming in and doing harm? There's no reason to "jail" someone until they've done something wrong. Especially, if your community is starting out, you don't want to put more barriers on your new users.
Personally, I would just let them register until you're met with a reason to stiffen up your community registration process.
Would state that a vast majority of our clients do not use administrator validation. It is there for an extreme case of either misuse, or you only want to cater to an extremely small niche and need to validate the registration form before letting them in. For the latter, they have a set of trusted users doing that or are overseeing that themselves as the community administrator till they have a full set of trusted users.
You may wish to review our recommendations/statements in your Feedback topic regarding this 😉 .

This is the issue here in your understanding. To clarify
The statement there is somewhat incorrect. A restricted moderator who is given access to the ACP "Is" an admin. By definition an administrator is a member who has been granted access to the admin CP in any way. The way permissions work are as pointed out above
So a member can be BOTH an admin, and a moderator. In fact technically an administrator could have no moderation capability on the front end if you really wanted (not that there would be much point in this)