All Astronauts

Yeah, the free version at this point isn't supported anymore and I know there is at least one third party app, and probably others, that will break formatting there if you are just using the free version.
Those will probably get pulled with 4.5 anyways.
Glad it's working now for you!

I downloaded the free version but I just bought the paid version and it works thanks 🙂

Group Colors on User Links 17 Released!
For anyone following along, I worked this up. Bottom line is if this was going to get compatible with that app it would need to be me to fix it - apps first over plugins in hook order. I've added specific checks in various templates for the application and if present and enabled, call that app's templates. All other paths involve some deep low-level output manipulation and it is so not worth it -if even grimly possible.
Also changed the forum aside hook point to more tightly target things.

Social Search 5.2 Released!
Added widget for scaled popular search terms Added configurable number of scaled popular search terms to widget and block Block number is in ACP settings, widget number is on the widget settings on the front end when messing around with widgets. Widgets have different scaling CSS calls, just look them up and adjust as needed.

????

Social Search 5.1 Released!
Quick addition of a scaled text popular searches block to the results page - option in settings. Adjusted margins for searches displayed on Search Wall @Ember Stone

This will NOT adjust the color of the results. Your site's colors are going to be so varied that it isn;t worth my time. You can adjust as you like by just adding the changes you need to your custom.css file.
For now, this will take the 20 most popular results and place them in this block (your mileage may vary based on how well-trafficked your community is + you will need tracked data so new installs maybe give it some time to get that data...). This block is at the moment only available on the search results page - it'll come to the front end widgets soon enough but my plate is full and so on on my end and with 4.5 looming (preview prior to beta is awfully close...) any additions to this will wait for my 4.5 sweep.
Oh yeah, the 20 are randomized on page load to mix it all up. (example above only has 14 - its my newer dev install with very little searching so not all the datas)
Popularity text sizing based on percentages - 10 steps - zero to nine. zero being the 'least most popular', nine being the 'most most popular'.
.ss-scale-0 { font-size: 1em; } .ss-scale-1 { font-size: 1.25em; } .ss-scale-2 { font-size: 1.5em; } .ss-scale-3 { font-size: 1.75em; } .ss-scale-4 { font-size: 2em; } .ss-scale-5 { font-size: 2em; } .ss-scale-6 { font-size: 2.25em; } .ss-scale-7 { font-size: 2.5em; } .ss-scale-8 { font-size: 2.75em; } .ss-scale-9 { font-size: 3em; } That's what I am providing. Copy/paste these into your custom.css and add in any color changes as needed to make the text darker or different colors as the percentages change. If you are not going to tweak the sizing then just remove those font-size bits to save on clutter.
To add this block, go to the Social Search settings and enable it. Note that the recent block and this new most popular block can both be on the page at the same time (as in the screen shot) - configure as you like.
Popularity is based on last 90 days.
Not bad for a request made a couple of hours ago 🍺

Social Search 5.1 Released!
Quick addition of a scaled text popular searches block to the results page - option in settings. Adjusted margins for searches displayed on Search Wall @Ember Stone

This will NOT adjust the color of the results. Your site's colors are going to be so varied that it isn;t worth my time. You can adjust as you like by just adding the changes you need to your custom.css file.
For now, this will take the 20 most popular results and place them in this block (your mileage may vary based on how well-trafficked your community is + you will need tracked data so new installs maybe give it some time to get that data...). This block is at the moment only available on the search results page - it'll come to the front end widgets soon enough but my plate is full and so on on my end and with 4.5 looming (preview prior to beta is awfully close...) any additions to this will wait for my 4.5 sweep.
Oh yeah, the 20 are randomized on page load to mix it all up. (example above only has 14 - its my newer dev install with very little searching so not all the datas)
Popularity text sizing based on percentages - 10 steps - zero to nine. zero being the 'least most popular', nine being the 'most most popular'.
.ss-scale-0 { font-size: 1em; } .ss-scale-1 { font-size: 1.25em; } .ss-scale-2 { font-size: 1.5em; } .ss-scale-3 { font-size: 1.75em; } .ss-scale-4 { font-size: 2em; } .ss-scale-5 { font-size: 2em; } .ss-scale-6 { font-size: 2.25em; } .ss-scale-7 { font-size: 2.5em; } .ss-scale-8 { font-size: 2.75em; } .ss-scale-9 { font-size: 3em; } That's what I am providing. Copy/paste these into your custom.css and add in any color changes as needed to make the text darker or different colors as the percentages change. If you are not going to tweak the sizing then just remove those font-size bits to save on clutter.
To add this block, go to the Social Search settings and enable it. Note that the recent block and this new most popular block can both be on the page at the same time (as in the screen shot) - configure as you like.
Popularity is based on last 90 days.
Not bad for a request made a couple of hours ago 🍺

