Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document WP Cloud website setup #1338

Merged
merged 2 commits into from
Apr 27, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
32 changes: 32 additions & 0 deletions packages/playground/website-deployment/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,32 @@
# Hosting playground.wordpress.net on WP Cloud

This document covers our setup to host playground.wordpress.net on WP Cloud.

## Web server configuration

The WP Cloud platform is primarily focused on hosting WordPress. Since playground.wordpress.net is not a WordPress site and has some Playground-specific requirements, we had to do a number of things to get the site running as desired.

WP Cloud uses Nginx which does not support the .htaccess files we used previously for:

- rewriting URLs
- redirecting requests
- customizing response headers
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure where the multiple spaces between the hyphen and the text came from. Perhaps it is from an auto-formatter on commit.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that’s a formatter. I don’t mind but if you find it annoying then let’s change it.


In order to customize these aspects for static files on WP Cloud, we did the following:

- Configured the WP Cloud site to delegate requests for non-existent files to WordPress.
- Provided a `__wp__/index.php` file as a default target for Nginx. - Even though this is not a WordPress site, we can provide a `__wp__/index.php` file that Nginx will run as a fallback for non-existent files. The `__wp__/index.php` file is empty and simply exists so Nginx will invoke PHP.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The __wp__/index.php file is empty and simply exists so Nginx will invoke PHP.

What’s the value of simply invoking php?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, I got my answer from the next bullet point

- Added a `custom-redirects.php` file to implement special request handling. - WP Cloud invokes `<web-root>/custom-redirects.php` (if it exists) at the beginning of every PHP run in order to provide custom request handling. We added this file to implement the rewrites, redirects, and custom headers that we used to get via htaccess.
- Set aside files that need special handling. - If we need custom treatment of static files, those files cannot be found by Nginx. Otherwise, Nginx will serve them directly without invoking PHP. For this reason, all files that need special treatment are set aside under `<web-root>/files-to-serve-via-php/`

## Deployment notes

New website builds are pushed to the WP Cloud site via SSH.

During deployment, we consult `custom-redirects-lib.php` about each file, and if it needs special treatment (e.g., URL rewrites, redirects, etc), it is set aside into the `<web-root>/files-to-serve-via-php/` folder with its relative path otherwise preserved. For example, if a file `a/b/c/playground.png` requires special handling, it is moved to `<web-root>/files-to-serve-via-php/a/b/c/playground.png`. Nginx will no longer find the file based on the request URI `a/b/c/playground.png` and will delegate the request to PHP, giving us a chance to customize how the file is served.

At the end of the deployment process, the WP Cloud edge cache is purged.

## Secrets

Secrets are provided by a "Persistent Data" feature of WP Cloud and are set manually via a WP Cloud API. Once set, the secrets are synched to the site in an encrypted form which is accessed by `custom-redirects-lib.php` via the `Atomic_Persistent_Data`. Here is an [example of retrieving Slack-related secrets](https://github.com/WordPress/wordpress-playground/blob/776e8bbddecdde287ae7bb1d42d711dedf71f138/packages/playground/website-deployment/custom-redirects-lib.php#L186-L192).
Loading