All Astronauts

A few updates:
FYI to those lurking, the above stuff was resolved a long time ago via PMs.
Lots of moving parts behind the scenes these days and Invision Community 5 exists in a quasi-state of both being months and months away but also coming on a LOT faster than you realize. Many of my big things will require new purchases for a variety of reasons including but not exclusive to:
a somewhat new codebase what may or may not be possible to do in the new version and other probably secret things  If you are punching renewals on this, thank you as always, but I'd request you actually hold off on those for now - ditto for any other apps/plugins of mine you have until the sun rises on a few things. You'll have clarity soon enough. Things change, the world ever turns, and all that, but I'm not going anywhere. 

I've got a few spare licenses that are not in use at all - no domains attached, not actively licensed. 
Any chance these can remain "parked" until I activate them for actual use and then the "keep up with renewals or else" stuff kicks in? I'd hate for these licenses I paid for to go extinct for lack of use (rather than in-use but lagging on renewals). If the current opt-in thing for the new way stays in place for all these oldies; then I think were good because I can just "opt-in" when they go active; but getting clarity here would be nice. I think this is/was clarified above... still gonna ask about this specific use (non-use) case.
Also, while we're here... some of these changes I wouldn't mind seeing applied to the Marketplace. I've got people renewing stuff for super cheap simply because the renewal price was cheap years and years ago but new renewal prices do not apply to them. Also, if staying current with renewals is the new model, having that for Marketplace purchases seems a fair option for us to apply to our stuff as well. Granted; probably some dev on your end, but I'm thinking both of these requests would be welcomed by most if not all the Marketplace participants. This would also allow us to adjust our pricing downwards if we knew we'd be getting a more steady stream of revenue.
 

I've got a few spare licenses that are not in use at all - no domains attached, not actively licensed. 
Any chance these can remain "parked" until I activate them for actual use and then the "keep up with renewals or else" stuff kicks in? I'd hate for these licenses I paid for to go extinct for lack of use (rather than in-use but lagging on renewals). If the current opt-in thing for the new way stays in place for all these oldies; then I think were good because I can just "opt-in" when they go active; but getting clarity here would be nice. I think this is/was clarified above... still gonna ask about this specific use (non-use) case.
Also, while we're here... some of these changes I wouldn't mind seeing applied to the Marketplace. I've got people renewing stuff for super cheap simply because the renewal price was cheap years and years ago but new renewal prices do not apply to them. Also, if staying current with renewals is the new model, having that for Marketplace purchases seems a fair option for us to apply to our stuff as well. Granted; probably some dev on your end, but I'm thinking both of these requests would be welcomed by most if not all the Marketplace participants. This would also allow us to adjust our pricing downwards if we knew we'd be getting a more steady stream of revenue.
 

I've got a few spare licenses that are not in use at all - no domains attached, not actively licensed. 
Any chance these can remain "parked" until I activate them for actual use and then the "keep up with renewals or else" stuff kicks in? I'd hate for these licenses I paid for to go extinct for lack of use (rather than in-use but lagging on renewals). If the current opt-in thing for the new way stays in place for all these oldies; then I think were good because I can just "opt-in" when they go active; but getting clarity here would be nice. I think this is/was clarified above... still gonna ask about this specific use (non-use) case.
Also, while we're here... some of these changes I wouldn't mind seeing applied to the Marketplace. I've got people renewing stuff for super cheap simply because the renewal price was cheap years and years ago but new renewal prices do not apply to them. Also, if staying current with renewals is the new model, having that for Marketplace purchases seems a fair option for us to apply to our stuff as well. Granted; probably some dev on your end, but I'm thinking both of these requests would be welcomed by most if not all the Marketplace participants. This would also allow us to adjust our pricing downwards if we knew we'd be getting a more steady stream of revenue.
 

Yep.

