Right, time to refocus on the primary objective of this exercise and that is to try to figure out a way to get the Caddy word out there (for good and bad apps!) . I’m going to try Mathew’s suggestion and I’ll report back shortly, but first, an early morning cuppa
This is what I love about you. You’re such a purist. Thank goodness for this trait! Without it, Caddy wouldn’t be the amazing product that it is.
Not only is the WP app less than ideal, but the support documentation is woeful as I’ve indicated in an earlier post Process check: Spreading the Caddy Word - #6 by basil. There’s been a recent and positive development though. I’m one step closer to the WP documentation team, which should make it easier to sell the idea of linking to Caddy wiki articles. Check out the WordPress forum thread Giving WordPress Its Own Directory.
Yes, but make sure you keep the same structure as the expanded form (long form of try_files). The split_path .php is important for it to actually work properly.
When the WordPress files were relocated from the webroot to a subdirectory, and the site block in the Caddyfile updated to do an internal redirect…
@subdir {
not path /my_subdir/*
not file
}
rewrite @subdir /my_subdir{uri}
…the home page of the site remained accessible, but sub-pages became inaccessible. The issue wasn’t with permalinks. php_fastcgi handles permalinks intrinsically. For the sub-pages to become accessible again, the rewrite required an expanded version of php_fastcgi to be used.
This ‘hard-coding’ of ‘my_subdir’ causes a further problem though. Returning to an earlier discussion…
This breaks as a consequence. Can this be accommodated as well given that a reason for relocating WordPress files out of the webroot was to enable versioning? It seems to me like the hard-coding needs to be replaced with something relative, but I don’t know what that might be.
At the beginning of this post, I created a ‘version’ of the WP site.
cp -r my_subdir 2020
chown -R www:www 2020
This was a gross oversimplification of what WP versioning entails. Refer to this independent article Moving a WordPress Root Install to a Subdirectory Install and Vice Versa for a sense of what might be involved… For this exercise, I don’t really want to go any further down the rabbit’s hole. From tests 1 and 2, I’m satisfied the Caddy equivalent code for the WP article is working correctly.
As the link refers to a Caddy V1 article, and as Caddy V1 is now obsolete, I’d like to get this bullet point changed This is what I’m proposing as the replacement text:
Pretty permalinks are available under:
Caddy automatically in a default WordPress installation.
Just further down in the WP article, in the section Using “Pretty” permalinks, add the following bullet point:
For Caddy, a web server that supports HTTPS natively, the rewrite rule may need to be adjusted if WordPress files are moved to a subdirectory. Refer to Using Caddy to give WordPress its own directory for details.
If you can improve on this wording, please have a go. I’ll submit a change request with issue #332.once we have agreement on the wording.
I’m at the tail end of the process check. I followed these four steps:
Pick a page to transform - Find an application support page to do a Caddy makeover on.
Track the transformation - Create a Caddy forum thread for tracking the conversion, testing, and for community and Caddy core maintainer input.
Wikify the result - Summarise the result in a Caddy wiki article
Lobby for inclusion - Contact the application document team to include a reference to the Caddy wiki article on the original page.
However, I realise after reviewing a few other application pages, step 3 may not be appropriate in many situations. For example, consider the WP article Brute Force Attacks. On this page, several proxy servers are mentioned already. The idea here would be to add Caddy to that list. In light of this, a revised process might look like the following:
Pick a page - Find an application page to make Caddy ready.
Discuss the approach - Create a Caddy forum thread for reviewing the approach, Caddy code to use, community and Caddy core maintainer input, and testing
Optionally, wikify the result - Summarise the result in a Caddy wiki article. This step is appropriate when the application page centres on a single proxy server.
Lobby for inclusion - Contact the application document team to have Caddy referenced on the application page.
Leading up to the meeting, things were a little bit touch and go regarding the request put through to link the Caddy wiki article to an existing WP article.
There’s a big discussion on whether the articles contain external links or not. I don’t know if it got resolved.
This is generally disallowed, but it appears that Caddy forum wiki articles are considered a credible source. The WP documentation team are short-staffed so it will take some time before the Caddy reference appears on the said article. Still, it’s in the pipeline
The next step I guess is to reflect on this thread and maybe try to understand the benefits/downsides of the process. It’s really a checkpoint on whether or not to continue down this path.
Application pages often contain code for other proxy servers. This is likely to be unfamiliar to the contributor, Seek help from the Caddy community to convert these code snippets to a Caddy equivalent.
Seek Caddy core maintainer endorsement on any Caddy code being considered for an application page. No one knows the Caddy code better!
Don’t assume the Caddy code will work. It’s important to test it with the application. As it turned out, for the process check, there were unforeseen side effects that only surfaced during testing.
Stakeholder benefits
Contributor
Contributors generally come from the position of being knowledgeable on the application. Outcomes for the contributor:
By making an application page Caddy ready, contributors improve their knowledge of Caddy.
Contributors become an ‘expert’.on the specified application page.
Contributors create a bridge between the application and Caddy.
Caddy Maintainers
Caddy core maintainers generally come from the position of being knowledgeable on Caddy, but are not necessarily knowledgeable on the application. Outcomes for core maintainers:
As more templated solutions are provided, the number of support requests for an application should reduce over time. Core maintainers should end up only handling bespoke requests for the application.
Gradual shift in the support paradigm to more bespoke Caddy requirements.
Expect new Caddy audiences to filter through application support pages.
An increased Caddy footprint in applications.
Caddy Community
Support the contributor through their knowledge of the application and Caddy.
Observe and learn first-hand as the solution unfolds within the forum.
End-users
Naturally become aware of or gravitate to a Caddy solution via the application page.
More of a self-service approach using ‘canned’ Caddy solutions.
Risk Analysis
Risk
Likelihood
Impact
Consequence
Mitigation
New Caddy keywords are introduced.
Medium
Low
Caddy code on some application pages could be improved.
Maintain a register of Caddy ready application pages.
Caddy keywords are deprecated.
Low
Low
Caddy code on some application pages may need to be reviewed.
Maintain a register of Caddy ready application pages.
Caddy keywords become defunct.
Low
Medium
Caddy code on some application pages will need to be updated.
Maintain a register of Caddy ready application pages.
Caddy rewrite from V2 to V3.
?
High
Caddy code on every application page will need to be reviewed.
Maintain a register of Caddy ready application pages.
Caddy code isn’t added to the application’s support pages
?
Low
No new Caddy audiences through the application / No Caddy footprint in the application / Support requests for the application do not decrease.
Effective lobbying of the application documentation team is required to maximise the chances of Caddy code being inserted or referenced in application support pages.
Probably, yes. Will probably need experimenting with. Using index off essentially drops the middle block from the expanded form, so you can redo that part yourself instead. Using an argument for index changes both of the instances of index.php in that try_files, but it seems like you only want to change the last one, so you do need to do it yourself.
This raises an important point for the process. If a solution has a degree of complexity, it’s probably a good idea to create a Caddy wiki page for it rather than insert Caddy code in the application page. This way. it’s easier to update the solution as it matures.
Based on the risk analysis and recent changes to the wiki article for the test case, the suggested process for making application pages Caddy ready matures as follows:
Pick a page - Find an application page to make Caddy ready.
Discuss the approach - Create a Caddy forum thread for reviewing the approach, Caddy code to use, community and Caddy core maintainer input, and testing
Optionally, wikify the result - Summarise the result in a Caddy wiki article. This step is appropriate when the application page centres on a single proxy server, or, the Caddy solution has a degree of complexity.
Update the register of Caddy ready application pages.
Lobby for inclusion - Contact the application document team to have Caddy referenced on the application page.
If Caddy core maintainers are reasonably satisfied with this, I’ll start work on a wiki page for the process and the register.