Caddy v2 with wondercms

Help
1

Hey guys,
thanks for the caddy server, i find it really easy proxying docker apps. I tried getting wondercms to work this time without docker and have problems with the caddyfile.

1. Caddy version (caddy version):

2.4.6

2. How I run Caddy:

Debian apt with caddy stable repo

a. System environment:

Debian 5.10.84 VPS
PHP 7.4

b. Command:

Paste command here.

c. Service/unit/compose file:

Paste full file contents here.
Make sure backticks stay on their own lines,
and the post looks nice in the preview pane.

d. My complete Caddyfile or JSON config:

web.tllggrs.de {

  import logd

  root * /var/www/wondercms
  encode gzip zstd
  file_server

  respond /cache.json 403
  respond /database.js 403

  try_files {path} {path}/ /index.php?page={http.request.orig_uri.path.file}&{query}

  php_fastcgi unix//var/run/php/php7.4-fpm.sock

  }

3. The problem I’m having:

Especially the original .htaccess file:

Options -Indexes
ServerSignature Off
RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)$ index.php?page=$1 [QSA,L]
RewriteRule database.js - [F]
RewriteRule cache.json - [F]

From the caddy docs first i tried:

try_files {path} {path}/ /index.php?page={path}&{query}

Which should handle all of the rewrite lines but the last two. But it seems that wondercms expects the {path} without the leading slash, which you can see in their nginx file:

rewrite {
  r ^/(.+)$
  to {path} {path}/ /index.php?page={1}
}

so e.g.

/index.php?page=home
not
/index.php?page=/home

which is caddys behaviour for {path}.

So i tried {http.request.orig_uri.path.file} instead, which seems to work at first because wondercms now finds all the pages and doesn’t throw 404 like before.
But now wondercms has problems when setting GET vars. When logging out of admin, it redirects to

index.php/logout&token=sometoken

which ends in an error and not logging out because there should be a question mark instead of the ampersand in the url. Changing it by hand to a question mark in the URL bar makes the logout succeed.

Is this a problem with wondercms thinking the URL already has some GET vars because of the internal rewrite with ?page= and not remembering the actual URL doesnt already have GET vars? Or did i not find the right placeholder for try_files statement causing an error in wondercms php? The placeholder should be equivalent of {path} without leading slash.

Also the caddy file seems to prioritize the try_files statement when requesting cache.json or database.js, instead of responding with 304. Which also prevents access, since it redirects to index.php but is not the wanted behaviour for me.

4. Error messages and/or full log output:

5. What I already tried:

I tried different placeholders, but i can’t find the right one. Also i found an older thread with wondercms but couldn’t get it to work.

6. Links to relevant resources:

Thanks!

2

That’s awkward. I wish PHP CMSes would start actually doing their own routing via the index.php like all other modern PHP frameworks do. Sigh.

But in this case, I think try_files alone won’t be enough for you, you’ll need to use the path_regexp matcher to grab just the part after the slash, and the file matcher to skip doing the rewrite if the request is for a static file.

@page {
	path_regexp page ^/(.+)$
	not file {path} {path}/
}
rewrite @page /index.php?{re.page.1}&{query}
1 Like
3

The issue that wondercms sends logout to /logout&token=xyz still remains with that config. Though manually changing ampersand to questionmark still does the trick.

I also opened an issue with wondercms on github.

4

Yeah, that’s an invalid URL if they’re just using a & and not ?. The query is defined to start with a ?, and continued with each &. They’re not interchangeable.

5

Yeah, it’s a bug on this line:

They should definitely be doing logout?token here

1 Like
6

Nice catch, Francis. Saw your post over there!

7

This topic was automatically closed after 30 days. New replies are no longer allowed.