Dll

Removing and reinstalling is the only way I have been able to get it going again after an update. It's fine in 4.7.6 beyond that though, as far as I can see. 

On 1/17/2023 at 7:18 PM, Mark H said:

Just a note for the time being...

One thing self-hosted folks can do is to block the IP range of the spammer(s) using 109.107.166.230, but that needs to be done in the server firewall.

This would be the range to block for that service provider, in CIDR format:

109.107.160.0/19

which blocks 109.107.160.0 through 109.107.191.255

And for that spammer in Iraq... that provider has a huge range of IP's, from 37.236.0.0 to 37.239.255.255 so I personally blocked a fairly small range for them which encompasses the one IP that spammer used:

37.239.8.1/24

(Note: I've added these on my own server already, and it appears I got to it before my sites were hit.)

More blocks can be added as you notice them, but try to keep the ranges small. Blocking a too-large range can cause server issues under the right (wrong?) circumstances.

I'm kinda surprised that this doesn't appear to have been actioned on the Invision cloud - as we had a spammer within the russian range above get through onto a user account this morning?

Some really odd stuff goes on with this app on CiC. Whenever there's a new IPS version, it stops working (no emails logged whatsoever and all emails are sent the standard way), and the only way to get it to work again is to uninstall and reinstall it from the marketplace. But, on many occasions that's not possible due to this:

Quote

4C133/6 We could not parse the application.json file for this application because it is missing or corrupt. Please contact the author for an updated copy of this application.

51 minutes ago, marklcfc said:

It could be an option but don't fancy doing that each time, plus in general I wouldn't want my site to be 10-15 minutes behind for guests even during normal periods.

Think you're going to need to compromise somewhere. Either by spending more with either more server power/load balancing or with cloudflare so you can change the cache time to something more acceptable for you.

Or, you're going to have to accept the default cache time or the fact your site is going to crash when it's busy.

Alternatively I suppose you could wait for Leicester to get relegated at the end of the season, then I imagine those busy times may get less frequent 😅

Then as has been mentioned above, perhaps it's time for you to upgrade to load balanced servers. 

Personally though, I'd recommend testing it with the caching switched on for a period of time and see how your users find it. Ultimately, it's a forum not a chat room and so people tend to read more than just the very latest posts.

You can change it in clouudflare if you must. But, unless you have a specific reason to not have it set to that, other than thinking it's too long, perhaps just try it and see how it goes. In our experience it's been fine and no user has complained.

It does update, it just caches for 5-15 minutes. 

I think all it is that the emojis show capitalised and non-capitalised versions. 

He's posting a screenshot from this site @Marc Stridgen - so I think the bugs may still be there in this version. 

I don't know if this is a setting you can change, but it's looking for Amazon..co.uk - note the two dots rather than one. Changing that will probably fix it.

It was fine before, but honestly I just noticed it stopped showing, so don't know when it last worked. Sorry!

We're not seeing the ignore button here either (using cic), and tested on the default theme. 

1 hour ago, Marc Stridgen said:

Just taking a look there. Reports dont actually have push notifications

You're right, sorry. I was looking at the auto moderation notification settings.

47 minutes ago, Marc Stridgen said:

Are you getting push notifications for other items?

Yep

Just for info, although the email notifications are working fine since the patch, push notifications don't seem to be.

Thanks for sorting this. Merry Christmas 🎄

That's quite disappointing to be honest. The December release was supposed to be a minor maintenance update with it being year end / Xmas etc. So to introduce a fairly significant bug with it and then leave it in place over a month isn't ideal.

Is there no patch available for this as yet? It's hurting our work flow and having notifications of new reports is even more important for us over the Christmas period.

Just now, Daniel F said:

My app includes indeed guzzle too.

                "guzzlehttp/guzzle": "~5.3.3||~6.0||~7.0",
                "guzzlehttp/psr7": "^1.8.4||^2.2.1",

 

Once SEO essentials is disabled it works? 
 

It works if SEO essentials is uninstalled, but keeps failing if it's installed and disabled. 

One thing though, it doesn't work well if you have @Daniel F's SEO essentials installed as well. I know it's not strictly a bug or issue with either application, but thought it would be useful to know, as right now it's a case of having one or the other installed. 

This is the error if you try to send an email with the SEO application installed. 

Quote

Error: Undefined constant GuzzleHttp\Client::VERSION (0)
#0 /var/www/sharedresources/awssdk/Aws/Handler/GuzzleV6/GuzzleHandler.php(40): GuzzleHttp\default_user_agent()
#1 /var/www/sharedresources/awssdk/Aws/WrappedHttpHandler.php(87): Aws\Handler\GuzzleV6\GuzzleHandler->__invoke(Object(GuzzleHttp\Psr7\Request), Array)
#2 /var/www/sharedresources/awssdk/Aws/ClientSideMonitoring/AbstractMonitoringMiddleware.php(126): Aws\WrappedHttpHandler->__invoke(Object(Aws\Command), Object(GuzzleHttp\Psr7\Request))
#3 /var/www/sharedresources/awssdk/Aws/Middleware.php(126): Aws\ClientSideMonitoring\AbstractMonitoringMiddleware->__invoke(Object(Aws\Command), Object(GuzzleHttp\Psr7\Request))
#4 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/FulfilledPromise.php(41): Aws\Middleware::Aws\{closure}(Object(Aws\Credentials\Credentials))
#5 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/TaskQueue.php(48): GuzzleHttp\Promise\FulfilledPromise::GuzzleHttp\Promise\{closure}()
#6 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/Promise.php(248): GuzzleHttp\Promise\TaskQueue->run(true)
#7 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/Promise.php(224): GuzzleHttp\Promise\Promise->invokeWaitFn()
#8 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/Promise.php(269): GuzzleHttp\Promise\Promise->waitIfPending()
#9 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/Promise.php(226): GuzzleHttp\Promise\Promise->invokeWaitList()
#10 /var/www/sitefiles/d321955/applications/seoessentials/sources/vendor/guzzlehttp/promises/src/Promise.php(62): GuzzleHttp\Promise\Promise->waitIfPending()
#11 /var/www/sharedresources/awssdk/Aws/AwsClientTrait.php(58): GuzzleHttp\Promise\Promise->wait()
#12 /var/www/sharedresources/awssdk/Aws/AwsClientTrait.php(86): Aws\AwsClient->execute(Object(Aws\Command))
#13 /var/www/sitefiles/d321955/applications/awsses/sources/Outgoing/SES.php(44): Aws\AwsClient->__call('sendEmail', Array)
#14 /var/www/html/107503/applications/core/modules/admin/settings/email.php(189): IPS\awsses\Outgoing\_SES->_send('xxx@xxx...', Array, Array, 'xx@xx...')
#15 /var/www/html/107503/system/Dispatcher/Controller.php(118): IPS\core\modules\admin\settings\_email->manage()
#16 /var/www/html/107503/applications/core/modules/admin/settings/email.php(38): IPS\Dispatcher\_Controller->execute()
#17 /var/www/html/107503/system/Dispatcher/Dispatcher.php(153): IPS\core\modules\admin\settings\_email->execute()
#18 /var/www/html/107503/admin/index.php(13): IPS\_Dispatcher->run()
#19 {main}

Quote

#0 /var/www/html/107503/init.php(1029): IPS\_Log::log('Error: Undefine...', 'uncaught_except...')
#1 [internal function]: IPS\IPS::exceptionHandler(Object(Error))
#2 {main}

Actually, I think we're good - we were using smtp credentials rather than the correct user key etc. Seems ok now, I think. 

This just doesn't appear to work at all for us on 4.7.5, just throws this error on every attempt to send email. 

Quote

The request signature we calculated does not match the signature you provided. Check your AWS Secret Access Key and signing method. Consult the service documentation for details.
 

We've double (and triple) checked the key, permissions etc, made new IAM users etc etc. But, the result is always the same. 

Apologies, I misunderstood. 

You've got them all selected in that screenshot, do a ctrl+click on the ones you don't want to send a notification for. 

I think we have the same issue on our community. Don't think I've seen any emailed notifications for reports since 4.7.5