All Astronauts

2 minutes ago, Adriano Faria said:

That’s because it is hardcoded in the template (txt)

🥺 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:

Quote

Your server does not support authentication headers. As you will need to pass the API key in the URL, we recommend you set up IP address restriction.

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.

We solved that above via PM. He was just a little confused as its an app and not a plugin, so whole new tab in the acp with the AA logo and such.

1.1.1 Released!

• Patches that stupid stupid log bug.
• Post numbers linked.

Not sure when your MP refreshes out (one could run the task manually I guess...) but when 1.1.1 shows up, upgrade.

If any of you need help clearing those log files out just shoot me a pm.

If it's only passing two variables I'd be looking for a REALLY out of date plugin. Like a year or two at least. That third var (out of four) is the post before registering flag and that's been a thing for awhile now.

Also, to be fair, there are occasions where something breaks and hooks are in the error stack but it's not actually the hook that's the problem. In this case though, yes, a function is expecting four variables and it's getting only two, so it breaks.

Can you PM me an ACP login (with your site name as well so I can get there) so I can take a peak? Should not be happening.

There were some changes we were forced to make (and then slightly rescinded but not yet fixed) with how 3rd-party devs include certain forms of resources in their apps. Long story short we had to stick them back into resources which might end up hosted off-site and depending upon your CDN and SSL cert settings and so on, would then get blocked. Or it might be something else, either way the code looks fine here but I'll need to peak really quick to see what's what.

4.5 only; most of the hook points have changed. I know lots of people have to delay 4.5 upgrade due to theme compatibilities and so on but it really is nicer on this side. 

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.

Actually,  you have to have a front end favicon set now for this to work, so check under the acp  customization tab and look for icons and... something  option and make sure one is set. On phone now so can't look myself