wordpress.studio

The website for WordPress Studio, built with Studio Code, and the source of its homepage video.

• The repository root is the site's folder: the studio block theme, the studio-docs plugin, the uploads, the SQLite database and DESIGN.md. WordPress core is not tracked, because Studio installs it when it creates a site.
• video/ is the Remotion project behind the homepage video.

Load the site in Studio

You need WordPress Studio, either the app or the CLI (npm install -g wp-studio).

Studio only adds a folder that is empty or already holds a full WordPress install, so you first create a blank site, then check this repository out into its folder.

With the Studio app

1. Click Add site, then Blank site. Name it WordPress Studio, open Advanced settings and set Local path to ~/Studio/studio-website. Leave What should we create? empty and click Create site.

2. Stop the site from its menu in the sidebar.

3. In a terminal, check the repository out into the site's folder:

   cd ~/Studio/studio-website
   git init -b main
   git remote add origin https://github.com/Automattic/studio-website.git
   git fetch origin
   git checkout -f -B main --track origin/main
   

4. Start the site again in Studio. Its pages, theme and media are now the ones from this repository.

With the CLI

studio site create --path ~/Studio/studio-website --name "WordPress Studio" --start=false
cd ~/Studio/studio-website
git init -b main
git remote add origin https://github.com/Automattic/studio-website.git
git fetch origin
git checkout -f -B main --track origin/main
studio site start

git checkout -f replaces the blank site's database and theme with the ones in this repository. Studio keeps its own files (wp-config.php, wp-content/db.php, wp-content/mu-plugins/, STUDIO.md), which are ignored.

To log in to WP Admin, use Studio: Open in… → WP Admin in the app, or studio site status for the admin password.

Working on the site

Ask Studio Code (in the app, or studio code in the site's folder) for changes, then commit them. DESIGN.md describes the design system; follow it for any design or content change.

The content lives in one SQLite file, wp-content/database/.ht.sqlite. Git can version it but not merge it: stop the site before you pull or commit, and when two people change content, the last commit wins.

The docs

The Studio documentation at wordpress.studio/docs is WordPress too: the docs post type of the studio-docs plugin (wp-content/plugins/studio-docs), rendered by the theme's single-docs template and its docs header and footer parts, built from core blocks and the plugin's blocks (code, callout, navigation, table of contents, search, …), so the pages and the templates open in the block editor and the Site Editor like the rest of the site. The markdown is not edited here. Its source of truth is docs/user/docs/ in the Studio repository, so the docs evolve with the code and ship with each release; the site imports it at build time and the posts are build output (the database is not committed).

npm install                            # once: Shiki, for the code highlighting
node scripts/build-docs-manifest.mjs   # stage the markdown and screenshots into build/docs/
studio wp wp-docs import --force       # import them into the docs post type

scripts/build-docs-manifest.mjs checks the Studio repository's docs/user/docs and docs/user/screenshots/images out (from trunk; set STUDIO_DOCS_REF to pin another revision), places each page in the sidebar defined in its PAGES list (a markdown file upstream that is not in the list is reported at every build and stays off the site until it is added; working notes go in NOT_PAGES), records the revision it staged in build/docs/source.json, cleans up what the markdown carried over from developer.wordpress.com (heading links, linked images, absolute links, command lines without code fences), highlights every code block with Shiki (github-light / github-dark, the same themes as before) and writes build/docs/manifest.json for the importer. wp wp-docs import turns the pages into blocks, sideloads the screenshots once per content hash into wp-content/uploads/docs/ (ignored), and keeps each page's Markdown for /docs/<page>.md, /docs/llms.txt, /docs/llms-full.txt, /docs/index.json and the search index at /docs/search-index.json. wp wp-docs status shows what is imported and from which revision, and whether any page was edited in WordPress since; wp wp-docs convert <file.md> prints the blocks for one file. The plugin's README describes the blocks and the pipeline; php tests/run-fixtures.php and php tests/run-unit.php in the plugin folder test the conversion without a database.

Edits made in WordPress

The pages open in the block editor like any post, but the import rewrites every page, so an edit made there is live on the next deploy and gone on the one after the next import. The importer records a hash of every page it writes; a page that no longer matches has drifted:

npm run docs:drift                      # the pages edited in WordPress: what changed, by whom, when (exit 1 when any)
npm run docs:drift -- --diff            # each edit as a Markdown diff against the file the page was imported from
npm run docs:reconcile                  # write the edits back onto Automattic/studio trunk and show the diff (dry run)
npm run docs:reconcile -- --pr          # the same, then push a branch and open the pull request with gh
npm run docs:drift -- --reset           # discard the edits (asks first): re-import the pages from the staged files

以上为 README 的开头部分。其余内容请阅读原文。 查看完整 README ↗