All Astronauts

Ignoring the fact that I have to re-submit this update because I forgot to increment a number on the submission form which makes your ACP MP entry tell you that there is an update available, you have a new KS inbound. Soon...
KS 1.2.0
UPDATE! Altered the breadcrumb hook. Home icon now inserted without replacing elements, home text removed via JS. UPDATE! Review stars now use the complete half-star icon instead of the default half and half-flipped approach. NEW! FA5 Pro licensed icons supported.  FIX! Reverse Post Order in Topics setting when set to apply to all forums. FIX! Some sites do not ajax-load new pages of Forum topics, so I had to fix up the topic post numbering feature to account for that. I believe that takes care of any requested fixes/hitches lingering about.
EDIT: My MP idiocy has been reverted and now KS 1.2.0 has been successfully submitted. Approved, and available for upgrading to, whenever whenevers (holiday hours for IPS so prob the new year sometime)

tldr; You can create and name the extension anything you like, just like any other extension. But if you want the extension to actually work, that name can only, exclusively, be "Main". If you name your file anything else for this extension, the extensions.json file will not have the entry added, and even if you add the entry manually to the json file, this will kick out Whoops class not found error as it is apparently not correctly set in the Application object or wherever. If you DO set your class name to Main when creating this extension, everything works as intended.
- Add extension for 3rd party app via dev center
- Give it a class name of Whatever (so Whatever.php in my app's extension dir)
- Edit file
- Class name in the auto-gen extension file is _Main, not _Whatever - doesn't matter what you enter, this will always auto-gen to _Main
- If you run the extension via the ACP - Members - Member View - download personal data button, nothing occurs, even when you correctly name the function to what you set it as in the dev center
- That's because the extensions.json data file entry for this extension is never added when you add this extension via the dev center when you name the class something other than Main
- If you manually enter your extension into the json file, clear caches to be safe, and then try again to use the extension via the ACP - Members - Member View - download personal data button...
Class 'IPS\core\extensions\core\MemberExportPersonalInformation\Whatever' not found So the json file is correctly being read to engage the extension but elsewhere it does not exist - perhaps/probably in the application obj itself.
If I DELETE the extension in the dev center, that DOES remove my-manually-added entry in the json file AND the extension PHP file itself - these would be my not-named Main entry and file.
I'd also note you have zero documentation on this extension in the Developers Documentation.
Solution: perk up this method so it correctly takes in the set-by-the-developer class name, or, if you are locking this down to just Main, note in dev documentation (once you create some...), though that would mean only a single one of these extensions per-application and I'm not sure if that's the best thing (just my two cents)

Heads up that 20.1.0 is inbound. Includes a non-fix to the upgrade routine (I have no idea why there is a version in the MP with an upgrade routine that was not in the final submitted version and I'm afraid to ask - water under the bridge - and I'm chalking it up to the weirdness involved in the approval process and MP early days and leaving well enough alone), preventive removal of hooks on the Support page as IPS has inbound changes there so upgrading to the new version of Invision Community should be no problem when that is released, and a little JS bonus for the System Overview widget: it now auto-updates the 15-5-1 load percentages every two seconds. If you enjoy staring at the dashboard be aware those live load updates will halt after five minutes, otherwise you could walk away from your desktop with this widget up on the dashboard and your session would never time out. That's no good.
Altogether this is just a minor update, not an entirely planned release, but the timing was right to push something out so here it is.

tldr; You can create and name the extension anything you like, just like any other extension. But if you want the extension to actually work, that name can only, exclusively, be "Main". If you name your file anything else for this extension, the extensions.json file will not have the entry added, and even if you add the entry manually to the json file, this will kick out Whoops class not found error as it is apparently not correctly set in the Application object or wherever. If you DO set your class name to Main when creating this extension, everything works as intended.
- Add extension for 3rd party app via dev center
- Give it a class name of Whatever (so Whatever.php in my app's extension dir)
- Edit file
- Class name in the auto-gen extension file is _Main, not _Whatever - doesn't matter what you enter, this will always auto-gen to _Main
- If you run the extension via the ACP - Members - Member View - download personal data button, nothing occurs, even when you correctly name the function to what you set it as in the dev center
- That's because the extensions.json data file entry for this extension is never added when you add this extension via the dev center when you name the class something other than Main
- If you manually enter your extension into the json file, clear caches to be safe, and then try again to use the extension via the ACP - Members - Member View - download personal data button...
Class 'IPS\core\extensions\core\MemberExportPersonalInformation\Whatever' not found So the json file is correctly being read to engage the extension but elsewhere it does not exist - perhaps/probably in the application obj itself.
If I DELETE the extension in the dev center, that DOES remove my-manually-added entry in the json file AND the extension PHP file itself - these would be my not-named Main entry and file.
I'd also note you have zero documentation on this extension in the Developers Documentation.
Solution: perk up this method so it correctly takes in the set-by-the-developer class name, or, if you are locking this down to just Main, note in dev documentation (once you create some...), though that would mean only a single one of these extensions per-application and I'm not sure if that's the best thing (just my two cents)

/** * Decode JSON * * @param bool $asArray Whether to decode as an array or not * @return array * @throws \RuntimeException * @li BAD_JSON */ public function decodeJson( $asArray=TRUE ) { $json = json_decode( $this->content, $asArray ); if ( $json === FALSE ) { throw new \RuntimeException('BAD_JSON'); } return $json; } You are testing for a return value of FALSE and that is not returned by PHP json_decode. If the content to be decoded cannot be decoded (malformed json, not json) that method returns null.
null is returned if the json cannot be decoded or if the encoded data is deeper than the nesting limit. If you would rather not swap that FALSE out for null, @Colonel_mortis suggests JSON_THROW_ON_ERROR flag in json_decode as work around.

I've raised your suggestion internally for further consideration.

The one place it matters right now: New Rest API keys. You check for cgi, and if it is running, you then flash this:
That took away a few minutes of my life and got me down this rabbit hole. My server (in question) does support auth headers so I had to actually check what the hell was happening, is there something wrong with my server, and etc., etc., but no, it is just that you don't bother to actually verify headers at all, you just check if cgi is running and then assume there are no Auth headers available, and push out that warning. A warning based on a guess. At a minimum changing that lang key to something more accurate such as "We detected PHP CGI and you might not have auth headers..."
Granted, for the IPS API stuff, if you have auth headers that work then that message is irrelevant - you aren't forcing it off in the authorizationHeader() method in \IPS\Request - so everything will still work, but again, you are already have code for checking headers right there, why not actually check for valid headers during the key setup method in the first place and have it be factually accurate instead of pushing out a guess?
As it stands now in your unreleased-to-the-masses Zapier integration, that cgi check is a flat out middle finger. Unless that changes, as currently coded, if you detect cgi you will not allow Zapier to be configured and used, whether I have valid headers or not.
The best outcome here is a validateAuthHeaders method that makes a curl call and then you can re-use \IPS\Request\authorizationHeader() to validate things are good to go.
If not, you might want to maybe alert the Invision Community self-hosted user base that there is a rather sticky server requirement for Zapier use. It's a derpy plugin to get around the testSettings() hitch in the Zapier integration for me but I'm struggling to see why I need to do this at all.

PHP 8.0.0 has been released. Some bugs that I've found in a couple of minutes of testing:
There are a bunch of deprecation warnings for required parameters following optional parameters - from my search with the regex function\s*\w+\s*\([^=)]*=[^)]*,\s*\$[^,)=]*[,)] there are 47 instances of this in the suite. It should be safe to remove all of the offending default parameters, since they can never be utilised. The cms lang key can_edit_item_message_record is invalid - it contains %S rather than %s, which causes the page to (randomly?) 500. Fatal error: Cannot make static method XMLReader::open() non static in class IPS\Xml\_XMLReader in .../system/Xml/XMLReader.php on line 34 (this might be a fun one to fix - it's a PHP 8 change that isn't compatible in either direction - https://www.php.net/manual/en/xmlreader.open.php#refsect1-xmlreader.open-changelog - you probably have to make a new method that delegates instead) TypeError: method_exists(): Argument #1 ($object_or_class) must be of type object|string, null given from statusContainer.phtml:133 (when viewing a feed containing status updates) PHP Fatal error:  Unparenthesized `a ? b : c ? d : e` is not supported. Use either `(a ? b : c) ? d : e` or `a ? b : (c ? d : e)` in .../applications/calendar/widgets/upcomingEvents.php on line 153 If I come across any more issues, I'll add them in this topic, and encourage others to do the same.

IPS has been mucking about with the meta tags and json output recently. If you want them to warn you this is happening prior to a release being released you'll need to poke the various parties responsible.
/* Wipe JsonLD for now until issues resolved */ \IPS\Output::i()->jsonLd = array(); That includes breadcrumbs. Sorry.

Waiting on approval, but here's a peak at the new Searchlight coming in SSSR 3

Now it's up.
Note, Gallery is exceptioned out so if a search result is a Gallery thing, Searchlight won't fire there (the page loads and THEN a popup fires with the image and comments and that's just confusing the hell out of everything right now) and those of you on Elastic Search with stemmed search results - meaning you searched for... I dunno... "baconese" and stemmed results give you some with just 'bacon' the results with just bacon might/probably are not highlighted yet. The new and improved Searchlight is doing exact term matching for the moment with markJS. 
We'll get there. This is one of those things I NEED for a site so expert more eventually.
Also, Searchlight is REALLY locked in on only firing when you come out of the search results page. The search terms are only placed into a Searchlight cookie when you click a search result. The longest that cookie will exist is seven seconds which is just a guess on what a crap site might take for loading a page. Regardless, the moment the page actually finishes loading, that cookie is wiped out after I grab the terms with Searchlight. Getting to the point, if you refresh a page that has Searchlight marks on it, they go away - there are no search terms for it to mark any more.
Lastly, this does not mark out hits in content titles anymore. Not much of a need to flag those out - your hit is right there in the title so... Always looked a little dumb anyways.

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.
 
 

