The file/ (should it better be in public/?) folder's location is /var/www/social/file/ and so is it configured in the panel/paths administration page.
But I'm getting 404 on every thumbnail. Can you please elaborate the documentation on how to enable this feature? Thank you.
I'm using the latest ```master``` branch with NGINX and PHP-FPM. I tried to configure x-static-delivery, so I added the following in my configuration file:
```php
$config['site']['x-static-delivery'] = 'X-Accel-Redirect';
```
After that I ran the ```checkschema.php``` script, then modified my NGINX configuration, adding the following:
```nginx
location /file {
internal;
root /var/www/social/;
}
```
The ```file/``` (should it better be in ```public/```?) folder's location is ```/var/www/social/file/``` and so is it configured in the ```panel/paths``` administration page.
But I'm getting 404 on every thumbnail. Can you please elaborate the documentation on how to enable this feature? Thank you.
That's rather interesting. As far as I can tell, that config seems correct. What commit are you on? Do you have any log messages? Is the nginx config block above other blocks? Maybe some regex is conflicting (specifically the location / block).
That's rather interesting. As far as I can tell, that config seems correct. What commit are you on? Do you have any log messages? Is the nginx config block _above_ other blocks? Maybe some regex is conflicting (specifically the `location /` block).
Does the 404 appear when you post a notice with an attachment locally? Can you turn debugging on in the config and see if there's anything in the logs? When you post an attachment, you should get a link to it, with an ID in the end; could you check the database entries in the file and file_thumbnail tables for that ID?
The file folder is not supposed to be inside public, the point is that the webserver doesn't serve the files directly. In the nginx log you posted the error was when accessing the file directly, it seems. How did that request happen? Did the link appear somewhere on the page? Do you have extra plugins enabled?
Does the 404 appear when you post a notice with an attachment locally? Can you turn debugging on in the config and see if there's anything in the logs? When you post an attachment, you should get a link to it, with an ID in the end; could you check the database entries in the `file` and `file_thumbnail` tables for that ID?
The `file` folder is not supposed to be inside `public`, the point is that the webserver doesn't serve the files directly. In the nginx log you posted the error was when accessing the file directly, it seems. How did that request happen? Did the link appear somewhere on the page? Do you have extra plugins enabled?
The `file/` (should it better be in `public/`?) folder's location is
`/var/www/social/file/` and so is it configured in the `panel/paths`
administration page.
The file directory should be under INSTALLDIR (/) and not in PUBLICDIR (public/).
In panel/paths you should have something like /file/ for Attachments->path.
I believe having this misconfigured might well be the reason for the 404s you are experiencing.
The `file/` (should it better be in `public/`?) folder's location is
`/var/www/social/file/` and so is it configured in the `panel/paths`
administration page.
The `file` directory should be under INSTALLDIR (`/`) and not in PUBLICDIR (`public/`).
In `panel/paths` you should have something like `/file/` for *Attachments->path*.
I believe having this misconfigured might well be the reason for the 404s you are experiencing.
Here's my panel/paths settings. I moved back the file directory under INSTALLDIR following your advice. Then I made the changes needed (in config.php and NGINX block, then restarted NGINX) and I still got the error with the thumbnails. I'm on vacation, so I will try to debug the rest when I come back home, but it seems to be related to the Qvitter plugin and how it loads the thumbnails.
Here's my `panel/paths` settings. I moved back the `file` directory under INSTALLDIR following your advice. Then I made the changes needed (in config.php and NGINX block, then restarted NGINX) and I still got the error with the thumbnails. I'm on vacation, so I will try to debug the rest when I come back home, but it seems to be related to the Qvitter plugin and how it loads the thumbnails.
AFAIK, the issue I encountered was the way Qvitter was handling the thumbnails and so was I getting that many errors. With the default UI, I don't have any problems (just the attachment-wrapper's height that is fixed and giving an akward height to the previews, still need to see what's happening there).
As mentionned on this issue regarding Qvitter, I am aware that Qvitter is not maintained anymore, as for the instance it was created for in the first place (quitter.se), and a "mordern" UI like it is missing me.
AFAIK, the issue I encountered was the way Qvitter was handling the thumbnails and so was I getting that many errors. With the default UI, I don't have any problems (just the attachment-wrapper's height that is fixed and giving an akward height to the previews, still need to see what's happening there).
As mentionned on [this issue regarding Qvitter](https://notabug.org/diogo/gnu-social/issues/57), I am aware that Qvitter is not maintained anymore, as for the instance it was created for in the first place (quitter.se), and a "mordern" UI like it is missing me.
With the same scenario (nginx and php-fpm, similar config) with the exception of qvitter, i was having the same issue when enabling X-Accel-Redirect.
I haven't tried it for a while; i've just enabled it again, and now it's working fine :)
With the same scenario (nginx and php-fpm, similar config) with the exception of qvitter, i was having the same issue when enabling X-Accel-Redirect.
I haven't tried it for a while; i've just enabled it again, and now it's working fine :)
I'm using the latest
master
branch with NGINX and PHP-FPM. I tried to configure x-static-delivery, so I added the following in my configuration file:After that I ran the
checkschema.php
script, then modified my NGINX configuration, adding the following:The
file/
(should it better be inpublic/
?) folder's location is/var/www/social/file/
and so is it configured in thepanel/paths
administration page.But I'm getting 404 on every thumbnail. Can you please elaborate the documentation on how to enable this feature? Thank you.
That's rather interesting. As far as I can tell, that config seems correct. What commit are you on? Do you have any log messages? Is the nginx config block above other blocks? Maybe some regex is conflicting (specifically the
location /
block).I am using commit
0bb35d7e7f
. I enabled the access_log and error_log in my NGINX config and got this:The NGINX block is weel above the other blocks, I copied the DOCUMENTATION/SYSTEM_ADMINISTRATORS/webserver_conf/nginx.conf.sample and made this:
Here's also my PHP-FPM block:
Does the 404 appear when you post a notice with an attachment locally? Can you turn debugging on in the config and see if there's anything in the logs? When you post an attachment, you should get a link to it, with an ID in the end; could you check the database entries in the
file
andfile_thumbnail
tables for that ID?The
file
folder is not supposed to be insidepublic
, the point is that the webserver doesn't serve the files directly. In the nginx log you posted the error was when accessing the file directly, it seems. How did that request happen? Did the link appear somewhere on the page? Do you have extra plugins enabled?The
file
directory should be under INSTALLDIR (/
) and not in PUBLICDIR (public/
).In
panel/paths
you should have something like/file/
for Attachments->path.I believe having this misconfigured might well be the reason for the 404s you are experiencing.
Here's my
panel/paths
settings. I moved back thefile
directory under INSTALLDIR following your advice. Then I made the changes needed (in config.php and NGINX block, then restarted NGINX) and I still got the error with the thumbnails. I'm on vacation, so I will try to debug the rest when I come back home, but it seems to be related to the Qvitter plugin and how it loads the thumbnails.Any update?
AFAIK, the issue I encountered was the way Qvitter was handling the thumbnails and so was I getting that many errors. With the default UI, I don't have any problems (just the attachment-wrapper's height that is fixed and giving an akward height to the previews, still need to see what's happening there).
As mentionned on this issue regarding Qvitter, I am aware that Qvitter is not maintained anymore, as for the instance it was created for in the first place (quitter.se), and a "mordern" UI like it is missing me.
With the same scenario (nginx and php-fpm, similar config) with the exception of qvitter, i was having the same issue when enabling X-Accel-Redirect. I haven't tried it for a while; i've just enabled it again, and now it's working fine :)
Ops... disabled again, as it seems to interfere with cache. Examples follow.
1) X-Accel-Redirect enabled:
curl -I https://gnusocial.net/avatar/1-96-20200119102924.jpeg HTTP/2 200 server: nginx date: Wed, 08 Jul 2020 10:48:07 GMT content-type: text/html; charset=UTF-8 content-length: 2891 last-modified: Sat, 25 Apr 2020 18:24:33 GMT etag: "5ea48061-b4b" strict-transport-security: max-age=15768000; preload; x-content-type-options: nosniff referrer-policy: strict-origin-when-cross-origin content-security-policy: default-src 'self' 'unsafe-inline'; frame-ancestors 'self'; form-action 'self'; style-src 'self' 'unsafe-inline'; img-src * blob: data:; x-permitted-cross-domain-policies: none x-robots-tag: all accept-ranges: bytes
2) X-Accel-Redirect disabled:
curl -I https://gnusocial.net/avatar/1-96-20200119102924.jpeg HTTP/2 200 server: nginx date: Wed, 08 Jul 2020 10:49:11 GMT content-type: image/jpeg content-length: 2891 vary: Accept-Encoding,Cookie content-description: File Transfer content-disposition: inline; filename="1-96-20200119102924.jpeg" expires: Fri, 07 Aug 2020 10:49:11 GMT content-transfer-encoding: binary cache-control: max-age=2592000 strict-transport-security: max-age=15768000; preload; x-content-type-options: nosniff referrer-policy: strict-origin-when-cross-origin content-security-policy: default-src 'self' 'unsafe-inline'; frame-ancestors 'self'; form-action 'self'; style-src 'self' 'unsafe-inline'; img-src * blob: data:; x-permitted-cross-domain-policies: none x-robots-tag: all
(Note the "expires" line in the second one).