All Astronauts

This was already submitted - sans Font Awesome - I'll add that as an option. Otherwise out of the gate it has dot next to name, outline user avatar, or online badge style next to the three dot post menu bit (where the author badge shows up)
FYI this is not just forums. Covers all commenting and reviews areas across the suite, and likely 3rd party apps as well if they are using (directly, not copying) the default templates involved there. 
Extra FYI: when it shows up in the MP it will be called Online Status
Where would you put the FA icon? Replace the dot? Replace the badge? Both?

This was already submitted - sans Font Awesome - I'll add that as an option. Otherwise out of the gate it has dot next to name, outline user avatar, or online badge style next to the three dot post menu bit (where the author badge shows up)
FYI this is not just forums. Covers all commenting and reviews areas across the suite, and likely 3rd party apps as well if they are using (directly, not copying) the default templates involved there. 
Extra FYI: when it shows up in the MP it will be called Online Status
Where would you put the FA icon? Replace the dot? Replace the badge? Both?

That was the icon used:
 

public static function roundedDiffFromSeconds( $seconds, $memberOrLanguage=NULL ) { $now = static::ts( time() ); $then = static::ts( time() - $seconds ); return $now->roundedDiff( $then, $memberOrLanguage ); } Don't panic! This is not related to all the other DateTime shenanigans going on. Just a small bug with a big return - routinely 52 years.
The problem is having $then calculated as time() - $seconds. That needs to just be seconds:
$then = static::ts($seconds);
You only use this in one spot (admin\stats\timeToSolved.phtml) that I can see so probably just been overlooked for a while.
Full Explained working on something not quite two minutes old:
$now: 1663390800
$then:  1663390800 - 1663390700 = 100
$now->roundedDiff ($then);
roundedDiff then immediately calculates its own difference:
$this->diff($date) which in this case is $this->diff(100) which is the difference between right now and 100 seconds after January 1, 1970 midnight UTC.
 

public static function roundedDiffFromSeconds( $seconds, $memberOrLanguage=NULL ) { $now = static::ts( time() ); $then = static::ts( time() - $seconds ); return $now->roundedDiff( $then, $memberOrLanguage ); } Don't panic! This is not related to all the other DateTime shenanigans going on. Just a small bug with a big return - routinely 52 years.
The problem is having $then calculated as time() - $seconds. That needs to just be seconds:
$then = static::ts($seconds);
You only use this in one spot (admin\stats\timeToSolved.phtml) that I can see so probably just been overlooked for a while.
Full Explained working on something not quite two minutes old:
$now: 1663390800
$then:  1663390800 - 1663390700 = 100
$now->roundedDiff ($then);
roundedDiff then immediately calculates its own difference:
$this->diff($date) which in this case is $this->diff(100) which is the difference between right now and 100 seconds after January 1, 1970 midnight UTC.
 

public static function roundedDiffFromSeconds( $seconds, $memberOrLanguage=NULL ) { $now = static::ts( time() ); $then = static::ts( time() - $seconds ); return $now->roundedDiff( $then, $memberOrLanguage ); } Don't panic! This is not related to all the other DateTime shenanigans going on. Just a small bug with a big return - routinely 52 years.
The problem is having $then calculated as time() - $seconds. That needs to just be seconds:
$then = static::ts($seconds);
You only use this in one spot (admin\stats\timeToSolved.phtml) that I can see so probably just been overlooked for a while.
Full Explained working on something not quite two minutes old:
$now: 1663390800
$then:  1663390800 - 1663390700 = 100
$now->roundedDiff ($then);
roundedDiff then immediately calculates its own difference:
$this->diff($date) which in this case is $this->diff(100) which is the difference between right now and 100 seconds after January 1, 1970 midnight UTC.
 

It's end-of-life - will not be upgraded.
I made a new BETTER version that handles more than forums - it is the upgrade for newer versions:
 

@OptimusBain all good with the new version?

I'll show myself out...

