Use straight quotes.

Backtick inline literals.
Rename _ to - in virtual-host, and add to index and refactor.
Clean up MyST markup for virtual-host.md

docs/plone-deployment/deploy.md

@@ -90,7 +90,7 @@ Add secrets in the `Secrets` section of your environment. Refer to the table bel
 
 | Secret Name | Secret Value | Description |
 |-------------|--------------|-------------|
-| DEPLOY_HOST | Your hostname or IP | The Docker Swarm manager’s address. |
+| DEPLOY_HOST | Your hostname or IP | The Docker Swarm manager's address. |
 | DEPLOY_PORT | 22 | The SSHD port. |
 | DEPLOY_USER | Your username | A user with Docker command permissions. |
 | DEPLOY_SSH  | Content of `devops/etc/keys/plone_prod_deploy_rsa` | The private SSH key for connection. |

docs/plone-deployment/index.md

@@ -38,4 +38,5 @@ project-start
 project-edit
 server-setup
 deploy
+virtual-host
 ```

docs/plone-deployment/intro.md

@@ -55,9 +55,9 @@ simplifies the setup process, making it accessible even for beginners.
 
 #### GitHub and GitHub Actions
 
-With Plone’s development anchored on GitHub, the community is gravitating towards GitHub Actions for new packages.
+With Plone's development anchored on GitHub, the community is gravitating towards GitHub Actions for new packages.
 The principles outlined are adaptable to GitLab, Jenkins, and similar platforms.
 
 #### Kubernetes
 
-While the current training edition doesn’t cover Kubernetes, we anticipate its inclusion in future updates.
+While the current training edition doesn't cover Kubernetes, we anticipate its inclusion in future updates.

docs/plone-deployment/plone-stack.md

@@ -10,15 +10,15 @@ myst:
 
 Explore the intricate components of the Plone stack, tailored for deploying a modern Plone 6 site with a ReactJS-powered frontend.
 For deployments focusing on Plone Classic UI with server-side HTML rendering, the frontend component is excluded.
-This guide won’t cover the integration of a web accelerator or the setup of an edge caching service.
+This guide won't cover the integration of a web accelerator or the setup of an edge caching service.
 
 ## Components of the Plone Stack
 
 ### Webserver
 
 The webserver, accessible externally on ports 80 and 443, handles the routing and rewriting of HTTP requests to the Plone frontend and backend, and is tasked with TLS termination. While {term}`Nginx` and {term}`Traefik` are recommended, other webservers can also be employed. This training will exclusively utilize Traefik.
 
-To understand the rewrite rules used in Traefik, please read our reference about {term}`Zope`'s [Virtual Hosting Services](./virtual_host).
+To understand the rewrite rules used in Traefik, please read our reference about {term}`Zope`'s {doc}`virtual-host`.
 
 ### Web Accelerator
 
@@ -30,7 +30,7 @@ Hosted on a Node HTTP-server running on port 3000, the Plone frontend constitute
 
 ### Plone Backend
 
-Operating on port 8080, the Plone Backend, a WSGI process, serves as the HTTP server hosting the Plone API. It’s optimal to pair it with a specialized database like ZEO server or a relational database via RelStorage, supporting PostgreSQL, MySQL/MariaDB, and Oracle. A separate shared file system is essential for storing binary data if ZEO is employed.
+Operating on port 8080, the Plone Backend, a WSGI process, serves as the HTTP server hosting the Plone API. It's optimal to pair it with a specialized database like ZEO server or a relational database via RelStorage, supporting PostgreSQL, MySQL/MariaDB, and Oracle. A separate shared file system is essential for storing binary data if ZEO is employed.
 
 ### Database
 

docs/plone-deployment/project-edit.md

@@ -20,7 +20,7 @@ Both Plone Frontend and Backend in your project support add-on integration. Add-
 
 ### Adding a New Block to the Frontend
 
-We’ll illustrate the process of integrating a Frontend add-on, `@plonegovbr/volto-code-block`, which renders highlighted source code blocks. We’ll centralize all modifications within our project's add-on, `volto-ploneconf2024`, to streamline future Volto version upgrades.
+We'll illustrate the process of integrating a Frontend add-on, `@plonegovbr/volto-code-block`, which renders highlighted source code blocks. We'll centralize all modifications within our project's add-on, `volto-ploneconf2024`, to streamline future Volto version upgrades.
 
 #### Incorporating a New Dependency
 
@@ -59,7 +59,7 @@ git push
 
 ## Implementing OAuth Support with GitHub
 
-We’ll now add GitHub OAuth authentication, involving both Backend and Frontend add-ons and GitHub OAuth application creation.
+We'll now add GitHub OAuth authentication, involving both Backend and Frontend add-ons and GitHub OAuth application creation.
 
 ### Creating a GitHub OAuth Application
 
@@ -88,7 +88,7 @@ To ensure the name `ploneconf24.localhost` points to the address `127.0.0.1`, we
 1. Open the Start Menu and search for **Notepad**.
    Right-click on it and choose **Run as administrator**.
    If Windows asks if you want the application to make changes to the system, click **Yes**.
-   (If you don’t open Notepad as an administrator, you won’t be able to modify the `hosts` file.)
+   (If you don't open Notepad as an administrator, you won't be able to modify the `hosts` file.)
 
 2. In Notepad, click **File » Open**.
    Then navigate to the following folder:
@@ -114,7 +114,7 @@ ping ploneconf24.localhost
 
 Start the Docker Compose stack with `make stack-start`. Navigate to [http://ploneconf2024.localhost/ClassicUI/login](http://ploneconf2024.localhost/ClassicUI/login) and authenticate.
 
-Install `pas.plugins.authomatic` from the {guilabel}`Add-ons` control panel and configure it with the following JSON configuration, replacing `KEYHERE` and `SECRETHERE` with your GitHub OAuth application’s client ID and secret.
+Install `pas.plugins.authomatic` from the {guilabel}`Add-ons` control panel and configure it with the following JSON configuration, replacing `KEYHERE` and `SECRETHERE` with your GitHub OAuth application's client ID and secret.
 
 ```json
 {

docs/plone-deployment/project-start.md

@@ -88,7 +88,7 @@ Docker will download necessary images, build Frontend and Backend images, and in
 
 ### Checking the Stack Status
 
-Verify the stack’s operational status with:
+Verify the stack's operational status with:
 
 ```shell
 make stack-status
@@ -118,7 +118,7 @@ Accessing the site at http://ploneconf2024.localhost
 
 ### Updating the Codebase
 
-For codebase modifications, re-run `make stack-start` to rebuild the affected containers, ensuring your site’s behavior aligns with the updates.
+For codebase modifications, re-run `make stack-start` to rebuild the affected containers, ensuring your site's behavior aligns with the updates.
 
 ### Stopping the Stack
 

docs/plone-deployment/server-setup.md

@@ -27,7 +27,7 @@ Create a new {file}`.env` file by copying the content from the existing `.env_di
 cp .env_dist .env
 ```
 
-Customize the {file}`.env` file to match your specific deployment environment. Here’s an example configuration:
+Customize the {file}`.env` file to match your specific deployment environment. Here's an example configuration:
 
 ```shell
 DEPLOY_ENV=prod
@@ -83,7 +83,7 @@ ssh plone@ploneconf2024-<your-github-username>.tangrama.com.br
 
 ## Setting Up Docker
 
-Ensure you’re logged into Docker, as the deployment process uses public images. Create a new Docker context for the remote server:
+Ensure you're logged into Docker, as the deployment process uses public images. Create a new Docker context for the remote server:
 
 ```shell
 make docker-setup
@@ -97,6 +97,6 @@ make docker-info
 
 # Review
 
-By now you’ve now successfully set up a Plone deployment server using Ansible for automated provisioning, Docker for containerization, and Docker Swarm for scalability and availability.
+By now you've now successfully set up a Plone deployment server using Ansible for automated provisioning, Docker for containerization, and Docker Swarm for scalability and availability.
 
 The next step is to deploy your project to this server.

docs/plone-deployment/setup.md

@@ -19,11 +19,11 @@ Linux/macOS
 :   A recent version is preferred. macOS users should have [Homebrew](https://brew.sh/) installed.
 
 Windows
-:   Consider using [WSL2 with Ubuntu](https://documentation.ubuntu.com/wsl/en/latest/), though it’s not officially tested for this training.
+:   Consider using [WSL2 with Ubuntu](https://documentation.ubuntu.com/wsl/en/latest/), though it's not officially tested for this training.
 
 ### 2. Code Editor
 
-Choose a code editor you’re comfortable with, such as VSCode, PyCharm, Sublime, VI, or Emacs.
+Choose a code editor you're comfortable with, such as VSCode, PyCharm, Sublime, VI, or Emacs.
 
 ### 3. Python
 
@@ -40,7 +40,7 @@ python -m pip install --upgrade pipx uv
 ```
 
 ```{tip}
-Use [Pyenv](https://github.com/pyenv/pyenv) if your system doesn’t provide the required Python version.
+Use [Pyenv](https://github.com/pyenv/pyenv) if your system doesn't provide the required Python version.
 ```
 
 ### 4. Docker
@@ -102,7 +102,7 @@ We'll use the GitHub Container Registry during the training. The concepts are al
 
 ### 7. Cookieplone
 
-The latest version of {term}`Cookieplone` will be used, and it doesn’t require a separate installation as we’ll use `pipx`.
+The latest version of {term}`Cookieplone` will be used, and it doesn't require a separate installation as we'll use `pipx`.
 
 ### 8. Make
 

docs/plone-deployment/virtual-host.md

@@ -0,0 +1,123 @@
+---
+myst:
+  html_meta:
+    "description": "Virtual Hosting Services"
+    "property=og:description": "Understand how to use Zope infrastructure to rewrite URLs in run time."
+    "property=og:title": ""Virtual Hosting Services"
+    "keywords": "Plone, Deployment, Stack, Configuration, Guide, Virtual Host Monster, VHM"
+---
+
+# Virtual Hosting Services
+
+Zope comes with one object that helps you do virtual hosting: *Virtual Host Monster* (VHM). Virtual hosting is a way to serve many websites with one backend server.
+
+## Virtual Host Monster
+
+Zope objects need to generate their own URLs from time to time. For instance, when a Zope object has its "absolute_url" method called, it needs to return a URL which is appropriate for itself. This URL typically contains a hostname, a port, and a path. In a "default" Zope installation, this hostname, port, and path is typically what you want. But when it comes time to serve multiple websites out of a single Zope instance, each with their own "top-level" domain name, or when it comes time to integrate a Zope Folder within an existing website using Apache or another webserver, the URLs that Zope objects generate need to change to suit your configuration.
+
+A Virtual Host Monster's only job is to change the URLs which your Zope objects generate. This allows you to customize the URLs that are displayed within your Zope application, allowing an object to have a different URL when accessed in a different way. This is most typically useful, for example, when you wish to "publish" the contents of a single Zope Folder (e.g. `/FooFolder`) as a URL that does not actually contain this Folder's name (for example, as the hostname `www.foofolder.com`).
+
+The Virtual Host Monster performs this job by intercepting and deciphering information passed to Zope within special path elements encoded in the URLs of requests which come into Zope. If these special path elements are absent in the URLs of requests to the backend server, the Virtual Host Monster does nothing. If they are present, however, the Virtual Host Monster deciphers the information passed in via these path elements and causes your Zope objects to generate a URL that is different from their "default" URL.
+
+The Zope values which are affected by the presence of a Virtual Host Monster include `REQUEST` variables starting with `URL` or `BASE` (such as `URL1`, `BASE2`, or `URLPATH0`), and the `absolute_url()` methods of objects.
+
+Virtual Host Monster configuration can be complicated because it requires that you *rewrite* URLs "on the way in" to Zope. In order for the special path elements to be introduced into the URL of the request sent to Zope, a front-end URL "rewriting" tool needs to be employed. Virtual Host Monster comes with a simple rewriting tool in the form of its *Mappings* view, or alternately you can use Apache or another web server to rewrite URLs of requests destined to Zope for you.
+
+
+### Configuring the Virtual Host Monster
+
+The default mode for configuring the Virtual Host Monster is not to do any configuration at all! Rather, the external router or webserver modifies the request URL to signal what the *real* public URL for the request should be.
+
+If you *do* choose to change the settings of your VHM, the easiest method to do so is to use the VHM`s ZMI interface.
+
+### Special VHM Path Elements `VirtualHostBase` and `VirtualHostRoot`
+
+A Virtual Host Monster doesn't do anything unless it sees one of the following special path elements in a URL.
+
+#### `VirtualHostBase`
+
+If a Virtual Host Monster "sees" this name in the incoming URL, it causes {term}`Zope` objects to generate URLs with a potentially different protocol, a potentially different hostname, and a potentially different port number.
+
+#### `VirtualHostRoot`
+
+If a Virtual Host Monster "sees" this name in the incoming URL, it causes Zope objects to generate URLs that have a potentially different "path root."
+
+### `VirtualHostBase`
+
+The `VirtualHostBase` declaration is typically found at the beginning of an incoming URL. A Virtual Host Monster will intercept two path elements following this name and will use them to compose a new protocol, hostname, and port number.
+
+The two path elements which must follow a `VirtualHostBase` declaration are `protocol` and `hostname:portnumber`. They must be separated by a single slash. The colon and portnumber parts of the second element are optional, and if they don't exist, the Virtual Host Monster will not change the port number of Zope-generated URLs.
+
+Examples:
+
+-   If a VHM is installed and a request comes into your server with the following URL.
+
+    `http://backend:8080/VirtualHostBase/http/example.com`
+
+    URLs generated by Zope objects will start with `http://example.com:8080`.
+
+-   If a VHM is installed in the root folder, and a request comes into your server with the following URL.
+
+    `http://backend:8080/VirtualHostBase/http/example.com:80`
+
+    URLs generated by Zope objects will start with `http://example.com` (port 80 is the default port number, so it is left out).
+
+-   If a VHM is installed in the root folder, and a request comes into your Zope with the following URL.
+
+    `http://backend:8080/VirtualHostBase/https/example.com:443`
+
+    URLs generated by Zope objects will start with `https://example.com/` (port 443 is the default https port number, so it is left off).
+
+One thing to note when reading the examples above is that if your Zope is running on a port number like 8080, and you want generated URLs to not include this port number and instead be served on the standard HTTP port (80), you must specifically include the default port 80 within the VirtualHostBase declaration, for exemple, `/VirtualHostBase/http/example.com:80`. If you don't specify the `:80`, your Zope's HTTP port number will be used (which is likely not what you want).
+
+### `VirtualHostRoot`
+
+The `VirtualHostRoot` declaration is typically found near the end of an incoming URL. A Virtual Host Monster will gather up all path elements that *precede* and *follow* the `VirtualHostRoot` name, traverse the Zope object hierarchy with these elements, and publish the object it finds with the path rewritten to the path element(s) that *follow* the `VirtualHostRoot` name.
+
+This is easier to understand by example. For a URL `/a/b/c/VirtualHostRoot/d`, the Virtual Host Monster will traverse `a/b/c/d` and then generate a URL with path `/d`.
+
+Examples:
+
+-   If a VHM is installed in the root folder, and a request comes into your Zope with the following URL.
+
+    `http://backend:8080/Folder/VirtualHostRoot/`
+
+    The object `Folder` will be traversed to and published, and URLs generated by Zope will start with `http://backend:8080/`, and when they are visited, they will be considered relative to `Folder`.
+
+-   If a VHM is installed in the root folder, and a request comes into your Zope with the following URL.
+
+    `http://backend:8080/HomeFolder/VirtualHostRoot/Chris`
+
+    The object `/Folder/Chris` will be traversed to and published, URLs generated by Zope will start with `http://backend:8080/Chris`, and when they are visited, they will be considered relative to `/HomeFolder/Chris`.
+
+### Using `VirtualHostRoot` and `VirtualHostBase` Together
+
+The most common sort of virtual hosting setup is one in which you create a Folder in your Zope root for each domain that you want to serve. For instance, the site `https://example.com` is served from a Plone Site in the Zope root named /Plone while the site `https://example.org` is served from another Plone Site in the Zope root named `/OrgSite`. In order to do this, you need to generate URLs that have both `VirtualHostBase` and `VirtualHostRoot` in them.
+
+To access `/OrgSite` as `https://example.org`, you would cause Zope to be visited via the following URL.
+
+`/VirtualHostBase/https://example.org/OrgSite/VirtualHostRoot/`
+
+In the same Zope instance, to access `/Plone` as `https://example.com/`, you would cause Zope to be visited via the following URL.
+
+`/VirtualHostBase/https/example.com/Plone/VirtualHostRoot/`
+
+### Rewriting sub-paths
+
+Consider the following.
+
+-   `https://example.com` should have the object at `/Plone` (A Plone Site) as root.
+-   `https://example.org` should have the object at `/Plone/org` (A content with id `org` inside the Plone Site) as root.
+-   `https://example.com/ClassicUI` should point to the root object on Zope .
+
+The rewrite rule for `example.com` will be the following.
+
+`/VirtualHostBase/https/example.com/Plone/VirtualHostRoot/`
+
+The rewrite rule for `example.org` will be the following.
+
+`/VirtualHostBase/https/example.org/Plone/org/VirtualHostRoot/`
+
+The rewrite rule for `example.com/ClassicUI` will be the following.
+
+`/VirtualHostBase/https/example.com/VirtualHostRoot/_vh_ClassicUI/`