Version 10 Released!
Re-written widget DB routines for efficiency and reduced size. CSS patch for text display in widgets. Added limit to avatar display count in widgets (limit 100). Widgets will no longer appear at all when there is no data to display - that includes messages stating as such. Widget templates re-written for better efficiency. Flood control now in-effect everywhere, setting removed. No repeat writes or updated visit timestamps inside of five minutes for the same member. Recording of topic visits revamped for, yes, you guessed it, better efficiency. Popup table modal now will correctly show member names with group formatting if that option is enabled. NEW! Prune the Who Viewed table! Never, or choose to remove entries older than a configurable day amount. Task always runs daily but will not do anything unless you have the pruning option turned on in the plugin settings. Also, I've compiled a list of some of the feature requests in this thread from the last two years. I'll *try* to get them into whatever this thing becomes - either a version 11 plugin or a re-written "version 11" application as some things can only be tackled if it is an application (access to extensions and so on). 
That list being, with comments by me:
Is there anyway that this counter could also show # of guest views per post on the actual post itself?
(All views already tracked by IPS but not guests separately - also what about bots - possible but would be messy. Lean no... )
  Any thoughts on showing total # of views of a post as well?
(Already handled by Kitchen Sink, also this is inbound by IPS with their thing in 4.5 or I can release<redacted>)
  Is there a way to reset or clear the list of viewers?
(Partially addressed in version 10 with the prune function. Easy add for individual topics but need permissions check AND a place to stick the button.  I'll stick it in the moderators menu - users of this will need to have mod powers AND a separate permission set in the plugin settings. This will happen.)
  Is there any way to have an option to make these plugins respect the "browse anonymously" option and not list members who check that when they log in? Seems like the default software goes out of its way to hide their last login date on their profiles, but this plugin gives them away. I'd need it to hide them altogether so they can lurk threads without being exposed.
(How to deal with anons is mostly dealt with already, setting available to choose to not track anons period. This should probably be good enough.)
  I'll add a no-follow to reader links which should help.
(Already done on the modal button. Probably needed for the widget views as well to reduce SEO load. Will happen.)

There shouldn't be too much left honestly. I think I still need to try and get word boundaries up on search results but it isn't a big priority right at the moment. The rest of it is the usual version one 'oh yeah, I forgot about that thing and that other thing over there and I can probably change these ten lines down to five...'
@Joel R brought up the Clubs miss a few hours ago and I was like "Oh yeah... Clubs..."

The thing about ideas is that once they hit, then the OCD kicks in and you have to act on it...
SSSR 1.2 Released!
Pages CMS records in Streams default to a two-line truncation. SSSR now checks on those and more-aggressively truncates to match the usual two-line character amount. The javascript truncation routine will rarely, if ever, fire on those now. Demonstrably better (at least for my sites where this matters...)

SSSR 1.1 Released!
Fixed a default setting that was beyond form number limit. Removed setting for word count on Streams. Implemented a much more aggressive filter on streams. That default setting may or may not have messed with saving the plugin settings. Sorry bout that if it did.
The new aggressive settings is courtesy of one of my sites where the content items didn't begin with 'words' (don't ask...). While looking at that hitch I quickly realized that playing with customizable word count limits and so on wasn't really necessary and just cut this down to the bone. I looked at the three line stream results (where three lines of text are displayed for the item - that's the max right now, there are some  - like Pages database records - that push out just two lines), worked up a reasonable character count for those, and now we just limit and truncate right around that amount. Stupid fast now.
@Joy Rex without me working up animated gifs this is hard to do, so I'll just try to better explain.
The bottlenecks here are: 
The amount of text these search and stream results push out of your server and down the internet tubes. This large page size now being ingested by your end-user's browser, in addition to any other page load blocking items trying to spark up. The IPS javascript truncation routines that fire AFTER the entire page has loaded. This plugin addresses all three by limiting all the stream and search results text that those things have to deal with. Remember: the hitch is that by default the ENTIRE content item text is pushed out here, no matter how large it may be. That means ALL of that text is rendered by the browser before any javascript truncation happens.
Truncating this text server-side is stupid fast and easy to do. That's less for your web server to push out the door. That means smaller pages for your end-user's browser to ingest  - that's a faster page load time. Those javascript truncate routines have very little to do now.  If the vast majority of the text content of your community, that's forum posts, image comments or descriptions, etc. routinely consist of a handful of lines of text - seriously, like 2, 3, 4, 5 lines or something, you won't see too much improvement here. People aren't so much discussing as they are chatting. 
If instead you have in-depth discussions, people posting paragraphs of text, Pages databases where content items are walls of text (book chapters, creative writing, subtitles, articles, and what not) this is the thing that you NEED! Any animated gif I provide would, with the appropriate content items of sufficient length in the streams, show a before where you literally see walls of text appear on the screen only to eventually snap away Thanos-style when the js truncation fires - after the page has fully loaded of course. The after gif would be faster page loading and minimal, if any screen-snap occurring from the js truncation.
I can even see, for streams, a way to all but eliminate any firing of the js truncation completely. I'd just need to look at the default stream templates to see if they are wanting one, two, or three lines of text - the item type is already there, I can just read it and adjust the cut as needed. I'm noting this for a future rev. No screen snaps allowed (eventually when I get on this addition)
FYI, I've had this stuff laying around for a few years now - I just got around to cleaning it up and piling it all together rather than the hodgepodge of plugins it was.

