Martin A.

latest upgrade and for me this is still an issue
3-4 seconds without own suggested edit, normal speed with edit
 
 
 

I just thought i would update this in case anyone else needs it. I finally got it.
This is to get OAuth2:
// This part, you are just sending the user to the Login page. public void LoginTest1() { string MyClientID = "1234"; string MyRandomNumber = "4321";// <-- This is your own made up code, you will use this //again, make it anything you want. it gets sent back to you again to let you know it was a secure connection string MyRedirectURI = "https://MySite.com/URIPage/";// <-- This i made a custom page with an input field and make it //capture the code from the URL. string MyScope = "Files?"; string uri = "https://MySite.com/oauth/authorize?client_id="+MyClientID+"&response_type=code&state="+MyRandomNumber+"&redirect_uri="+MyRediectURI+"&scope="+MyScope+""; // <-- I has to put quotes at the end. Dont know why.. Application.OpenURL (uri); } // once they login, the "Code" will be displayed in the URL of "https://MySite.com/URIPage/" you will see a code, and the random number you made. // you will need to make a way for them to enter this into your app. private IEnumerator GetAccessToken() { Dictionary<string, string> content = new Dictionary<string, string>(); content.Add("grant_type", "authorization_code"); content.Add("code", RequestToken); // <-- I used a variable for this, but your "Code" in the URL goes here. content.Add("redirect_uri", "https://MySite.com/URIPage/"; content.Add("client_id", "123456789"); content.Add("code_verifier", "432151");// <-- This is the random code you made up at the very start UnityWebRequest www = UnityWebRequest.Post("https://MySite.com/oauth/token/", content); yield return www.Send(); if (!www.isNetworkError) { string resultContent = www.downloadHandler.text; Debug.Log("Response: "+resultContent); <-- This will show you your Token you are looking for. :) } else { // This needs to show an error, saying something went wrong. Found i had a disabled scope. } } else { Debug.Log("Failed: "+www.error);// <-- displayes the error, if you have any. :) } }  