Eh, I'm just puttering on various things on the back deck right now (upper 70s, low humidity, nice breeze - yes...) so shoot me a PM with your site (and ACP access which I imagine I've already done with you before) - and I can look closer. At least maybe see what bookmarks is doing there to muck it up.

It's going to be Bookmark. Specifically, because it stuck itself at the front of the list. I was doing an even/odd thing in the CSS to hide this and appending this button to the front breaks that. This whole area is a hot mess when it comes to multiple third-party hooks and such. Although... I haven't changed this code in ages - maybe there is better targeting available now? Checking. 
EDIT: So now I remember why. The targeting with competing plugins back in the day was hell so I just gave up and did the even odd thing. I can still do this with CSS using nth-of-types now (maybe before too - the mind blurs when you are down some CSS rabbit holes)
I'll submit a new version - gives me a chance to get the version language strings right internally.

I just woke up, didn't even know it was approved yet 😀. 
Un momento por favor...

Version 3.0.0 submitted, available ???
4.7.0 Compatibility Sweep NEW! Added to Font Awesome 6 to the Font Awesome chooser. Font Awesome 5 remains as an option. A few CSS patches here and there. If you are using the Font Awesome chooser in KS, you are using FA5. This KS now supports FA6 and at a glance, it is more sizing-compatible with FA4 than FA5 was - that is, some FA5 fonts that swapped in for FA4, the sizes were a little off; that's no longer the case (mostly, have not looked at every FA instance). I'd switch the FA6 but I left the FA5 option in place as some of you might have "stuff" going on.
Couple CSS changes I'd probably only notice.
Uhhh... made sure everything was working? Tested on 4.7.1 107021, PHP 8.0.13. 
Oh, and I forgot to change the version number on the internal language file so the ACP settings area will say 2.2.whatever. Already patched for the next release.

Now that 4.7.1 is out I should get along and update this.

Invision Community search and stream results push out the ENTIRE CONTENT ITEM TEXT to the web page and then truncates the result with the browser via Javascript.
This leads to long page load times, snapping screen behavior when the js routines truncate the text after the page has loaded, and so on.
This plugin truncates these results BEFORE they hit your user's browsers, giving them faster load times and better engagement.
Speedy Search and Stream Results (SSSR) is a roll-up plugin that includes my free Truncate Stream Items plugin and adds on a truncate search results feature, a bit that allows you to select the number of images pushed out to stream results when the stream item is a Gallery album update (new images posted), and a setting to allow you to truncate down stream descriptions which can get ridiculously long when a user has selected many forums and so on for their custom streams. 
The IPS javascript truncate functions will still fire on these pages but with vastly less text to deal with! Plus of course, the added benefit that that text was never sent to the page in the first place... 
See the screenshot for settings.
 
 

7.0.0 Submitted! Available when approved...
NEW! Last Searches made by community members added alongside Quicksearch!
NEW! @HDiddy Your Quicksearch filter filter has arrived!
CHANGE! The remove content item icon from search results has been expanded into an emphasized search results view option.
4.7.0 compatibility sweep. All good. 6.0.0 users are fine as well.


This is an option in settings. Toggle it on and the last searches made by your community members will appear here. Unlike Social Search, I do not believe I am running these through the bad word filter - these are a straight pull from what IPS is saving as searches now. Yell if that is a problem. Otherwise, as long as you have searches this will populate nicely. Looks good when QS is not expanded, the results will pile in when it is expanded. There is a hard-coded three-minute cache on these terms. So after three minutes since the last build, the next Quicksearch user (or more likely page load) will rebuild the cache and so on - so your DB load is pretty much nil on this.

This has been sitting in this plugin since December/January I think; sorry bout that. Anyways, as stated above, when you have a ton of pages content every bit gets jammed into Quicksearch. You can toggle some of them off here and just present a lean QS experience instead of overwhelming users with options. This affects the QS EXCLUSIVELY! Users using advanced search will still get all the options they can handle.
As for the emphasized search results option, this:

