SeNioR-

A user on my community brought this to my attention.  I think this may be intended behavior by Google chrome, but should be something reviewed for an overlay by IPS 
WebP images open in a new tab, and are not scrollable like JPG
Sample topic: 
 

I agree with @Morrigan. Nearly 4 years on from his post, and I am a bit frustrated with the moderation and ban systems. It is way more difficult and disjointed than it need be, with no real options to track historical moderation problems and add notes with a ban. I'd also like to have a message display to the banned member with a reason.
I won't get into this too much now - I am hoping there will be significant improvements with V5 and my comments here will be moot.

Please move this to the feedback thread then.
 
Thank you.

Suddenly it's 2018.
This isn't directed at you Jim, but at the decision-makers at IPS as a whole.
The fact that a vendor of web-based photo gallery software doesn't officially support WebP in 2024 is, frankly, absurd.
And it's absurd for several reasons:
It clearly works. I wasn't even aware that webp wasn't officially supported (or I didn't remember) because I've been uploading webp to my galleries for a while now, and it has been working nicely, and will continue to work nicely in their new S3 home. The standard was announced in 2010 and went to stable release in 2018. There's been 8 years to get onboard. Much of the web has been using it for years, especially the big, picture heavy sites. The search engines penalize us for using heavy images and I personally see a significant performance difference on my own site with webp. The only thing that broke here was that I moved storage locations, and the url update task isn't processing the new location properly. The images are still attached properly to the article, they just aren't embedded correctly.  
 

Just delete or remove enough characters, and then you will be able to post. You are able to edit or type in that box.  
This happens to me all of the time.  I either truncate the content or override all of the content with my own quick summary. 

No. While you can download an application's folder from the server, plugins aren't the same. When plugins are installed, the setup folder is NOT saved on the server. And the original XML file is not available, either.
You'll need to rebuild the XML file from scratch based on the files on the server, plus rewrite from scratch the setup folder (if the plugin creates tables or adds columns).
 
It may take some time, but it can be done. I've done it several times for clients, especially recently after the marketplace closed.

To be honest, it's quite easy to reproduce. See this:

Someone or something is attempting to "hack" or something on the board. In the code, you may try to find it at applications\calendar\modules\front\calendar\view.php:
/* Pagination */ $offset = isset( \IPS\Request::i()->offset ) ? min( array( \IPS\Request::i()->offset, \count( $events ) ) ) : 0; As you can see, there is no check to ensure that the offset value is an integer. Please try changing it to:
/* Pagination */ $offset = isset( \IPS\Request::i()->offset ) ? \intval( \IPS\Request::i()->offset ) : 0; $offset = $offset ? min( array( $offset, \count( $events ) ) ) : 0; Should help.

As a matter of principle, PHP 8.2 should be supported officially for v4 in the next months. PHP 8.1 is already in security-only support and that expires on 25 Nov 2024.

If anyone wants my other apps, just let me know and I will post them here.

Website Footer v2 2.0.2.tar
Sorry, I had to close down the site due to issues with the software which I was using. Sadly, I cannot use my own forum for downloads.

PHP 8.2 is not supported. Downgrade to either 8.0 or 8.1.

Sounds like an incompatible php version. 
Make sure that you’re using php 8.0.0 or higher 

This would definitely be something server side and / or associated with other software on the server for a few reasons.
While we do use a custom session handler, we use the proper session_set_save_handler and related functions, rather than ini_set. The only usage of ini_set throughout the software is during an automatic Admin CP upgrade to disable errors, which is a fairly typical use case - and if it fails, the error is suppressed and ignored. This is the case for both 4.16.12.1 as well as the current version. Based on the error itself, it looks like there may be a configuration issue somewhere in php.ini, or in a .htaccess file that is present on the server, attempting to set that directive (which is incorrect in itself - the directive is session.save_handler instead, though that could be as simple as the server interpreting the dot as an underscore in the error).

I don't remember reading anything about it. Today we need to use hooks to allow new videos to be embedded on the site. How IPS5 will handle that?

That's always a risk with sharing tentative dates and timelines. Over sharing can cause issues as well since things can change before being finalized. Along with that, you never know what setbacks (or opportunities) will pop up.
I'm always checking for the next update (we were spoiled last fall), but with such a major overhaul, let's let them cook. 
Reading between the lines, it feels like there are some updates being made to core features that should help IC5 hang with some of the more well-known CMS's out there.
The initial goal I saw was releasing a beta before the end of 2023 with a Q1 2024 release. Planning to be an early adopter, I shared with my community an update would be coming in 2024 and hopefully before the college football season in September.
Either I'm clairvoyant or I've been involved with too many development projects 😂
I hope this didn't come across the wrong way. It can be very difficult to provide regular updates when there's so much liable to change.

As the feed view is an IPB5 feature, it won’t be available until IPB5 is available   
As the feed view is an IPB5 feature, it won’t be available until IPB5 is available.

Hi,

We've been having issues every 6 hours when the badge status cache expires and they regenerate. This causes our (rather large) DB to hit 100% CPU and the forums become unresponsive.

Looking into this, the issue is that multiple threads will try to get the badge stats at once when they expire: \IPS\core\Achievements\_Badge::getBadgeStats()

We have approximately 40 concurrent requests trying to regenerate these stats every 6 hours.

As a work around, we are temporarily updating the stats expiration while we re-generate the statistics, this results in it only running once per 6 hours (instead of 40 times)

 
if( !isset( $stats['expiration'] ) OR time() > $stats['expiration'] OR !isset( $stats['badgeCount'][ $this->id ] ) ) { // Write the old stats back to the store while we regenerate them $stats['expiration'] = time() + 60; \IPS\Data\Store::i()->badgeStats = json_encode( $stats ); $stats = NULL; }  

As you have a custom theme and third-party applications/plugins which interact with code surrounding this, I would recommend starting by ensuring these are compatible with the release you're on. 

<script> alert("{expression="\IPS\Member::loggedIn()->email"}"); </script>  

Thanks for the response!  There are some JS and JQuery errors, but nothing seemingly significant.  We're not using any custom JS; aside from some minor CSS tweaks, everything we're doing is vanilla Invision CMS.
Lazy loading was enabled and never disabled.  I just disabled it, and it triggered a rebuild.  I'll give that some time and try the page again once it's completed.

I sent him a PM on his website and have been waiting on verification since december.

Hi all,
I've been struggling to get my server to support auth headers for the API. I am using Plesk to manage everything and the forum is hosted on Apache with FPM.
What I've tried so far
Adding CGIPassAuth on to top of .htaccess for the /api/ subfolder Adding to top FcgidPassHeader Authorization of .htaccess  I tried adding both to the apache directive  I've tried adding FcgidPassHeader AUTHORIZATION to the primary fcgid.conf file and restarting the service I've also tried doing a combo of all the above I tried changing SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$0 to SetEnvIf Authorization .+ HTTP_AUTHORIZATION=$1 in .htaccess I've tried a few things that I can't remember but I think I've tried everything that I've found from Googling maybe I missed something else that I can try.
I'll appreciate all the help that I can get. 
Thanks! 🙂

Quick edit:
I am running
PHP 8.2.17 with FPM/FastCGI
Server version: Apache/2.4.37 (AlmaLinux)
Server built:   Oct 18 2023 12:00:09
 

Invision Community
Version 4.7.16
  Running latest version
 
No patch available

The temp_ban column in the core_members table contains the banned state.
0 means not banned
-1 means banned 
any other integer in this column is the timestamp until the user should be banned