edwardspec / mediawiki-aws-s3

Extension:AWS allows MediaWiki to use Amazon S3 (instead of the local directory) to store images.
https://www.mediawiki.org/wiki/Extension:AWS
GNU General Public License v2.0
42 stars 32 forks source link

SocialProfile integration #69

Closed OAuthority closed 11 months ago

OAuthority commented 11 months ago

I'm potentially being stupid here, but I just wanted to get a few pointers about this. I'm using S3, with the basic settings:

'wgAWSRegion' => [
        'default' => 'eu-west-2'
    ],
    'wgAWSBucketDomain' => [
        'default' => 'static.domain.com'
    ],
    'wgAWSRepoHashLevels' => [
        'default' => 2
    ],
    'wgAWSRepoDeletedHashLevels' => [
        'default' => 3
    ],
    'wgAWSBucketName' => [
        'default' => 'static.domain.com'
    ],
    'wgAWSBucketTopSubdirectory' => [
        'default' => "/$wgDBname"
    ],
    'wgUploadBaseUrl' => [
        'default' => 'static.domain.com'
    ],

This is causing a few issues with SocialProfile, though, which is saving the images to the local disk instead of S3. If I enable SocialProfile, and set $wgSocialProfileFileBackend = 'AmazonS3'; which I believe is the name given for the LocalRepo, here, I get this error:

Found 1 error while validating the input provided for the ListObjects operation: [Bucket] is missing and is a required parameter

Potentially I'm missing some configuration? I think this is somewhat related to this task. Something was introduced in SocialProfile in this commit to assist with this. Do you have any idea what is potentially going wrong here? Is this an error on my end, with this extension, or with the SocialProfile extension?

edwardspec commented 11 months ago

Are there any clues in the debug log? (what bucket it is trying to use, what containers did it find, etc.)

$wgDebugLogGroups['FileOperation'] = '/path/to/some/writable/file.log';
OAuthority commented 11 months ago

Are there any clues in the debug log? (what bucket it is trying to use, what containers did it find, etc.)

$wgDebugLogGroups['FileOperation'] = '/path/to/some/writable/file.log';

The log shows:

2023-11-06 12:39:48 telepedia-wiki hijackwiki: S3FileBackend: found backend with S3 buckets: static.telepedia.net/hijackwiki, static.telepedia.net/hijackwiki/thumb, static.telepedia.net/hijackwiki/deleted, static.telepedia.net/hijackwiki/temp.
2023-11-06 12:39:48 telepedia-wiki hijackwiki: S3FileBackend: checking existence of directory  in S3 bucket [Null]
edwardspec commented 11 months ago

So the error is happening in findContainer() method. Let's check what parameter did it receive, and if containerPaths were correctly set...

In s3/AmazonS3FileBackend.php, immediately after the line

protected function findContainer( $container ) {

... can you please add the following code:

        $this->logger->debug(
            'S3FileBackend: DEBUG: in findContainer(): container={container}, paths={paths}',
            [
                'container' => $container,
                'paths' => FormatJson::encode( $this->containerPaths )
            ]
        );

It should tell us what we want to know.

OAuthority commented 11 months ago

The log indicates:

2023-11-06 14:09:33 telepedia-wiki hijackwiki: S3FileBackend: found backend with S3 buckets: static.telepedia.net/hijackwiki, static.telepedia.net/hijackwiki/thumb, static.telepedia.net/hijackwiki/deleted, static.telepedia.net/hijackwiki/temp.
2023-11-06 14:09:33 telepedia-wiki hijackwiki: S3FileBackend: DEBUG: in findContainer(): container=hijackwiki-avatars, paths={"hijackwiki-local-public":"static.telepedia.net/hijackwiki","hijackwiki-local-thumb":"static.telepedia.net/hijackwiki/thumb","hijackwiki-local-deleted":"static.telepedia.net/hijackwiki/deleted","hijackwiki-local-temp":"static.telepedia.net/hijackwiki/temp"}
2023-11-06 14:09:33 telepedia-wiki hijackwiki: S3FileBackend: checking existence of directory  in S3 bucket [Null]

I'll note that as per setting up SocialProfile, I manually created the folders that are required (avatars, awards), in S3 if that makes a difference? It does seem to be finding the "avatars" unless I'm miss-reading it?

edwardspec commented 11 months ago

Ok, hijackwiki-avatars isn't a standard container name, and that's why findContainer() can't find it.

Please try the following (in LocalSettings.php):

$wgAWSRepoZones['avatars'] = [
    'container' => 'avatars',
    'path' => '/hijackwiki/avatars',
    'isPublic' => true
];

... same for awards, etc.

OAuthority commented 11 months ago

I think thus is getting closer to the solution; that works, and it uploads to the bucket, but the file is such

https://static.telepedia.net/images/hijackwiki/avatars/hijackwiki_2_l.jpg?r=20231106150952

Whereas the actual bucket image is at: https://static.telepedia.net/hijackwiki/avatars/hijackwiki_2_l.jpg?r=20231106150952 Which is where the bucket is configured to upload (it uploads images here normally).

I tried this to see if it would make much difference, but sadly it did not, and the same behaviour applies:

    $wgAWSRepoZones["hijackwiki-avatars"] = [
        'container' => 'avatars',
        'path' => `$wgAWSBucketName/hijackwiki/avatars`,
        'isPublic' => true
    ];

Also, this seems to bring another set of issues, if I try to remove the avatar, or award, it says it has removed, but it doesn't delete it from the bucket, and as such, when I upload another image, it still shows the old image for some reason in the S3 bucket itself; relevant log for this seems to be:

hijackwiki: FileBackendStore::ingestFreshFileStats: File mwstore://AmazonS3/avatars/hijackwiki_2_s.png does not exist

Even though the file does actually exist at /avatars/hijackwiki_2_s.png unless this is the error about displaying it since its looking for /images/hijackwiki/avatars when it is actually located at /hijackwiki/avatars; even so, it doesn't seem to want to delete or overwrite the image in the bucket.

edwardspec commented 11 months ago

Extension:SocialProfile adds /images/ (unwanted part of the URL) in SocialProfileFileBackend::getDefaultUrlPath(). This value comes from $wgUploadPath.

OAuthority commented 11 months ago

Ah, that's perfect, it works now! Thank you for your assistance, and for this extension in general!