I am using Caddy 2 RC1.
My wordpress is working OK but i have problem with wp-admin subdirectory.
When i try to reach example.com/wp-admin i’m getting err_too_many_redirects error.
However, example.com/wp-admin/index.php working OK.
Here is my config:
example.com
{
root * /var/www/html
try_files {path} {path}/ /index.php?{query}
php_fastcgi unix//run/php/php7.3-fpm.sock
file_server
}
What’s wrong with it?
Have you tried removing try_files ? It’s somewhat redundant because php_fastcgi has its own try_files directive. See here for the explanation: php_fastcgi (Caddyfile directive) — Caddy Documentation
Try this:
example.com {
root * /var/www/html
php_fastcgi unix//run/php/php7.3-fpm.sock
encode gzip
file_server
}
You may also want to add the following in case users upload .php files to your site:
respond /uploads/*.php 404
second question, my caddy service file is not taking config file when i reboot or reload caddy.
i need to use adapt everytime i reboot.
it’s the same service with that you provided in installation docs. my Caddyfile located under /etc/caddy/Caddyfile
The current service file is designed to give you durability, ensuring that your config doesn’t change after a reboot. But reloading should work.
Did you solve your first question?
yes. it’s working great right now.
my config is not changed after reboot. but when i reboot, everytime caddy starting with
localhost config (i think it’s equal to no config). i believe that somehow it’s not taking config in action automatically.
Yes, that’s expected behaviour with the service file you’re currently using. Use sudo service caddy reload instead when you make config changes, not restart.
We have updated service files here that don’t have that issue:
It’s due to the --resume flag being in your service file, which clashes with your expectations.
i noticed that you updated it, i got the latest service file. i am using ubuntu 19.10.
Right now my config file is located under /etc/caddy/Caddyfile. I am sure. I even gave chmod 777 to config file.
Also Caddy is running after reboot but with localhost config 
i am basically doing:
caddy stop
caddy adapt
caddy start
otherwise i am just getting bad gateway in cloudflare.
What do you mean by “localhost config” ? Do you mean an old config that stuck around? If so, what’s that config? Got any logs? You’ll need to give us more information to go on here.
well i checked the logs, it was an issue with permissions. i gave chmod 777 to php-fpm sock and it’s fixed.
thanks a lot for your help.
This may end up being a monumental mistake.
Anyone with file access can now exploit your entire server via PHP.
“But nobody has file access!” you might say.
Getting trivial file access via another exploit that may have been mitigated by proper security is now a critical data loss event instead. Depending on the purpose of your site, this could be quite bad.
The fact it works with chmod 777 should be taken as an invitation to solve the issue properly with the correct permissions. Please do not leave the PHP-FPM socket world-executable.
I did chown caddy:caddy php7.3-fpm.sock
gave 644 to it.
any suggestions?
Based on the unit file above, the socket ownership should be set to caddy:caddy and the permissions should be 0660.
This should be set in PHP’s php-fpm.conf file, rather than being done with chown/chmod.
I’m pretty sure WordPress will respond with 403 to any php files in the uploads directory on its own. I’m not sure what version started this behavior.
Actually it’s working great (I am not accepting any file from visitors, but i tried that).
domain.com {
respond /wp-content/uploads/*/*/*.php 404
root * /root/dir
php_fastcgi unix//run/php/php7.2-fpm.sock
encode zstd gzip
file_server
}So what is the minimum needed to serve wordpress?
Something like this? Would this make a good example for the wiki?
example.com
root * /var/www/wordpress
php_fastcgi unix//run/php/php-version-fpm.sock
file_server
yes. but also he/she need to edit php-fpm listener.
otherwise caddy installation could make it automatically if it detects php-fpm like nginx (from linux distro ) does.
I think that’s the right example. The permissions and php config are important, but they aren’t directly relevant to caddy, and you’ll have varying approaches. I’d stick to the most basic example and let people figure the rest out for themselves based on their own needs.
Excellent – yeah, examples are meant to be tuned by the user, not blindly copied+pasted. For example I don’t want to hard-code a PHP version thinking they have to always be using an old version of PHP.
I will post it as a wiki article unless someone beats me to it 
Is it a good idea to create similar posts for other CMS or systems in the Wiki ? One post per configuration ?