All Astronauts

I've always just created a new user group for this, plus group formatting for the user names. Since one is in the acp already changing the group, resetting the password is trivial. You appear to be needing / wanting more though

nor should you 🙂 Not a lot going on in that task, it just reads \IPS\Session\Store::i()->getOnlineUsers a few times and musses with an array or two before saving to settings a thing or two. PM me ACP access and I can peek at whats happening, I'll run it manually so I can see whats happening.

Good catch. I made a tiny copy/paste error. If I want to output any KS settings to be available for javascript purposes, I have to manually insert them into the output array, which is all well and good until you output the value of one setting for a different one. That's how things end up not working. Patched, submitted, 1.2.1

Be a bit more. Since it had been five days already I figured it was behind in the queue and asked for it to be pulled os I could re-submit with some more tweaks. Was just submitted again now. It was that or another derpy update immediately afterward and that seemed silly - both for end users and the reviewers. 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. UPDATE! Also improved the page numbering feature to work better with custom themes that have moved the .ipsComment_tools structure to the postContainer template instead of the post template Only new thing (minus the obligatory code tweaks here and there) is that last one. Unrelated note: Those of you using the Who Viewed the Topic plugin, the Viewers app should be submitted today. That will be the upgrade path for 4.5. The plugin works fine as-is now but will not be submitted to the new ACP MP so you are on your own there. It needed to get re-written to deal with GDPR and honestly, lots of other reasons.

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)

Quick sweep of that directory shows this file is the only one not using {class}

🥺 but at least an easy fix

I can make a vid if you like, but this is as straight-forward as it seems. Create new extension, name it something, nothing appears in json, doesn't work (obvs) Deleted. Tried again, this time with Main, worked. Did I try again a third time with a non-Main name or an entire new app after I deleted the original and tried again with Main? No. My luck this was a one-off Dev mode hitch... I'll poke it some more EDIT: No need for vid, you can replicate this yourself - this is still broken. I used an app that just had some widgets in it (testing app), and added a new memberExportwhatever extension not named Main ("Workdamnyou"). Added fine, json did NOT build out, the PHP file class is as stated before, _Main and not _Workdamnyou Ok, that's expected, so I added another one. It wanted nothing to do with it at all. In fact, it seemed to think the name I provided ("Jake") was actually Main, and since the previous created extension here got the name _Main, naturally that's a crash: Tis' bugged

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)

IPS asks us to use internal methods when possible. Decoding malformed/bad json with this method lets it through as "valid". Have I been directly impacted by this? Not much - I saw the problem and wrote around it - it's trivial code and a trivial fix (though expanding it with try catch and pushing out the actual JSON errors ala @Colonel_mortis 's suggestion is a better solution) As it stands now the fix for this method is just $json === FALSE >>> $json === null. I did a bit more myself. This ain't a big deal, but it is broken. A different/better/somewhat related question is whether apps with API structure are going to run into the same problem files in the interface directory have on the new CIC2 structure. You guys said interface is alright now but is the API directory also in the clear?

/** * 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.

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.

Granted, it does what it says, but the reality is you are mainly concerned with Authorization headers being sent and you are assuming if CGI then no auth headers. You may wish to start checking for valid auth headers instead - that can be dealt with with CGI implementations - both .htaccess and Nginx confs - it's only a rewrite rule for the most part, not that hard. It's a hard warning when setting up API keys now (telling admins to set an ip address to be safe), and a little digging shows that when you guys eventually go ahead and turn on Zapier integration for the masses it is going to tell CGI mode servers to get bent and I imagine there will be a non-trivial number of users who will be a little miffed when that's the first they learn of it.

The hard-coded manual bit for Stripe has been a part of how Commerce handles Stripe calls for a long time. No one else is (probably) having these problems - I'm not (granted an instance of one but I'm not seeing any other posts on the forums otherwise) - so something is going on that's likely particular to your instance. And manual here is just how they are handling it behind the scenes, I've not had any problems taking credit cards with Stripe via Commerce forever. https://stripe.com/docs/api/payment_intents/object#payment_intent_object-capture_method The language isn't quite the clearest in the world, but 'manual' here effectively means 'hold'. The Commerce Stripe method puts a 'hold' on the funds, albeit briefly, and then once other stuff happens (I assume on the IPS Commerce side, either directly in the method 'now' or via a queue task or something 'soon' - haven't looked...) it will capture the transaction, taking the funds and completing it. Mark could certainly explain this better but all signs point to you having something either off with your Stripe configuration or are you doing/have some custom thing going on? In Commerce Stripe is pretty much set it and forget it (and I say that as someone who set it up eons ago in the pre-4 days and I think I poked the Stripe bear (configuration/settings) once in all the years since. That or MaxMind/fraud rules are messing things up somewhere in the stack. Just spit-balling...

'manual' is hard-coded for capture_method for the Stripe method in Commerce. As you can imagine, you are hitting stuff most others with Stripe aren't I'd be sure to first look at the system and error logs in the Support area of the ACP just to see if there are any other errors being thrown that apply here. Probably spot nothing but a good place to start ruling other crap out.

Y'all know post numbering was included by request into Kitchen Sink. Someone asked for a few weeks ago. Took all of a few minutes to stick in.

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.

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.

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

On the fence? Best get in now... Slightly related: That's probably gonna get a bump for 4.5. IPS did knee-cap most of my new buys by building in search tracking, but mine is still more precise and detailed. I doubt that is enough to generate new sales though 😞 - anyways... if any of you search junkies are interested, post up there in the support topic as my gaze will likely be turning in that direction soon.

So what are you all thinking here? Things have calmed down enough for 4.5 upgrades on my end to swing back to this. On the one hand, I'm not all that incentivized to keep on with this as with IPS building it in sales are probably gonna be crap. On the other hand, it's already built out so. And on the third hand (be glad I'm not counting legs...), my tracking is still more detailed. I know you all will want, in general terms, the ability to not track tags, the ability to wipe out entries in the ledger based on term, based on ip address (enter term or ip address, remove all entries, that kind-of thing), I've had a widget or two on my list from the before time to do, plus this geo-thing... Floor is open.

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.

Shoot me a pm with a link to your site, optional acp access, this shouldn't be too hard to track down, and the community maps author is in my regular Slack pile if there is a direct conflict there we can hash it out.

That appears to be another third party plugin or something. That template does not appear in any IPS app or KS. Shoot me a pm with site name and acp access and I'll be glad to pop in and look though.