teraßyte

You likely have a huge achievements activity log, and the bigger the table grows, the slower the site is. I've seen it happen before. Try enabling the setting to prune the old logs and see if it helps:

Let me ask you a quick question: is your admin account in at least 1 club?
 
I have looked at the code, and unless the member editing the stream is in at least 1 club, the field with the club options won't appear. I consider it a bug since IPS shouldn't check if the specific user is in any clubs from the ACP:
/** * Fetch our clubs and cache * * @return array */ protected function _getOurClubs() { if( static::$ourClubs === NULL ) { static::$ourClubs = \IPS\Member\Club::clubs( \IPS\Member::loggedIn(), NULL, 'name', TRUE, array(), \IPS\Settings::i()->clubs_require_approval ? array( 'approved=1' ) : NULL ); static::$ourClubs = static::$ourClubs ? iterator_to_array( static::$ourClubs ) : array(); } return static::$ourClubs; }  
For the admin dispatcher, they should pass NULL rather than \IPS\Member::loggedIn() as the first parameter.

It's been broken for months now... 🙄

Yeah, I agree. Posted a bug report on that

The core_output_cache table holds only temporary caches that can be recreated at any time. You can forget about it.

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.

Those are absolutely server issues then as IPB has nothing to do with accessing those services!  Good luck. 

Having a host with hard limits on things such as number of files or processes running is usually the one's you should avoid.  Is this a shared hosting server or VPS? I'd look into a different host if I were you. 

You're nowhere near your limits in that screenshot. Is it possible that your site/server was hit by a DDOS attack? I'd check that with your hosting.

Ok, can I ask why it's done that way? I think most people wouldn't realise the setting is there unless they are creating their own signature themselves.

Please keep the extension's behavior consistent across all the functions. Some extensions first check if the extension implements a certain function before calling it, while others expect the function to exist at all times and throw errors if they're missing.
 
