We (@mholt @dunglas and I) were talking in Slack about the ergonomics of using the Caddyfile for end-users of custom builds of Caddy which may include many handler plugins. Forcing users to specify order or wrap things in route causes some friction that would be nice to smooth out.

The reason we never did this in the past is because we didn't want to allow plugins to depend upon eachother, because we can't guarantee the order in which plugins are loaded. We also didn't want the ordering to become unreliable when the order of directives in the standard distribution changes.

We can mitigate those factors by doing two things:

• Only allow plugins to register an order for their directive in relation to a directive in Caddy's standard distribution (we keep a defaultDirectiveOrder which doesn't change, to ensure this, and modify directiveOrder accordingly)
• Only allow plugins to order "before" and "after" another directive (and no "first" or "last" like the order global option allows) to reduce the chance of ordering that doesn't make sense.

The API looks like this:

httpcaddyfile.RegisterHandlerDirective("my_directive", parseDirective)
httpcaddyfile.RegisterDirectiveOrder("my_directive", "after", "redir") // new

Or course, there's still a slight problem if two plugins try to both order the same way in relation to a standard directive (e.g. both are "before headers") because their order will not be guaranteed. There are some complicated ways we could mitigate this though, for example we could invalidate the ordering for both directives since they're in conflict, forcing the user to specify their own order for both. But ultimately I think this it probably not an immediate need, and we can expand upon that later.