This is to get information:
public void CallForSomething(uri) { string Bearer = "1234567890";// <- Your Bearer ID var httpRequest = (HttpWebRequest)WebRequest.Create(uri); httpRequest.Headers["Authorization"] = "Bearer "+Bearer; HttpWebResponse httpResponse; try { httpResponse = (HttpWebResponse)httpRequest.GetResponse(); } catch (WebException ex) { httpResponse = (HttpWebResponse)ex.Response; } using (var streamReader = new StreamReader(httpResponse.GetResponseStream())) { var result = streamReader.ReadToEnd(); string FullTXT = result.Replace(@"\", string.Empty); Debug.Log(FullTXT); // <-- This is what comes back :) } }  

+1
The more cloud information is shown, the more negative I am about it. I'm quite an advanced user - I know the solution and have the confidence that I won't migrate to the cloud. And if, by some miracle, I want to (e.g., as part of another project), I will definitely keep it in mind.

Thanks!
This is a PHP bug that's fixed in 8.1.10 - https://bugs.php.net/bug.php?id=81263

4.7.2 did not solve this particular issue btw, this topic shouldn't be marked as solved.

public static function roundedDiffFromSeconds( $seconds, $memberOrLanguage=NULL ) { $now = static::ts( time() ); $then = static::ts( time() - $seconds ); return $now->roundedDiff( $then, $memberOrLanguage ); } Don't panic! This is not related to all the other DateTime shenanigans going on. Just a small bug with a big return - routinely 52 years.
The problem is having $then calculated as time() - $seconds. That needs to just be seconds:
$then = static::ts($seconds);
You only use this in one spot (admin\stats\timeToSolved.phtml) that I can see so probably just been overlooked for a while.
Full Explained working on something not quite two minutes old:
$now: 1663390800
$then:  1663390800 - 1663390700 = 100
$now->roundedDiff ($then);
roundedDiff then immediately calculates its own difference:
$this->diff($date) which in this case is $this->diff(100) which is the difference between right now and 100 seconds after January 1, 1970 midnight UTC.
 

Hi all,
We've been working on fine-tuning the PHP8 compatibility scanner to ignore technically incorrect things, but they are still allowed with PHP 8.0 and 8.1.

Please see this post for details: 
 
 

@Matt, half of the resources I had to update since yesterday had a different parameter name in a Rest API method:
protected function _createOrUpdate( \IPS\node\Model $category ) I had to change it to:
protected function _createOrUpdate( \IPS\node\Model $node ) because of \IPS\Node\Api\NodeController.
---------------------
EDIT:
Another example:
public function saveForm( $val ) and:
public function saveForm( $values )  
Is that REALLY necessary?

This information should have been in the «blue banner» on top of our sites? 
We really need to be active on here to learn stuff like this - about a minor upgrade…

https://invisioncommunity.com/forums/forum/519-announcements/

https://invisioncommunity.com/forums/forum/519-announcements/

Already tested, works. Awesome job! 
Regards and thank you very much!
 
Chris

The new version has been approved now 🙂

The devil is in the detail, as is said.  The detail, however was assumed that everyone was on board and up-to-date.  I would still have liked to have seen a warning about third party apps possibly being locked 'before' the upgrade began.  It does this with themes where you either proceed or cancel the upgrade.  Running a scan after the fact is assuming a lot from people.
I agree wholeheartedly that if your site is mission critical then you should test 'every' update, not just this one, before proceeding to save yourself a lot of heartache.
As far as information, blogs, etc, not everyone reads them, especially if they are aimed at devs.  Even a post telling people be warned that some/all of your apps will be locked, so check with the devs to make sure they are up-to-date.
I would even go as far as flagging all apps in the marketplace to show that they are compatible with 4.7.2 because the 4.7 compatible flag may not always be correct, as witness in my own case where the apps are still purchasable, but will not work in 4.7.2 at this point in time. 
There's a lot more that could have been done to inform people of the pitfalls in an unmistakeable way - a pre-upgrade warning would have put me off upgrading until I was sure that everything would work, I never dreamed that some of the apps I use would be locked.
There are plusses and minuses in all of this; the good, the bad and the ugly if you wish lol.
As I mentioned it's no big deal to me, because I'm just a hobbyist, but someone else may have an even bigger headache to contend with.  Fair play to IPS for moving things forward and creating a great environment for us all to play and work with, but information is thin on the ground and I believe that is the one weakness that needs addressing 🙂
 

Just a very quick update before I sign off for the evening.  @Adriano Faria has pulled it out of the bag and the app that I use that is crucial to my site's existence has been swiftly approved in the Marketplace and my site is back up and running now.  So, a huge thankyou to @Adriano Faria and a big thank you to IPS for expediting the approval of the app.
I would point out one small thing to anyone who has a similar experience, once you update you have to 'enable' the app in the applications section of the ACP as it is not automatically enabled.  The locked status is no longer present.
Hope that helps 🙂
 

https://invisioncommunity.com/forums/forum/519-announcements/

The issue we had with the online indicator (which was the exact same DateTime::diff issue as this) occurred mid July. I don't remember which PHP version we were at at the time. 
We're now using 8.1.10, although that installation have not had the issue with the license expiry emails (yet).

It's related to a bug in how PHP 8.1 handles timezones. The same bug is also causing the issue with the constant license expire emails some people are receiving:
 

You mean when they load that page they'll get to one that looks like this?
https://www.walkingfootball.com/communitymap/?group=Club Locations
I've identified the issue. Will put up a fix for this shortly.
EDIT: New version is pending approval now.

The license calculation seems to be faulty on the server side. I also see this all the time on multiple installations:

Very likely related. 

This looks like it's the funny issue I encountered with DateTime::diff() when timezones aren't bypassed in DateTime::ts().
When the diff is 1 day 30 minutes for instance, it would return -1 year, +11 months, +29 days, +23 hours, +30 minutes.
This issue caused the online indicator on our site to stop function, as the diff wasn't "just 15 minutes". $diff->y would for instance not be TRUE ,as it's -1.
Fixed that issue by changing this in Member::isOnline()
$diff = \IPS\DateTime::ts( $this->last_activity, TRUE )->diff( \IPS\DateTime::create() ); Wonder is this is just an issue for those in a + timezone (only speculations)

This looks like it's the funny issue I encountered with DateTime::diff() when timezones aren't bypassed in DateTime::ts().
When the diff is 1 day 30 minutes for instance, it would return -1 year, +11 months, +29 days, +23 hours, +30 minutes.
This issue caused the online indicator on our site to stop function, as the diff wasn't "just 15 minutes". $diff->y would for instance not be TRUE ,as it's -1.
Fixed that issue by changing this in Member::isOnline()
$diff = \IPS\DateTime::ts( $this->last_activity, TRUE )->diff( \IPS\DateTime::create() ); Wonder is this is just an issue for those in a + timezone (only speculations)

This looks like it's the funny issue I encountered with DateTime::diff() when timezones aren't bypassed in DateTime::ts().
When the diff is 1 day 30 minutes for instance, it would return -1 year, +11 months, +29 days, +23 hours, +30 minutes.
This issue caused the online indicator on our site to stop function, as the diff wasn't "just 15 minutes". $diff->y would for instance not be TRUE ,as it's -1.
Fixed that issue by changing this in Member::isOnline()
$diff = \IPS\DateTime::ts( $this->last_activity, TRUE )->diff( \IPS\DateTime::create() ); Wonder is this is just an issue for those in a + timezone (only speculations)

This looks like it's the funny issue I encountered with DateTime::diff() when timezones aren't bypassed in DateTime::ts().
When the diff is 1 day 30 minutes for instance, it would return -1 year, +11 months, +29 days, +23 hours, +30 minutes.
This issue caused the online indicator on our site to stop function, as the diff wasn't "just 15 minutes". $diff->y would for instance not be TRUE ,as it's -1.
Fixed that issue by changing this in Member::isOnline()
$diff = \IPS\DateTime::ts( $this->last_activity, TRUE )->diff( \IPS\DateTime::create() ); Wonder is this is just an issue for those in a + timezone (only speculations)