Martin A.

Same on my 4.7.3 B1 dev install, and our 4.7.2.1 install.

No, it was a pretty straight forward thing to add

The new version has been approved now 🙂

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

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).

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.

@CaliPilot What's the locale you use? de_DE?

I undid the change I made to @Kjell Iver Johansen's install yesterday and added some debugging to see what's going on. The emails came back this morning. No more than 3 at the same time, surely this can be fixed to send it daily instead.. if ( $daysLeft <= 7 ) { \IPS\Log::log( [ 'withBypass' => [ (new \IPS\DateTime)->diff( \IPS\DateTime::ts( strtotime( $response['expires'] ), TRUE ) ), (int) (new \IPS\DateTime)->diff( \IPS\DateTime::ts( strtotime( $response['expires'] ), TRUE ) )->format('%r%a'), ], 'withoutBypass' => [ (new \IPS\DateTime)->diff( \IPS\DateTime::ts( strtotime( $response['expires'] ) ) ), (int) (new \IPS\DateTime)->diff( \IPS\DateTime::ts( strtotime( $response['expires'] ) ) )->format('%r%a') ], 'response' => $response ], 'martinDebug' ); \IPS\core\AdminNotification::send( 'core', 'License', 'expireSoon', FALSE ); } array ( 'withBypass' => array ( 0 => DateInterval::__set_state(array( 'y' => 0, 'm' => 1, 'd' => 18, 'h' => 23, 'i' => 37, 's' => 58, 'f' => 0.948895, 'weekday' => 0, 'weekday_behavior' => 0, 'first_last_day_of' => 0, 'invert' => 0, 'days' => 48, 'special_type' => 0, 'special_amount' => 0, 'have_weekday_relative' => 0, 'have_special_relative' => 0, )), 1 => 48, ), 'withoutBypass' => array ( 0 => DateInterval::__set_state(array( 'y' => -1, 'm' => 10, 'd' => 11, 'h' => 0, 'i' => 22, 's' => 1, 'f' => 0.051112, 'weekday' => 0, 'weekday_behavior' => 0, 'first_last_day_of' => 0, 'invert' => 1, 'days' => 48, 'special_type' => 0, 'special_amount' => 0, 'have_weekday_relative' => 0, 'have_special_relative' => 0, )), 1 => -48, ), 'response' => array ( 'active' => true, 'cloud' => false, 'expires' => '2022-10-28 07:00:00', 'products' => array ( 'gallery' => true, 'cms' => true, 'forums' => true, 'calendar' => true, 'spam' => true, ), 'chat_limit' => 5, 'support' => 'Standard', 'legacy' => false, 'plan' => NULL, ), ) As you can see, -48 days since it expired when you don't bypass timezones. You are comparing a unix timestamp with another unix timestamp, so you shouldn't adjust for timezones anyway.

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)

You mean to not show the club when viewing the main map, just when viewing the map on the club page? Must be a cache issue. I can see that club location on the main map.

Linux returns a similar error.

Not easy to say without seeing your C# code. Remember that when using a REST API key the auth is done using basic "user:password" authentication on the HTTP request. You can also add the key to the URL using "?key=<key>". (Based on the docs, I have never used the API system myself)

That's gonna be difficult.

Yeah... That sucks.

I'll take this back after having read some support topics. Looks like a lot of apps are throwing errors because of this new scanner. If you can you should setup a test forum where you install these apps and then perform an upgrade on that. Don't need to create a mirror of your live site, just a default install with all your apps and plugins.

Just remembered the board I recently saw who upgraded went from 4.6 to 4.7.1. The issues he had was both PHP8 and 4.7 related. If you're on 4.7 and PHP8 now it might be just fine.

Yeah, there's a new scanner tool in 4.7.2 that will ensure your apps and plugins wont break your community. (Although the error it reported for Community Map won't do that) But be prepared that quite a few of your apps will be disabled when upgrading.

Submitted an update for this now.

Have you applied the patch they released on Monday? That is supposed to fix that error.

If you know the ID of each CSS file you can do this {{$key = 10;}} {{$css = NULL; try { $css = (string) \IPS\File::get( 'cms_Pages', \IPS\cms\Templates::load( $key )->_file_object )->url; } catch ( \Exception ) {} }} {{if $css !== NULL}} {{\IPS\Output::i()->cssFiles[] = $css;}} {{endif}} If you want to load them by filename and group you'd have to either query for it, or hook into \IPS\cms\Templates and create your own helper method. load() will only accept template_id or template_key, but template_key also contains the id.

But are all those galleries enabled in the Community Map settings?

Have you enabled all gallery categories that should be shown? I just did a test on 4.7.1, and it properly shows me the image on the map.