Monviech
commented
6 months ago A good example can be seen here:
I have defined an "onPreAction" with a deferred promise, that is resolved only when the "saveFormToEndpoint" was successful.
The same behavior can be extended to also include a validation action afterwards.
The validation should reload the template, afterwards use the "caddy fmt --overwrite" to correct all formatting errors, and then use "caddy validate /usr/local/etc/caddy/Caddyfile", parsing the output if the configuration is valid. If not, then the deferred promise should be rejected and a popup should inform the user of it.
The exact error could be printed, but maybe it's too hard to pass it to such an error message, so a general message "Validation of Caddyfile failed" would be the best choice.
Since there are a lot of options and the validation model can't catch all errors, a validation check should be implemented.
I had an invalid configuration a few times because I cloned a domain (I use one domain with like 20 different ports for a very complex setup) and I accidentally had a duplicate port.
Caddy looks like it has started, but it's actually not working then.
The "reconfigure Act" needs another deferred promise, which calls a new "validate" action. A validate script needs to be written that checks the output of "caddy validate /usr/local/etc/caddy/Caddyfile" after it has been regenerated by the template.
If the validation fails and the promise isn't kept, a popup should inform the user that the current configuration is invalid, and the reload of Caddy should not take place.