Becomes this:

No more superfluous icons and photos, slightly enlarged search result text, margins and padding adjusted to fit.
Everything is working as before in 4.7.0 - oh, though I did make an adjustment to the search marking terms cookie auto-destruct time.  When you click through on a search result with Searchlight enabled, your search term comes through on a cookie that is made on the spot, then read once your content page finished loading, and then is wiped out just as fast. I had it set to autodestruct after 8 seconds just as a safety catch but ya know, if you have a content item loading in that is - oh - say - maybe 1/3 of a book text? A really thick book? It takes time for a DB to grab that blob, and then it takes time for your browser to dump all that text into the window. Unlike when IPS was doing this with search and stream results (remember the whole point of this mod initially?), we do want all the text of the content item to load in. But time. Yeah. 8 seconds was not enough so Searchlight would not run if the page took longer than that to load, which it did on one of the sites under my purview. That number is now 16 seconds - maybe more. So, on the off-chance you have massive content items that Searchlight was not firing on to mark out terms, it probably does now 🙂
BTW I'm way behind checking out my apps and plugins for 4.7 but I really do imagine everything is perfectly fine for upgrading if you don't want to wait.

Pages Category Images is good to go as well. Upgrade away.
I did submit a new version to the Marketplace - 4.1.0 - the only change is adding in a template that displays beneath the image upload field providing the ways you can use this stuff - and of course flagged the file out for 4.7 compat.

Pages Searchable Text Fields is fine on 4.7 - I resubmitted a new 4.0.0 version to the Marketplace so I could flag the file out as 4.7.x compatible, but other than the version number the plugin is the same - though I think in the next version I'll stick a flag in on database fields view so you can see that a field is flagged as searchable or not. 
Looking at PCI now, should be back here in a bit...

Viewers 2.0.0 Submitted!
NEW! Pages application now supported! Both Custom Page views and Database Record views. NEW! Blogs application now supported! Blog entry views. NEW! Added Member Data Export for Pages Pages, Pages Database Records, and Blog Entries for GDPR compliance! ENHANCED! Adjusted all Member Data Exports to match native IPS data export date formatting! EXPECTED! 4.7.x compatibility sweep. etc... As stated earlier - Pages Pages,  Pages Records, and Blog Entries are only widgets for the time being:

Drag and drop widgets are locked to their respective "thing". Blog Entries will only show something on Blog entries. Pages Pages will only show on basic pages. Pages Records will only show on record view. Yes, databases live on a "page" but that is accounted for.
The GDPR member data export stuff is all set with the new stuff as well so those of you in affected areas, or just needing to comply with user data laws of some type, can rest assured you can dump this stuff will no problem at all.
Available when approved.

Pages Category Images is good to go as well. Upgrade away.
I did submit a new version to the Marketplace - 4.1.0 - the only change is adding in a template that displays beneath the image upload field providing the ways you can use this stuff - and of course flagged the file out for 4.7 compat.

Poked. I had to increment the version number from 20.0.0 to 20.0.1 for the resubmit. Other than that, the file is identical to what you have now.
All good.

Almost certainly. I'll test both of these (they are separate things) later today and report back. I have to resubmit the files regardless if there are changes or not to get the Marketplace to flag them up for 4.7 compatibility officially though so that will take some time.

Almost certainly. I'll test both of these (they are separate things) later today and report back. I have to resubmit the files regardless if there are changes or not to get the Marketplace to flag them up for 4.7 compatibility officially though so that will take some time.

Thx, I have fixed the class name in the skeleton file.

I'm on the support list of a CIC client, the Client Area support button clearly states support request must come from my email address, your system bounces it telling me "lol no. You are self-hosted""
If you see these bounces internally just grab it and go, otherwise point me in a direction. The actual site problem should be an easy fix (CMS block will not open for editing - clearly exists and is working - I'd poke it with the SQL tool but... you know...)