Bit of a deep cut this, and probably been there forever, but it would be nice to get this patched, if not in the 4x line, then 5x.
_showImage method, line 305 (or approx) in ips.ui.lightbox.js
// Build meta info if( image.meta ){ pieces.metaPanel .show() .html( ips.templates.render('core.lightbox.meta', { title: image.largeImage } ) ); } else { pieces.metaPanel.hide(); } Any alphanumeric/variable we pass in a front-end template through the data-ipsLightbox-meta bit, (e.g. data-ipsLightbox-meta="DERP"), will never display as you have the title variable in the render call hardcoded to image.largeImage instead of image.meta.
image.largeImage is just the url to the image; once patched we can throw titles, descriptions, whatever at this. Loads better than staring at a full url. Easy fix to boot.

There ya go. It's usually a week+ for approvals (for me at least) so right on time. Viewers users will probably need to wait until after the July 4th holidays for that update.
Enjoy searching and blowing stuff up (if one does that).
BTW, just throwing this old thing out there (I poked this months and months ago) in case it ever occurred to you:
Elasticsearch does have a similar to/spellcheck type feature. Like you misspell a word and ES will be like, you probably meant this one, and so on. It does work with Invision Community... after a fashion.
Long story short, a new, separate index would need to be created along with additional code changes in the indexing and query code to make it really happen. I could give you an option to enable it and it would work 100% right now with SINGLE WORD queries. The moment you add a second word (or more) to your search query it clown cars - everything is seemingly a mis-spelled word and the results returned are entirely property tax paying residents of loltown. Hence the need for the aforementioned changes above, which will not be happening.
I have, however, created the application version of this plugin. Haven't done anything else to it at all, but it is there, staring at me, from the Island of Not-Finished Applications, along with <gestures widely>... A few things from ye'olde Social Search will get folded in and barring this plugin not needing any updates to breaking changes, the next release will be that app, replacing this plugin. Just a replacement, not a new MP release or anything like that. You get an app, and you get an app, and...

They made some changes in the latest patch. Regardless, whenever the new version is approved this will always work as the cookies will be flagged as essential.

They made some changes in the latest patch. Regardless, whenever the new version is approved this will always work as the cookies will be flagged as essential.

Fairly caught. In the member data export extension, I wrongly assume the Blogs app exists. In your case, obviously etc. etc... That's on me. Easy patch though how long it takes to get approved and in the Marketplace... I'll take a gander at the other areas and makes sure things are copacetic before submitting. 
BTW, the data export stuff has existed within the Invision Community system for awhile now, new stuff is on the front end for members to say gimme 🙂

Its quite unlikely we would begin adding something to work around hosting companies not having the proper capabilities, to be honest. Using a self hosted environment, you should be looking for your host to meet the requirements your software requires, rather than looking for a workaround.

Yeah, it's been discussed a lot internally for years regarding cookie versus local storage. We do use local storage for somethings, but the downside is that it is not exposed to the PHP layer, which means you'd need to manage any preferences those settings control completely in client side scripting.

The single mark navigator was probably just hung up with a bad cache or something; all good now.
And with that, version 8.0.0 was submitted. Available when available...

Okee-dokie. So, for this to work, I had to add another hook so I could merge the two cookies I have into the essential cookies array. FYI these two cookies exists for, honestly, just a few seconds. When you are on a search results page and click a result to go to, its sets one cookie saying "Hey! Time flag some query terms" and the other cookie is those query terms. Once the content page you clicked to loads, the cookies are read, and then immediately removed. Can't get much more benign than that!
And the search light search terms highlighting is working on the latest - except when you have a single hit - if you have more than one hit, the term navigator appears on the side, but not with just one term - so I need to look at that (probably just a poor eval on my part now).
These two cookies will appear in the cookies list as well:

So, I gotta patch the whatevers first, and then this gets submitted. No idea when the update appears. I imagine there will be a flood of app/plugin updates with the cookie changes.
Oh - I'll check the truncate stuff now - hang on...
EDIT: Yep - truncate works great and everything is perky.

I put the truncating in long ago, then IPS did their own so I took mine out, then they took theirs out so I put mine back in. Worth a look at least to see if there has not been any silent changes there. Give me a bit.

Without looking I'm betting it's all the cookie stuff that was rolled out in the latest version. Did you enable the cookie consent stuff?

