As I see, there are no any logs in /var/log or anywhere else.
> any error logs?
Where can I get them?
As I see, there are no any logs in /var/log or anywhere else.
and tell me if it logs any PHP errors. From there I will be able to help you
Please setup logging rules
https://caddyserver.com/docs/caddyfile/directives/log
and tell me if it logs any PHP errors. From there I will be able to help you
I'd like to expand on this, since I'm having a similar issue; 4get acting weird. It most likely is something about the Caddyfile, but yeah. Nginx works fine, but when it comes to Caddy it just throws a blank page and a prompt to download if web?s= is present in the URL.
<abbr title="also that was so rude… #willoverparty">I'd like to expand on this</abbr>, since I'm having a similar issue; 4get acting weird. It most likely is something about the Caddyfile, but yeah. Nginx works fine, but when it comes to Caddy it just throws a blank page and a prompt to download if `web?s=` is present in the URL.
Here's the file:
```sh
:port {
root * /var/www/4g
file_server
encode gzip
php_fastcgi /var/run/php-fpm/php-fpm.sock {
index index.php
}
redir /{path}.php{query} 301
try_files {path} {path}.php
}
```
`port` is, well, a port.
i'm not a caddy guy, but with the described behavior my IT monkey debug procedure would be
what happens if you download when it prompts you? if it's the .php file your fpm is fucked one way or another, i bet
what happens if you make requests to the actual php endpoints? e.g. /web.php. if that works but the other thing doesn't, i guess your redirect is blowing it somehow?
i presume the index loads fine? if not make sure the root is correct
it looks like the config 301s /web to /web.php? this isn't really a config error but it is an interesting difference between the sample configs, now that i look at them.
apache passes /x to /x.php internally but doesn't care if you hit /x.php directly
nginx passes /x to /x.php internally but does 301 you to /x if you try to hit /x.php
caddy seemingly just 301s everything to /x.php
probably not helpful but 's all i got on short notice. if you can't get it figured out hit up diowo, i think he wrote this caddy config originally. shoutout nginx, ain't never let me down.
> @cynic
i'm not a caddy guy, but with the described behavior my IT monkey debug procedure would be
* what happens if you download when it prompts you? if it's the .php file your fpm is fucked one way or another, i bet
* what happens if you make requests to the actual php endpoints? e.g. /web.php. if that works but the other thing doesn't, i guess your redirect is blowing it somehow?
* i presume the index loads fine? if not make sure the root is correct
* it looks like the config 301s /web to /web.php? this isn't really a config error but it is an interesting difference between the sample configs, now that i look at them.
* apache passes /x to /x.php internally but doesn't care if you hit /x.php directly
* nginx passes /x to /x.php internally but *does* 301 you to /x if you try to hit /x.php
* caddy seemingly just 301s everything to /x.php
probably not helpful but 's all i got on short notice. if you can't get it figured out hit up diowo, i think he wrote this caddy config originally. shoutout nginx, ain't never let me down.
alright, for some reason, it works but only if you go to /index.php first
and no, the plain url is 404, but appears as a blank page if using firefox-based browsers, for chromium it just straight up shows 404
my guess here is that the index is set wrong, but i could be wrong
alright, for some reason, it works but only if you go to `/index.php` first
and no, the plain url is 404, but appears as a blank page if using firefox-based browsers, for chromium it just straight up shows 404
my guess here is that the index is set wrong, but i could be wrong
while also commenting out the index index.php line.
4got to update,
The fix I found was to set
```sh
try_files {path} {path}.php
```
to
```sh
try_files {path} {path}.php index.php
```
while also commenting out the `index index.php` line.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I use Arch btw.
Installed PHP packages:
Main page works
Instance browser page works, but there's no successful requests.
Search doesn't work
My Caddyfile:
any error logs?
Where can I get them?
As I see, there are no any logs in /var/log or anywhere else.
Please setup logging rules
https://caddyserver.com/docs/caddyfile/directives/log
and tell me if it logs any PHP errors. From there I will be able to help you
Closing as I didn't get any feedback from OP
I'd like to expand on this, since I'm having a similar issue; 4get acting weird. It most likely is something about the Caddyfile, but yeah. Nginx works fine, but when it comes to Caddy it just throws a blank page and a prompt to download if
web?s=is present in the URL.Here's the file:
portis, well, a port.Log:
@cynic
i'm not a caddy guy, but with the described behavior my IT monkey debug procedure would be
what happens if you download when it prompts you? if it's the .php file your fpm is fucked one way or another, i bet
what happens if you make requests to the actual php endpoints? e.g. /web.php. if that works but the other thing doesn't, i guess your redirect is blowing it somehow?
i presume the index loads fine? if not make sure the root is correct
it looks like the config 301s /web to /web.php? this isn't really a config error but it is an interesting difference between the sample configs, now that i look at them.
probably not helpful but 's all i got on short notice. if you can't get it figured out hit up diowo, i think he wrote this caddy config originally. shoutout nginx, ain't never let me down.
alright, for some reason, it works but only if you go to
/index.phpfirstand no, the plain url is 404, but appears as a blank page if using firefox-based browsers, for chromium it just straight up shows 404
my guess here is that the index is set wrong, but i could be wrong
4got to update,
The fix I found was to set
to
while also commenting out the
index index.phpline.