Jon Erickson

Awesome, thanks for the support.

Yes, you are correct.

No, you will need to create an actual API key using the instructions and replace APIKEY with it. This is why it is still Pending. Once you have the correct URL ie with the API key, the subscription will confirm itself.

AWS: 3.235.14 Guzzle: 7.5.0 Yeah, no problem. Looks like I need to examine another function argument. No problem. Will update soon.

Gotcha. Thanks for the insight.

We do set the ReplyTo. This is how we compose the payload sent to AWS. // Get from settings $fromName = $fromName ?? \IPS\Settings::i()->board_name; $fromEmail = $manager->getSendingEmailAddress($fromEmail) ?? \IPS\Settings::i()->email_out; // Compose the email payload $payload = [ 'Destination' => [ 'ToAddresses' => $toRecipients ], 'ReplyToAddresses' => [$fromEmail], 'Source' => static::encodeHeader($fromName, $fromEmail), 'Message' => [ 'Body' => [ 'Html' => [ 'Charset' => 'UTF-8', 'Data' => $this->compileContent('html', static::_getMemberFromRecipients($to)) ], 'Text' => [ 'Charset' => 'UTF-8', 'Data' => $this->compileContent('plaintext', static::_getMemberFromRecipients($to)) ], ], 'Subject' => [ 'Charset' => 'UTF-8', 'Data' => $this->compileSubject(static::_getMemberFromRecipients($to)), ], ], 'ConfigurationSet' => $configSet, ];

Hmm interesting. Will look into. Thanks for posting.

Have you confirmed your cron is running with PHP 7.4+? Most web hosting providers allow you to configure cron PHP version independently of your website PHP version. Sounds like your cron is executed using an old PHP version.

Experienced it as well.

Correct. That’s why I had him use my fix which just included sources/vendor to allow the rest of the sources folder to still be included.

I appreciate @Randy Calvert responses. They are exactly what I would have said. With that being said, we will await IPS’ response on where to place the vendor folder. It is currently in the sources folder as I was directed by @Daniel F to do so. I originally had it in the root application directory when I first released the application but it sounds like that wasn’t kosher.

system/Application/Scanner.php

Check my previous post for the update to fix it.

Looks like it was shipped with 4.7.3. Line 78 of Scanner.php: $excludeDirs = [ 'hooks', 'setup', 'dev', 'vendor' ]; HOWEVER, the patch, as it stands right now, will not work as the regex pattern is looking for a directory path of /\/var\/www\/html\/applications\/awsses\/(?:hooks|setup|dev|vendor)/ The vendor folder is located in the sources directory as required by IPS, not the root application folder. @Daniel F, do I move my vendor folder to the root directory or do you guys update the regex to look for the vendor folder in the sources directory? For the time being, you can edit line 78 of Scanner.php to the following to fix the issue. $excludeDirs = [ 'hooks', 'setup', 'dev', 'vendor', 'sources\/vendor' ];

Thanks for the support.

Seems like making it a background task would be helpful. Does it really run with every script execution when on the support page?

I completely agree. And I recognize this. But is it your responsibility to enforce this? Thank you for the cooperation.

It’s extremely easy to exclude the vendor directory. It’s the standard folder name for composer. I’m surprised they are even scanning it to begin with. It makes no sense to scan it because everything inside it is a 3rd party dependency (aka not the developers own work) so if a problem were to arise, they would have to approach the dependency author for a solution. Shouldn’t be IPS problem to ensure 3rd party dependency compliance.

How is excluding the vendor directory a bad solution? Composer is the industry standard and not supporting it, when you want active developer engagement to help grow your ecosystem blows my mind. IPS should not be responsible for ensuring php compatibility in 3rd party dependencies. There’s a reason composer has versioning and constraints. To make sure libraries are compatible with specific php versions. I should not be responsible for modifying someone else’s work to make it work with IPS. That’s backwards.

Gonna have to work with IPS to come up with a solution. At this point, there is nothing we can do to avoid the issue unfortunately - besides removing the dependencies we are using, which are needed to talk with AWS.

I finally recreated the issue in my local environment and received the following stack trace. Confirmed it is indeed attributed to the compatibility scanner and trying to scan the entire vendor/dependency folder. # Time Memory Function Location 1 0.0014 406056 {main}( ) .../index.php:0 2 0.1819 9685824 IPS\_Dispatcher->run( ) .../index.php:13 3 0.1820 9687328 IPS\core\modules\admin\support\_support->execute( ) .../Dispatcher.php:153 4 0.1820 9687328 IPS\Dispatcher\_Controller->execute( ) .../support.php:48 5 0.1820 9687328 IPS\core\modules\admin\support\_support->getBlock( ) .../Controller.php:107 6 0.1820 9687376 IPS\core\modules\admin\support\_support->_showBlockHookscanner( ) .../support.php:228 7 0.1845 9851896 IPS\Application\_Scanner::scanCustomizationIssues( $getDetails = FALSE, $shallowCheck = TRUE, $limit = 500, $options = ['shallowCheckEnabledOnly' => TRUE, 'enabledOnly' => FALSE] ) .../support.php:519 8 0.1983 9938336 IPS\Application\_Scanner::scanExtendedClasses( $getDetails = FALSE, $shallowCheck = TRUE, $limit = 500, $hardLimit = 5000, $options = ['shallowCheckEnabledOnly' => TRUE, 'enabledOnly' => FALSE] ) .../Scanner.php:786 9 21.4599 13207736 IPS\Application\_Scanner::getClassDetails( $scriptContents = '<?php\n// This file was auto-generated from sdk-root/src/data/apigateway/2015-07-09/api-2.json\nreturn [ \'version\' => \'2.0\', \'metadata\' => [ \'apiVersion\' => \'2015-07-09\', \'endpointPrefix\' => \'apigateway\', \'protocol\' => \'rest-json\', \'serviceFullName\' => \'Amazon API Gateway\', \'serviceId\' => \'API Gateway\', \'signatureVersion\' => \'v4\', \'uid\' => \'apigateway-2015-07-09\', ], \'operations\' => [ \'CreateApiKey\' => [ \'name\' => \'CreateApiKey\', \'http\' => [ \'method\' => \'POST\', \'requestUri\' => \'/apikeys\', \'responseCode\' => 20'... ) .../Scanner.php:175 Running into a max execution time.

Looks like we are gonna need to work together with Invision to fix this issue. Pretty sure the PHP 8 scanner is causing the issue. It’s unreasonable to not allow 3rd party applications to not include dependencies. With that being said, IPS dev team, how can we make sure the compatibility scanner avoids the vendor folder?

Correct. That’s what I’m thinking. Waiting for @Daniel F to answer.

I don’t think we’re dealing with a package size issue. People are able to install without issue. It’s only 30MB and this is due to needing to include the AWS SDK. No way around it without writing the library my self (which we know is against the point). Would your PHP scanner scan the entire vendor folder? This could be the reason for the hang. Interesting. This could be a plausible cause as this issue didn’t arise until the introduction of that scanner. And having it try to scanner an entire vendor folder could certainly cause a server to hang.

How are you linking it to the compatibility scanner? I wonder if the PHP 8 scanner is trying to scan the entire vendor folder.