Process check: Spreading the Caddy Word

They go inside transport fastcgi.

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.

2 Likes

I believe you mean like this?

(php_fastcgi2) {
  route {
    # Add trailing slash for directory requests
    @canonicalPath {
      file {path}/index.php
      not path */
    }
    redir @canonicalPath {path}/ 308

    # If the requested file does not exist, try index files
    @indexFiles file {
#    try_files {path} {path}/index.php index.php
      try_files {path} {path}/index.php /my_subdir/index.php
      split_path .PHP
    }
    rewrite @indexFiles {http.matchers.file.relative}

    # Proxy PHP files to the FastCGI responder
    @phpFiles path *.php
    reverse_proxy @phpFiles {args.0} {
      transport fastcgi {
        env SERVER_PORT 80
    	split .PHP
      }
    }
  }
}

Yeah probably. I think you need lowercase .php though for both split parts. Linux filesystems are case sensitive.

1 Like

Reviewing post Process check: Spreading the Caddy Word - #15 by basil

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.

These are tests I undertook to confirm the issue:

My webroot is defined as root * /usr/local/www/wordpress. From the root, I set up the test environment.

cp -r my_subdir 2020
chown -R www:www 2020
echo "Hello from root!" >> sample.txt
echo "Hello from 2020!" >> 2020/sample.txt
echo "Hello from my_subdir!" >> my_subdir/sample.txt
echo "Hello from default!" >> my_subdir/default.txt

Test 1

Confirm that this Caddy structure worked as intended:

@subdir {
  not path /my_subdir/*
  not file
}
rewrite @subdir /my_subdir{uri}

c14

c15

Yep, that looks good.

Test 2

Check that the modified php_fastcgi works for my_subdir.

That looks good too.

Test 3

Check that versioning works.

Oops!

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.

Next step: Writing the wiki article.

The wiki article has been drafted for review Using Caddy to give WordPress its own directory.

The final step is to lobby the WordPress documentation team to have it referenced on a WordPress support page.

1 Like

A request has been submitted to the WP doc team. See Using Caddy to Give WordPress Its Own Directory · Issue #332 · WordPress/HelpHub · GitHub

A related issue…

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:

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.

The draft wording is based on these follow-up comments from @francislavoie and @Whitestrake

I’m at the tail end of the process check. I followed these four steps:

  1. Pick a page to transform - Find an application support page to do a Caddy makeover on.
  2. Track the transformation - Create a Caddy forum thread for tracking the conversion, testing, and for community and Caddy core maintainer input.
  3. Wikify the result - Summarise the result in a Caddy wiki article
  4. 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:

  1. Pick a page - Find an application page to make Caddy ready.
  2. Discuss the approach - Create a Caddy forum thread for reviewing the approach, Caddy code to use, community and Caddy core maintainer input, and testing
  3. 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.
  4. Lobby for inclusion - Contact the application document team to have Caddy referenced on the application page.
1 Like

I’ve just come out of my (first-ever!) Slack meeting with the WordPress documentation team.

The documentation team holds weekly office hours on Tuesdays from 14:00-15:00 UTC in the #docs Slack channel.

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 :smiley:

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.

3 Likes

That’s great progress, thanks for the update!

Lessons learnt

  1. 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.
  2. Seek Caddy core maintainer endorsement on any Caddy code being considered for an application page. No one knows the Caddy code better!
  3. 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:

  1. By making an application page Caddy ready, contributors improve their knowledge of Caddy.
  2. Contributors become an ‘expert’.on the specified application page.
  3. 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:

  1. 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.
  2. Gradual shift in the support paradigm to more bespoke Caddy requirements.
  3. Expect new Caddy audiences to filter through application support pages.
  4. An increased Caddy footprint in applications.

Caddy Community

  1. Support the contributor through their knowledge of the application and Caddy.
  2. Observe and learn first-hand as the solution unfolds within the forum.

End-users

  1. Naturally become aware of or gravitate to a Caddy solution via the application page.
  2. 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.
2 Likes

@francislavoie Could the suggestion proposed in this thread here Handle_errors not working - #2 by francislavoie be used here
Process check: Spreading the Caddy Word - #19 by Whitestrake? If so, it might lead to a solution that avoids the use of the expanded form of phph_fastcgi.

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.

That makes the method I solution in the wiki article Using Caddy to give WordPress its own directory much more elegant and appealing.

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:

  1. Pick a page - Find an application page to make Caddy ready.
  2. Discuss the approach - Create a Caddy forum thread for reviewing the approach, Caddy code to use, community and Caddy core maintainer input, and testing
  3. 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.
  4. Update the register of Caddy ready application pages.
  5. 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.

FYI I linked to this topic from here:

1 Like

@matt Maybe move this post as well to the thread Terraforming the application landscape to help spread the Caddy message.

Which post?

Post #40 about Symfony.

1 Like

This topic was automatically closed after 30 days. New replies are no longer allowed.