Nope. Still version 2 in the MP.
It's kindof annoying right now in that when we submit a new file, if we edit the description to go along with it, the new description is there, but not the new screens or the new file. Those latter 2 don't show up until the new file is approved.
 

Just fyi this is finally, really done. Ran into some hitches with name spacing (don't ask...) and caught a few things on testing I figured I should just deal with now rather than post-release. That and the usual other work, other problems thing.
Approved when it is approved. There will be a new support topic as well. This topic remains for a brief time as support for the old plugin, which, yes, does work with 4.5, so it will remain "supported" but I will not be flagging it as officially compatible with 4.5. In fact, I had IPS go ahead and disable new purchases on the plugin itself as there was at least one purchase AFTER I stuck a bunch of text at the top of the MP listing saying don't do that as you would just be throwing money away.
Init release pretty much as stated in the previous post. The GDPR stuff will be "soon" but I'll probably push gallery and blogs support out first. The app is GDPR "safe" as nothing is saved when a member is deleted from your community, all the viewer information this app stored gets wiped when the member gets wiped, but full compliance - the ability for a member to grab a download of their stored views, that's yet to be done.
New application name is just "Viewers" btw.
 

Application done. Out of the gate it will be just forums, but blogs and gallery will be close behind after this breathes a bit out in the open - just want to make sure everything settles in for everyone before adding the rest.  
On installation, the new app will detect if you have the plugin installed, hump over your existing data, and then delete the plugin, so do not remove the plugin prior to installation of this new thing. You'll just wipe your existing data.
There are built in cull options now if you need to wipe a single topic's viewers out, or cull the whole thing and start over again (along with the usual truncate by x-amount-of-days daily task)
Want to spy? You can spy your members via the ACP member view page where I added a tab for Who Viewed. Naturally with just forums as the only app it's a little spartan but it is a start.
Those of you with GDPR or other jurisdictional fun to deal with, for now, no, you can't throw a member's views at them if they ask for it. But yes, it's an easy add to dump to CSV and on the list - will be fairly soon. 
All the usual clearing/merging of datas when a topic is deleted or a member is merged/deleted also occur.

All the rest of the newness will have to wait for the Marketplace entry. Gonna do a little testing first before submission.

That's because I'm a dumb-ass on occasion (I'll let everyone come up with their own time quantity for this particular trait. HINT: You are all probably right)
KS 1.1.1 submitted and requested for accelerated (instant) approval.
Apologies.

Application done. Out of the gate it will be just forums, but blogs and gallery will be close behind after this breathes a bit out in the open - just want to make sure everything settles in for everyone before adding the rest.  
On installation, the new app will detect if you have the plugin installed, hump over your existing data, and then delete the plugin, so do not remove the plugin prior to installation of this new thing. You'll just wipe your existing data.
There are built in cull options now if you need to wipe a single topic's viewers out, or cull the whole thing and start over again (along with the usual truncate by x-amount-of-days daily task)
Want to spy? You can spy your members via the ACP member view page where I added a tab for Who Viewed. Naturally with just forums as the only app it's a little spartan but it is a start.
Those of you with GDPR or other jurisdictional fun to deal with, for now, no, you can't throw a member's views at them if they ask for it. But yes, it's an easy add to dump to CSV and on the list - will be fairly soon. 
All the usual clearing/merging of datas when a topic is deleted or a member is merged/deleted also occur.

All the rest of the newness will have to wait for the Marketplace entry. Gonna do a little testing first before submission.

First, better as a separate mod, but easy to do.
Second, fits with KS, probably doable. You may wish to make a note in your terms of service or privacy note though about this that mods can see anon signed in users.

Already done. Will be in the next update.

FYI this was submitted last night. I'll post a changelog here when it gets approved.

FYI this was submitted last night. I'll post a changelog here when it gets approved.

All of one minute to do. If y'all want them consecutively numbered from 1+ per topic that will take a few additional minutes.
I'll pop this in with the other updates and submit it tonight. No guarantees if/when approved.