Spaces-API PHP only works with us-east-1: SpaceDoesntExistException in other regions

TL;DR: if SociallyDev/Spaces-API v3.5.0 throws SpaceDoesntExistException for buckets in any region except us-east-1 (e.g. a bucket in sfo2 reports Space 'assets-storage' does not exist), the constructor accepts a region argument but the Spaces class hardcoded us-east-1 when instantiating the underlying S3 client, so the endpoint URL and the client region disagreed. Until it is fixed upstream, patch the hardcoded region in the S3 client instantiation to your region (e.g. sfo2) and construct with the region argument and a space name that exists there. The reporter confirmed this fixed sfo2 access.

SpaceDoesntExistException: Space 'assets-storage' does not exist

Steps

1. Patch the hardcoded us-east-1 in the Spaces class's S3 client instantiation to your region.
2. Construct with the region and an existing space name in that region.

3. Retry the operation.

   Expected: the bucket resolves. Success check: reads/writes work in sfo2 (or your region).

When to use this

• Spaces-API v3.5.0, non-us-east-1 region, bucket exists but reports missing.

When NOT to use this

• The bucket genuinely does not exist; check the name.
• us-east-1 works and you can use it; no patch needed.

Compatibility

• SociallyDev/Spaces-API v3.5.0; the maintainer acknowledged the bug and invited a PR.

Variant phrasings

• "spaces-api SpaceDoesntExistException region"
• "digitalocean spaces php wrong region"

Root cause

The region argument fed the endpoint URL but the S3 client itself was hardcoded to us-east-1, so lookups ran against the wrong region.

Edge cases

• Keep the patch minimal so you can drop it when upstream fixes it.

In the thread Spaces-API PHP only works with us-east-1: SpaceDoesntExistException in other regions, the question was: With SociallyDev/Spaces-API v3.5.0, connecting to any DigitalOcean Spaces region except us-east-1 failed with SpaceDoesntExistException even though the space existed: e.g. a bucket in sfo2 threw Space 'assets-storage' does not exist. The constructor accepts a region argument, but the Spaces class hardcoded us-east-1 when instantiating the underlying S3 client, so the endpoint URL and the client region disagreed and the bucket lookup ran against the wrong region. The verified resolution: The region passed to the Spaces constructor was used for the endpoint URL but the S3 client itself was hardcoded to us-east-1, so non-us-east-1 spaces could never be found. The maintainer acknowledged the bug and invited a PR. Until it is fixed upstream, patch the hardcoded region in SpacesAPI/Spaces.php (or the S3 client instantiation it performs) to your region, e.g. sfo2, and construct with new Spaces($key, $secret, $region) using a space name that exists in that region. The reporter confirmed this fixed their sfo2 bucket access. Original discussion: https://vectle.com/threads/thr_MdlmZLkYhsJl6CP8amiplQ