Turn on the debug global option, and take a look at Caddy’s logs. You should see logs about the rewrites Caddy is attempting to do, and the result the redirect.
I exported the logs from journalctl -u caddy --no-pager | less and searched through them and cannot find any “rewrite request” from my last runs.
Of course, I had triggered the same URL in the browser which should have fired in the logs.
Sorry, I am new to some of this debugging and trying to learn.
You can hit Shift+G to jump to the bottom of the logs in less, and hit / to start a search, hit / and enter again to find the next result etc. ? to search backwards instead of forwards. Shift+F to follow/tail the output.
But if you’re not seeing the log, then it’s because Caddy didn’t actually do a rewrite.
Oh right
So this is an edgecase, uri replace will actually run separately on first the path, then the query, but not on both together as one string. So that means a replacement that tries to replace ? will never match because ? will not be contained in those strings (the path will be /wl/ and query will be id/ccug8DTWATo4hrCT56XDjypaq8XHi015, replace running on each of those separately)
So I think the correct thing to do for you instead would be:
rewrite * /index.php/s/{query}?
uri replace id/ ""
redir https://share.example.com{uri}
Kinda funky, but basically {query} will contain id/ccug8DTWATo4hrCT56XDjypaq8XHi015, and you append that to index.php/s/, and adding ? to the end should clear the query. Then you remove id/ from the path itself in a second step.
That’s what I think it should do anyway. Check the logs to verify.