A developer will commonly need the "full path" of an asset, relative to an aws-s3 bucket.
If the Volume is aws-s3 or google-cloud, craft\elements\Asset::getPath is not sufficient, as those Volume types can have a subfolder.
This should be provided by Craft and not those Volumes specifically, as there are multiple Volumes with a similar subfolder prop.
It may be arguable that getPath should return this full path to begin with, but I'm guessing that would break a lot of other things.
The "full/bucket path" would be needed any time a dev interacts with, e.g. the S3 SDK.
craft\awss3\Plugin does this very thing, here: https://github.com/craftcms/aws-s3/blob/master/src/Plugin.php#L59
Another example in the wild: https://github.com/nystudio107/craft-imageoptimize/blob/v1/src/imagetransforms/ImageTransform.php#L102-L114
@andris-sevcenko I could see us adding a getRootPath() method to the VolumeInterface, with craft\base\Volume providing a default implementation that just returns ''. And then both the S3 and GC plugins could just rename their private _subfolder() methods to public getRootPath().
Then craft\element\Asset could gain a new getFullPath() method:
public function getFullPath(): string
{
return $this->getVolume()->getRootPath() . $this->getPath();
}
Thoughts?
Most helpful comment
@andris-sevcenko I could see us adding a
getRootPath()method to the VolumeInterface, withcraft\base\Volumeproviding a default implementation that just returns''. And then both the S3 and GC plugins could just rename their private_subfolder()methods to publicgetRootPath().Then
craft\element\Assetcould gain a newgetFullPath()method:Thoughts?