There shouldn't be too much left honestly. I think I still need to try and get word boundaries up on search results but it isn't a big priority right at the moment. The rest of it is the usual version one 'oh yeah, I forgot about that thing and that other thing over there and I can probably change these ten lines down to five...'
@Joel R brought up the Clubs miss a few hours ago and I was like "Oh yeah... Clubs..."

The thing about ideas is that once they hit, then the OCD kicks in and you have to act on it...
SSSR 1.2 Released!
Pages CMS records in Streams default to a two-line truncation. SSSR now checks on those and more-aggressively truncates to match the usual two-line character amount. The javascript truncation routine will rarely, if ever, fire on those now. Demonstrably better (at least for my sites where this matters...)

SSSR 1.1 Released!
Fixed a default setting that was beyond form number limit. Removed setting for word count on Streams. Implemented a much more aggressive filter on streams. That default setting may or may not have messed with saving the plugin settings. Sorry bout that if it did.
The new aggressive settings is courtesy of one of my sites where the content items didn't begin with 'words' (don't ask...). While looking at that hitch I quickly realized that playing with customizable word count limits and so on wasn't really necessary and just cut this down to the bone. I looked at the three line stream results (where three lines of text are displayed for the item - that's the max right now, there are some  - like Pages database records - that push out just two lines), worked up a reasonable character count for those, and now we just limit and truncate right around that amount. Stupid fast now.
@Joy Rex without me working up animated gifs this is hard to do, so I'll just try to better explain.
The bottlenecks here are: 
The amount of text these search and stream results push out of your server and down the internet tubes. This large page size now being ingested by your end-user's browser, in addition to any other page load blocking items trying to spark up. The IPS javascript truncation routines that fire AFTER the entire page has loaded. This plugin addresses all three by limiting all the stream and search results text that those things have to deal with. Remember: the hitch is that by default the ENTIRE content item text is pushed out here, no matter how large it may be. That means ALL of that text is rendered by the browser before any javascript truncation happens.
Truncating this text server-side is stupid fast and easy to do. That's less for your web server to push out the door. That means smaller pages for your end-user's browser to ingest  - that's a faster page load time. Those javascript truncate routines have very little to do now.  If the vast majority of the text content of your community, that's forum posts, image comments or descriptions, etc. routinely consist of a handful of lines of text - seriously, like 2, 3, 4, 5 lines or something, you won't see too much improvement here. People aren't so much discussing as they are chatting. 
If instead you have in-depth discussions, people posting paragraphs of text, Pages databases where content items are walls of text (book chapters, creative writing, subtitles, articles, and what not) this is the thing that you NEED! Any animated gif I provide would, with the appropriate content items of sufficient length in the streams, show a before where you literally see walls of text appear on the screen only to eventually snap away Thanos-style when the js truncation fires - after the page has fully loaded of course. The after gif would be faster page loading and minimal, if any screen-snap occurring from the js truncation.
I can even see, for streams, a way to all but eliminate any firing of the js truncation completely. I'd just need to look at the default stream templates to see if they are wanting one, two, or three lines of text - the item type is already there, I can just read it and adjust the cut as needed. I'm noting this for a future rev. No screen snaps allowed (eventually when I get on this addition)
FYI, I've had this stuff laying around for a few years now - I just got around to cleaning it up and piling it all together rather than the hodgepodge of plugins it was.

