Hello,
I would like to use PHP and Markdown together so I can write things like:
``# Welcome **<?php echo($user); ?>**
Is there a way to make the two processors work together?
Thanks,
Moe
Hmm, interesting request. I would recommend generating the HTML files from Markdown (which should preserve the PHP tags, I guess? It depends on your Markdown engine) and then just serve the HTML+PHP as you normally would.
Thank you Matt,
That’s roughly the idea I had imagined, I’m curious if I can use Caddy’s built-in Markdown processor and then feed that output into PHP.
But I have no idea what that configuration would look like. Do you?
Thanks,
Moe
I must admit that I have no idea what would happen if you tried something like
markdown {
ext .php
}
fastcgi / localhost:9000 php
Which directive wins here?
Well with this configuration PHP wins. I actually thought Markdown would win since it’s first, but PHP gets it in the end and the Markdown is ignored.
markdown / {
ext .php
css /template.css
}
fastcgi / /run/php/php7.0-fpm.sock {
ext .php
split .php
index index.php
}
1 Like
Interesting result. My initial thought is that markdown would win simply because it’s higher up the Caddyfile than fastcgi.
You might have to write your PHP+Markdown files and then prerender them in the markdown engine of your choice before serving them with Caddy, as @matt mentioned.
Can you imagine the chaos that would ensue if the order of directives depended on their order in the Caddyfile? 
Here’s more on that: GitHub - caddyserver/caddy: Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS and a little more info about how middleware handlers work: httpserver package - github.com/mholt/caddy/caddyhttp/httpserver - Go Packages
FastCGI does have priority over markdown. I think that’s mostly an arbitrary choice… only one can handle the request.
Maybe that’s a weakness in Caddy’s middleware design, or at least of the markdown middleware.
Maybe markdown should forward the request onto other handlers, like the static file server, but wrap the ResponseWriter in its own type so that whatever does fill up the ResponseWriter will have its contents parsed as markdown (erm, we’d probably have to be sensitive to file extension or headers – in markdown’s case, that’s a curious situation: is the file extension .md or .php?). Gzip does something similar: it wraps the writer so that whatever goes down the pipe is gzipped on its way.
Anyway, food for thought.
1 Like
Very informative! Thanks for the links.
Naturally there are elements that have to take an increased or delayed priority, but I figured, as you say:
I thought it was probably an arbitrary choice that could be made by Caddy’s user in configuration, I just wasn’t well read up on the actuality.
It’s okay. It’s not super intuitive/obvious. I wish I could come up with a flexible design to allow customizable order or interop of more middlewares more easily, but… this is the best I could do. (I’m all ears I guess!)
1 Like
From a configuration standpoint, the directives could be nested, something like:
fastcgi / /run/php/php7.0-fpm.sock {
ext .php
split .php
index index.php
markdown / {
css /template.css
}
}Wouldn’t that involve programming each directive to support every other directive? And just how deep would it go? Sounds like a nightmare to me. Maybe some kind of directive chaining might be plausible, but nesting just sounds like a can of worms.
1 Like
Nesting does get multiplicatively complex, compared to chaining. I also prefer “shallow” / “flat” config files for readability.
Alternatively, the ext directive could be used to chain multiple middlewares.
In this case since both fastcgi and markdown have ext php directives, then the request should be sent to both (in the order prescribed in plugin.go).
markdown / {
ext .php
}
fastcgi / /run/php7.0-fpm.sock {
ext .php
}
This would keep the config file flat, and be fairly easy to understand.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.