Title: Set up Reprint development
Published: November 3, 2026

---

# Set up Reprint development

## In this article

 * [Set up a checkout](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#set-up-a-checkout)
 * [Find the code](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#find-the-code)
 * [Test a change](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#test-a-change)
 * [Prepare a pull request](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#prepare-a-pull-request)
 * [Change documentation](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#change-documentation)
 * [Prepare a release](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#prepare-a-release)

Use this guide to run Reprint from a checkout, test a change, and prepare a pull
request. You need Git, command-line PHP, and Composer. Read the [repository working rules](https://github.com/WordPress/reprint/blob/trunk/AGENTS.md)
before changing code or documentation.

## 󠀁[Set up a checkout](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#set-up-a-checkout)󠁿

Use PHP 8.1 or newer for the development tools and PHPUnit. Install Composer and
the PHP extensions required by [composer.json](https://github.com/WordPress/reprint/blob/trunk/composer.json).
Docker is needed for the end-to-end tests.

    ```language-sh
    git clone --recurse-submodules https://github.com/WordPress/reprint.git
    cd reprint
    composer install
    ```

For an existing checkout, run `git submodule update --init --recursive` first. Composer
links the local client and server packages into `vendor/`, so root tests use the
code you edit under `packages/`. Build the client and check that it runs:

    ```language-sh
    composer build:phar
    php reprint.phar --version
    ```

Run `composer build:phar` again after changing client code or its dependencies.

The WordPress plugin keeps a copied server package instead. Before your first plugin
test, install its dependencies:

    ```language-sh
    composer --working-dir=reprint-server-wp install
    ```

After changing server code under `packages/`, refresh that plugin copy:

    ```language-sh
    composer --working-dir=reprint-server-wp reinstall wp-php-toolkit/reprint-server
    ```

Without that refresh, a test of the plugin bundle may run the old server code.

## 󠀁[Find the code](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#find-the-code)󠁿

  |  Path |  Purpose |  
   |  `packages/reprint-client` |  Client package, CLI, pull workflows, and local runtime setup. |  
 |  `packages/reprint-server` |  Server API, database export, and file transfer implementation. |  
 |  `reprint-server-wp` |  WordPress plugin, settings UI, and self-contained distribution. |  
 |  `tests` |  PHPUnit tests and static-analysis support. |  
 |  `tests/e2e` |  Docker and Playground end-to-end tests. |  
 |  `bin` |  Build and version-stamping tools. |  
 |  `lib/sqlite-database-integration` |  SQLite integration submodule and SQL parser. |  
 |  `docs/handbook` |  Public documentation, listed in `docs/manifest.json`. |  
 |  `docs/contributing` |  Contributor guides and protocol reference. The manifest selects which pages are published. |

The client and server are separate Composer packages, `wp-php-toolkit/reprint-client`
and `wp-php-toolkit/reprint-server`. For embedding details, read the [client package](https://github.com/WordPress/reprint/blob/trunk/packages/reprint-client/README.md)
and [server package](https://github.com/WordPress/reprint/blob/trunk/packages/reprint-server/README.md)
guides.

## 󠀁[Test a change](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#test-a-change)󠁿

Run focused tests from the test directory:

    ```language-sh
    cd tests
    ../vendor/bin/phpunit HandbookManifestTest.php
    cd ..
    composer analyze -- --memory-limit=1G
    git diff --check
    ```

Use the test file for the behavior you changed. Run `composer test` for the PHPUnit
suite. The [admin UI test guide](https://github.com/WordPress/reprint/blob/trunk/tests/e2e/admin-ui/README.md)
and [end-to-end test configuration](https://github.com/WordPress/reprint/blob/trunk/tests/e2e/package.json)
cover the browser and migration tests. Tests that use MySQL need the database described
in [CLAUDE.md](https://github.com/WordPress/reprint/blob/trunk/CLAUDE.md).

Use `composer lint:php` for WordPress coding standards and `composer lint:php:compat`
for the supported PHP syntax. Existing per-file violation counts must not increase.
New code must keep the package’s minimum PHP version; push’s PHP 8.1 client requirement
is a runtime check.

## 󠀁[Prepare a pull request](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#prepare-a-pull-request)󠁿

Choose one change that a reviewer can test on its own. Explain what a user or caller
could do before and what they can do after the change. Include steps that reproduce
the problem or demonstrate the new behavior.

Add a test for the behavior you changed. For a resume change, stop the operation
at the boundary you changed, start a new process, and check that it neither skips
unfinished work nor applies completed work twice. The [architecture guide](https://developer.wordpress.org/reprint/contributing/architecture/)
explains how files, indexes, and database progress fit together.

Update the relevant handbook page when command options, results, or limits change.
Open the pull request in the [development repository](https://github.com/WordPress/reprint).

## 󠀁[Change documentation](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#change-documentation)󠁿

Edit the Markdown source under `docs/`. Link to other handbook pages with their 
complete website URLs, including any section anchor. For a new handbook page, add
its title, slug, source file, parent, and order to `docs/manifest.json`, and link
it from the relevant section. Put content pages under one of the six chapter groups.
Their URLs use `/reprint/SECTION/SLUG/` on developer.wordpress.org; the handbook
home and section pages have no parent.

Keep links to repository-only files and external resources as complete HTTPS URLs.
The root README and CONTRIBUTING links stay relative for GitHub.

Run `HandbookManifestTest.php` after changing links or page structure. It checks
that links name published pages, contributor pages are included, and every page 
can be reached from the handbook home. For importer registration and deployment,
see the [publishing plan](https://github.com/WordPress/reprint/blob/trunk/docs/contributing/publishing.md).

## 󠀁[Prepare a release](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#prepare-a-release)󠁿

Follow [Releasing Reprint](https://developer.wordpress.org/reprint/contributing/releases/)
when publishing a stable version or updating plugin-directory screenshots.

First published

November 3, 2026

Last updated

November 3, 2026

Edit article

[ Improve it on GitHub: Set up Reprint development ](https://raw.githubusercontent.com/WordPress/reprint/trunk/docs/contributing/development.md)

Changelog

[ See list of changes: Set up Reprint development ](https://developer.wordpress.org/reprint/contributing/development/?output_format=md#)

[  Previous: Contribute to Reprint](https://developer.wordpress.org/reprint/contributing/)

[  Next: Architecture and durable state](https://developer.wordpress.org/reprint/contributing/architecture/)