For example, the core/ModeratorPermissions currently has 4 functions available (preSave, getPermissions, onChange, onDelete) but only preSave checks if the function is available before calling it:
/* Allow extensions an opportunity to inspect the values and make adjustments */ foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { if( method_exists( $ext, 'preSave' ) ) { $ext->preSave( $values ); } }  
The other functions instead are called without any check:
foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE, 'core' ) as $k => $ext ) { foreach( $ext->getPermissions( array() ) as $name => $data ) { // ... } } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onChange( $current, $changed ); } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onDelete( $current ); }  
While I understand that getPermission() must be always implemented (the extension would have no meaning otherwise), the other 2 functions onChange() and onDelete() are completely optional and cause empty functions to be left around. For example, this code below comes from the Blog's extension:
/** * After change * * @param array $moderator The moderator * @param array $changed Values that were changed * @return void */ public function onChange( $moderator, $changed ) { } /** * After delete * * @param array $moderator The moderator * @return void */ public function onDelete( $moderator ) { }

Please keep the extension's behavior consistent across all the functions. Some extensions first check if the extension implements a certain function before calling it, while others expect the function to exist at all times and throw errors if they're missing.
 
For example, the core/ModeratorPermissions currently has 4 functions available (preSave, getPermissions, onChange, onDelete) but only preSave checks if the function is available before calling it:
/* Allow extensions an opportunity to inspect the values and make adjustments */ foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { if( method_exists( $ext, 'preSave' ) ) { $ext->preSave( $values ); } }  
The other functions instead are called without any check:
foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE, 'core' ) as $k => $ext ) { foreach( $ext->getPermissions( array() ) as $name => $data ) { // ... } } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onChange( $current, $changed ); } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onDelete( $current ); }  
While I understand that getPermission() must be always implemented (the extension would have no meaning otherwise), the other 2 functions onChange() and onDelete() are completely optional and cause empty functions to be left around. For example, this code below comes from the Blog's extension:
/** * After change * * @param array $moderator The moderator * @param array $changed Values that were changed * @return void */ public function onChange( $moderator, $changed ) { } /** * After delete * * @param array $moderator The moderator * @return void */ public function onDelete( $moderator ) { }

In case you don't want to put the whole site offline but only a specific application, for example only Calendar/Events, you can put it offline by going to ACP > System > SITE FEATURES > Applications > Events > Lock Icon (on the right).

Here's another good example from a random site that shows different payment options in case IPS needs inspiration on this commonly-accepted practice:

I think thats the version where the admin CP manages you.

Topics have no custom fields.
If you have the Pages/CMS application you can use a custom database instead:

Nothing will change. The CSS only hides the HTML content, but the <script> in this case will still be executed on page load regardless.

Subscriptions have been available for some time now and offer a good way to monetize your community. It would be nice if each subscription had the option of multiple offers - time frame/settings. Most sites these days offer a discount for an annual subscription. In IPS, you have to create an entirely new subscription/box rather than something like:

 

On another note, the preSave function is not even included in the file added by the developer center when you add the extension from ACP. That's another thing that should be double-checked: update example files with all available functions and clearly indicate which ones are required.
 
EDIT
Nevermind, I actually mixed up ModeratorPermissions with ContentModeratorPermissions (that doesn't support preSave). It's still something that should be double-checked for all extensions anyway.

Please keep the extension's behavior consistent across all the functions. Some extensions first check if the extension implements a certain function before calling it, while others expect the function to exist at all times and throw errors if they're missing.
 
For example, the core/ModeratorPermissions currently has 4 functions available (preSave, getPermissions, onChange, onDelete) but only preSave checks if the function is available before calling it:
/* Allow extensions an opportunity to inspect the values and make adjustments */ foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { if( method_exists( $ext, 'preSave' ) ) { $ext->preSave( $values ); } }  
The other functions instead are called without any check:
foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE, 'core' ) as $k => $ext ) { foreach( $ext->getPermissions( array() ) as $name => $data ) { // ... } } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onChange( $current, $changed ); } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onDelete( $current ); }  
While I understand that getPermission() must be always implemented (the extension would have no meaning otherwise), the other 2 functions onChange() and onDelete() are completely optional and cause empty functions to be left around. For example, this code below comes from the Blog's extension:
/** * After change * * @param array $moderator The moderator * @param array $changed Values that were changed * @return void */ public function onChange( $moderator, $changed ) { } /** * After delete * * @param array $moderator The moderator * @return void */ public function onDelete( $moderator ) { }

I figured I'd bump this one as a reminder for v5. 😛
 
I use attributes in several custom applications, and I always have to remember to add spaces for them to work. 🙄

In case you don't want to put the whole site offline but only a specific application, for example only Calendar/Events, you can put it offline by going to ACP > System > SITE FEATURES > Applications > Events > Lock Icon (on the right).

I figured I'd bump this one as a reminder for v5. 😛
 
I use attributes in several custom applications, and I always have to remember to add spaces for them to work. 🙄

Please keep the extension's behavior consistent across all the functions. Some extensions first check if the extension implements a certain function before calling it, while others expect the function to exist at all times and throw errors if they're missing.
 
For example, the core/ModeratorPermissions currently has 4 functions available (preSave, getPermissions, onChange, onDelete) but only preSave checks if the function is available before calling it:
/* Allow extensions an opportunity to inspect the values and make adjustments */ foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { if( method_exists( $ext, 'preSave' ) ) { $ext->preSave( $values ); } }  
The other functions instead are called without any check:
foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE, 'core' ) as $k => $ext ) { foreach( $ext->getPermissions( array() ) as $name => $data ) { // ... } } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onChange( $current, $changed ); } === foreach ( \IPS\Application::allExtensions( 'core', 'ModeratorPermissions', FALSE ) as $k => $ext ) { $ext->onDelete( $current ); }  
While I understand that getPermission() must be always implemented (the extension would have no meaning otherwise), the other 2 functions onChange() and onDelete() are completely optional and cause empty functions to be left around. For example, this code below comes from the Blog's extension:
/** * After change * * @param array $moderator The moderator * @param array $changed Values that were changed * @return void */ public function onChange( $moderator, $changed ) { } /** * After delete * * @param array $moderator The moderator * @return void */ public function onDelete( $moderator ) { }

The only "built-in solution" I can think of would be to change the constant to send notifications in the background even when there's only 1 (the default is 5). That way you can bypass the delay.
However, if your site is very active, you'll end up with a huge list of background processes in ACP, though. Not really ideal... 🙄
 
This is the constant you need to add to your file in case you want to give it a try:
\define( 'NOTIFICATION_BACKGROUND_THRESHOLD', 0 );  
Here's the guide on how to use the constants.php file if you've never used it: