Confirm by changing [ ] to [x] below to ensure that it's a bug:
Describe the bug
The zip file version of the SDK includes an aws-autoloader.php file that has incorrect class paths for the Symfony\Polyfill entries. They include Symfony\Polyfill\IntlIdn\... at their beginning, but in the referenced files the namespace and use statements all use Symfony\Polyfill\Intl\Idn\.... The difference being IntlIdn in the autoloader should be Intl\Idn as per the source files.
Those aws-autoloader.php entries look like the following...
'Symfony\Polyfill\IntlIdn\Resources\unidata\virama' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/virama.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\deviation' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/deviation.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\disallowed_STD3_valid' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/disallowed_STD3_valid.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\disallowed_STD3_mapped' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/disallowed_STD3_mapped.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\Regex' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/Regex.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\ignored' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/ignored.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\disallowed' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/disallowed.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\mapped' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/mapped.php',
'Symfony\Polyfill\IntlIdn\Resources\unidata\DisallowedRanges' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Resources/unidata/DisallowedRanges.php',
'Symfony\Polyfill\IntlIdn\bootstrap' => __DIR__ . '/Symfony/Polyfill/IntlIdn/bootstrap.php',
'Symfony\Polyfill\IntlIdn\Info' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Info.php',
'Symfony\Polyfill\IntlIdn\Idn' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Idn.php',
Taking the last example from the aws-autoloader.php data above...
'Symfony\Polyfill\IntlIdn\Idn' => __DIR__ . '/Symfony/Polyfill/IntlIdn/Idn.php',
The top of the referenced file is like follows...
namespace Symfony\Polyfill\Intl\Idn;
use Exception;
use Normalizer;
use Symfony\Polyfill\Intl\Idn\Resources\unidata\DisallowedRanges;
use Symfony\Polyfill\Intl\Idn\Resources\unidata\Regex;
This causes problems when the polyfill functions such as idn_to_utf8 from the Symfony/Polyfill/IntlIdn/bootstrap.php file are used as the code within Fatal Errors due to not being able to find the Symfony\Polyfill\Intl\Idn\Idn class, because Symfony\Polyfill\IntlIdn\Idn was used in the autoloader.
Version of AWS SDK for PHP?
Seen in: v3.150.1 + v3.151.3 + v3.151.4
Aws\Sdk::VERSION in your code composer show -i Version of PHP (php -v)?
Various across many sites, but one for sure is 7.4.8.
To Reproduce (observed behavior)
Steps to reproduce the behavior (please share code or minimal repo)
This is happening on WordPress sites that do not have the intl PHP package enabled, but are using plugins such as AMP along with WP Offload Media.
Expected behavior
A clear and concise description of what you expected to happen.
No failure to autoload the Polyfill classes when intl PHP package not enabled.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Any additional information relevant to the issue. Examples include any framework you may be using (e.g. Laravel, Wordpress) in conjunction with the AWS SDK for PHP, or PHP/environment config settings if the issue is related to memory or performance.
We are embedding the AWS PHP SDK inside the WP Offload Media WordPress plugin, and do use PHP Scoper to add an extra prefix. However, it does not alter the segments from the aws-autoloader.php I referenced, and the examples I showed above are straight from the downloaded aws.zip file, untouched by our own packaging.
Hi @ianmjones,
I apologize for the long delay in response time. Just wanted to update you to let you know that I was able to replicate the issue and am looking into it now
Hi again @ianmjones ,
We just merged the PR that should fix this issue, please let us know if you continue to experience it, or if you have any further questions
-Sam