LOL I like it. Thanks for helping non coders.

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.
 
 

This sounds really useful - could you provide a before and after example?

Enhanced Join Date 10 Released!
Adds Euro Style:  25 Feb 2020 or 25 February 2020

Whelp, that appears to be that. Not much incentive to carry this forward. Consider this app to be in maintenance mode from here on out. I imagine I will make sure its compatible with 4.5 whenever that hits, and bug fixes if needed of course, but any new features/dev would not be the best use of my time.
So it goes...

Wow, fantastic. Exactly what is needed.
Thank you very much.

@Mercury_ there ya go. Enjoy.

To follow up for those reading along, I gave up trying to get his htaccess right for CORS. Maybe it's something weird on his CDN end - maybe something weird with acp urls and the additional /admin/ bit. Life is way too short to bother so rather than using the resources feature I've just dumped the AA font icon into the interface directory which solves the problem 100%. Not sure if this change will get released right now though. Maybe if I tighten a few things up, or I'll wait because...
The next big release (Spacious ACP 20) will be with 4.5 as that, given the ACP changes, will make this a full-sweep kinda thing. Doesn't mean I'm not prepping junk ahead of time.
Pushing server load, memory available, and local storage remaining to the front side for one (admins only of course).

On the user menu now, compact/concise display, with tooltips. These stats are actually tasked, every five minutes. I'll let you choose which server load percentage to display (15, 5, or 1 minute amount) - will try to tool-tip all of it there as well.
S'alright?
Also, would you guys want an option to dump this into the footer like ye'olden days of ancient IPS and VB? I think IPS had this... I have it in the user menu so you can actually see it regularly, unlike the footer, but can do both.

I just checked on another user's  your site and the problem occurs when you use a CDN and push theme resources to it. Your browser won't load the font file as it thinks it's coming from some weird not-to-be-trusted place. Here's the error you'll see when you use your browser dev tools:
Access to font at 'https://YOUR_CDN_SERVICE/uploads/set_resources_1/02ee171f2a8c0a74cb9384690414859a_allastronauts.woff' from origin 'https://YOUR_IPS_SITE.COM' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.
So for everyone with this hitch you need to configure Apache/Nginx correctly to handle this stuff or check your CDN settings.
This is a quick guide to see what you need to do:
https://www.maxcdn.com/one/tutorial/how-to-use-cdn-with-webfonts/
All you end up doing, at least on your server-side, is flagging files with extensions such as .jpg, .png, .ttf, .woff, etc... as being cool being loaded from outside sites.
When you get that server stuff patched it will look like this:

Theoretically I could code it to do so but it would require your server to have the exec (or other similar) commands enabled.
But right now, no. Even setting up cron for IPS tasks requires you to manually add the cron command via server command line.

Group Colors on User Links 17 Released!
For anyone following along, I worked this up. Bottom line is if this was going to get compatible with that app it would need to be me to fix it - apps first over plugins in hook order. I've added specific checks in various templates for the application and if present and enabled, call that app's templates. All other paths involve some deep low-level output manipulation and it is so not worth it -if even grimly possible.
Also changed the forum aside hook point to more tightly target things.

Ahh, they list it as a plugin in description.
Well. Yeah, we're fighting over the same space. The hitch being {$member->name} is dumped inside the h1 and the only way to do stuff with that via hooks is grabbing the h1.
For them, now at least since they aren't overwriting the whole header, it's an easy hook as they just tell the hook to insert inside the h1 at the end.
For me though, I *have* to grab the entire h1 as that's the only way to get at that {$member->name} bit - if there were <span>s around that var we wouldn't be having this convo.
Let me think if I can get around this some other way... worse comes to worse I can do you a solid and just throw out one that doesn't have the profile hook.