Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Compute per-document site-plan facts in staged page compilation

Open
  • Is something wrong?
#3,699 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

  • #3705 by @chubes4 — closed without merging

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
php, wordpress
Domain
backend, performance

Research direction

Start with WordPressSitePlan::fromCompilerInput and trace how staged page compilation creates its receipt and how compose consumes it. Identify which listed facts depend only on one compiled document, then compare with whole compilation to preserve equivalent behavior. Done means those facts are computed in parallel during staged compilation, compose consumes them, cross-route facts remain in compose, and output stays byte-identical.

Written by the indexing model from the issue text.

Description

Problem

Slice 2 of #2089. In compose, WordPressSitePlan::fromCompilerInput costs 138 s on a 112-page real import. Of that, the parts that are per document, with no cross-route input, are:

  • WordPressSitePlan::documents: 16 s
  • PresetBinding construction and bindStylesheet: 23 s
  • canonicalEntityBindings: 10 s

Expected

Facts that depend only on one compiled document (its plan document entry, preset bindings for its route-owned stylesheets, and canonical entity bindings) are computed in the staged page compile, which already runs in parallel workers. They are carried in the receipt, and compose consumes them. Whole compilation computes the same facts inline. Output stays byte-identical. Anything that turns out to depend on cross-route state stays in compose.

Dominant language
PHP
Stars
22
Forks
3
Avg merge
7h 3m
Merged PRs (30d)
779

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/blocks-engine

All issues in Automattic/blocks-engine

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.