@SJ77 This plugin will NOT be updated. It's old hacky whatevers. I mean, it worked - right? But time marches on. People are still using it just fine though so if you have it carry on and so forth.
However...
New thing submitted tonight if I feel it. IPS approval time runs about a week if there are not any problems (and Daniel and/or Stuart are not crushed with other work). Then you can give me some money.
Backblaze, Wasabi, DigitalOcean, iDrive. Vultr too (if you count tests ran six months ago - I don't wanna spin up another $5 to check again). All tested out. 
Things are still derpy but more professionally so. Everything still piggybacks on the internal IPS S3 code. Oh, and Backblaze is solid (I bypass the S3 stuff and use the BB API directly for attachment downloads). And since those guys finally pushed out a status page (albeit a not-too-great one) you get this too:

Obviously a new support topic and so on but that will come post-release.

Tons of icons on a page can weigh things down pretty fast if you are not careful to limit the number displayed (even with caching on delivery and in browsers) - but yeah this isn't a big deal. To be compatible with the above he'd have to target this plugin specifically (those IPS widgets are doing things different in each one) - but to just show icons and what not st a nothing burger.

Sure you can go ahead and do it, but sit on releasing it until you have something meaningful to include. Whether that be bug fixes or enhancements. Releasing only this change is a waste of time for our reviewers and for customers.

Got it, but I need to get some glasses! Clearly my eyesight isn't what it used to be. 😂
Update fixes the issue I experienced. Thank you! 

You can use it as is just fine. If you HAVE to have the template parsing for random template logic and the like I'll... have to revert some code and then push the 2.0 again
See, they rejected that 2.0 update saying that the parsing of output (server-side) I do was "too heavy", at least they "thought/think" it was...
Thing is, that output parsing was already released in a previous version - the one available now if you purchase - and its not really affecting anything really - currently running on one fairly heavily trafficked site with no impact. Oh, I can see how it might impact things but its really not much different than what they do with emojis. So, when that rejection came I just thought I'd let things lay as it were and get around to "fixing" the update eventually.
That said, the initial release of Ads Everywhere had everything inserted via Javascript post-output. Which is what they want now. Which is fine, I just have to revert a bunch of changes (pita but no biggie) and tweak some other things.
If I go back to making all the ad inserts post-page load, there are some ad providers that can't handle that (Monumetric for one): they see an ad pop up in the DOM, they run the ad, and their code stops - it's not DOM-aware enough for another ad being inserted (or more) - hence why I did the output parsing in the first place so the ads were in the document on output and the ad network JS code would fire on all of them. Neat and tidy, no mess, no fuss.
When I do push the reverted all-JS version of 2.0, this means to accomplish this, I gotta tell everyone that the ad network JS code they typical stick in the header - they will probably need to specifically use my Ads Everywhere header block now for that code (leaning towards MUST). Because in order for the Monumetric (others..) ad networks to work in the revised version is for me to JS insert all the ads into the document and then LASTLY insert the core header JS ad network stuff so that it fires off on all the ads.
tldr; Unless you need to parse things like member variables and custom Pages blocks and stuff like that, go ahead and buy now and have fun. Otherwise, my skies will be "clearer-ish" in like two weeks or so to swing back to get this patched up. 

Thanks - works perfectly both in search and  activity stream.

ol.ipsStream li.ipsStreamItem:nth-child(2), ol.ipsStream li.ipsStreamItem:nth-child(4)
You will need to adjust the nths as needed. If things are off by one or whatever, again, just adjust the numerical nths and move on with your life.
The above inserts after 2 and 4, and is firing after 1 and 3  - that's because that timeline "earlier" thing is a LI element and is being counted. Like I said, just adjust numericals there and move along...
Two things: Be sure to set a position (before, after, etc.) in the radio choices for the ad - I do not have that field marked as required and its not auto-filling a default choice (at least locally) - I'll patch that for the next release - don't be like me staring at the output wondering why its not working and then discovering the above reason as to why. It's not pretty 🙂
The other is when entering more than one CSS selector (like I have above), you do comma sep them, spaces after the commas are fine, but do not have a trailing comma - it will err on that. Again, I'll make sure to clean that on the next release and prevent that by default.
Heads up that the CSS above will cover search results as well as streams. If you need to NOT have search results here yell back or figure out the more specific targeting yourself.