[Abdul-Muqadim-Arbisoft]

New plugin developers had no single place explaining what a patch is: the template patch catalog only lists the available patches, and the ENV_PATCHES filter documentation is very brief. The only conceptual explanation lived in the legacy v0 plugin API docs.

Add a "Template patches" page to the plugin development guide. It explains how {{ patch(...) }} statements work, how to add content to a patch with the ENV_PATCHES filter or with patch files, that patch content is rendered as a Jinja2 template, how indentation is handled, how multiple items are ordered (and how to use priorities), how to find and debug patches with tutor config patches list/show, and how plugins can create their own patches.

Link the new page from the plugin tutorial, the template patch catalog and the ENV_PATCHES and ENV_TEMPLATE_FILTERS docstrings. The catalog stays at reference/patches/index so that existing links to individual patches keep working.

This completes the work started in #852.
See: openedx/wg-devops#29

[Faraz32123]

Thanks, this fills a real gap for new plugin developers. I checked the content against the code (patch rendering, newline separator, priority order, tutor config patches list/show, the indent(2) example) and it's accurate; the docs also build cleanly with -n. LGTM, with a few optional nits:

1. "after you modify a patch, you should run tutor config save (or tutor local launch)": patches that go into Dockerfiles (openedx-dockerfile-*, mfe-dockerfile-*, …) also need tutor images build ... to take effect. Worth a sentence, since it's a common stumbling block.
2. In the indentation example, the content starts with a newline (""" + line break), which shows up as an empty line in the rendered file and in patches show. Harmless in YAML, but starting with """\ (or a short note) would avoid surprises.
3. Optionally, add a pointer from the legacy v0 patches section to this new page, so readers who land there find the current docs.

[Abdul-Muqadim-Arbisoft]

Thanks, this fills a real gap for new plugin developers. I checked the content against the code (patch rendering, newline separator, priority order, tutor config patches list/show, the indent(2) example) and it's accurate; the docs also build cleanly with -n. LGTM, with a few optional nits:

1. "after you modify a patch, you should run tutor config save (or tutor local launch)": patches that go into Dockerfiles (openedx-dockerfile-*, mfe-dockerfile-*, …) also need tutor images build ... to take effect. Worth a sentence, since it's a common stumbling block.
2. In the indentation example, the content starts with a newline (""" + line break), which shows up as an empty line in the rendered file and in patches show. Harmless in YAML, but starting with """\ (or a short note) would avoid surprises.
3. Optionally, add a pointer from the legacy v0 patches section to this new page, so readers who land there find the current docs.

Thanks @Faraz32123, all three addressed in 60a559d:

Added a sentence that Dockerfile patches (e.g. openedx-dockerfile-post-python-requirements) only take effect after tutor images build .... tutor local launch re-renders the Dockerfile but doesn't rebuild the image.
The indentation example now starts with """. Verified that patches show no longer starts with an empty line and docker-compose.yml no longer gets a whitespace-only line.
The legacy v0 patches section now links to the new page.