Wire up Edit button for template-backed pages (blog index, archives)

[jakemgold]

Context

The popup's Edit button works for singular post types and resolvable terms / authors. For non-singular pages backed by templates or template parts — blog index, category and tag archives, post type archives, and similar — the button is currently disabled with placeholder labels:

• src/popup/lib/labels.js:20 → 'Edit Archive (Coming Soon)' for pageType === 'archive'
• src/popup/lib/labels.js:21 → 'Edit Homepage (Coming Soon)' for pageType === 'home'

lib/detect.js already classifies these correctly via pageType; the gap is that we don't yet resolve them to an editable destination.

What needs to work

WordPress block themes (6.0+) render these views from templates and template parts editable in the site editor:

/wp-admin/site-editor.php?postType=wp_template&postId={theme}//{template_slug}

Behavior we want:

Theme type	Page type	Result
Block theme	blog index / archive / etc.	Edit button enabled → site editor deep link to the matching template
Block theme	template not resolvable	Keep disabled with a clearer label (no false promise)
Classic theme	any non-singular	Keep disabled — the template is a PHP file, the popup is not the right surface
Static front page configured (Settings → Reading → A static page)	homepage	Already works today (singular page); no change
Posts-page configured (Settings → Reading → Posts page)	the page named as Posts page	Already works today (singular page); no change

Implementation sketch

Three pieces, in order of dependency:

1. Detect block-theme vs. classic-theme. Server-side this is wp_is_block_theme(). From the frontend: REST has signals (/wp/v2/themes exposes a is_block_theme field for the active theme; /wp/v2/global-styles exists only on block themes), and some block themes emit a wp-block-theme body class or specific stylesheet links. Pick a primary signal and at least one fallback.

2. Detect the active template / template-part name. Block themes set deterministic templates per view (e.g. archive, category, category-{slug}, home, front-page, index). REST has /wp/v2/templates which lists registered templates with slugs; matching the current view to a template can be done by checking current_template signals if exposed, otherwise inferring from pageType + taxonomy / postType context already on ctx. A <link rel="alternate" type="application/json"> or generator meta sometimes carries this.

3. Construct the edit URL. Once theme slug and template slug are known, build the site-editor deep link. The theme slug is already detected (`ctx.themeSlug`); the template slug comes from step 2.

Out of scope

• Editing classic-theme template files. They're PHP and the popup is not the right tool.
• Pre-block-editor "Customize" deep links for legacy widget areas. Different surface.

Done when

• On a block theme, the Edit button is enabled on at least the common cases: blog home (pageType === 'home') and category archive (pageType === 'archive', taxonomy === 'category'). Pressing it lands the user on the correct template in the site editor.
• On a classic theme, the Edit button stays disabled. The label is honest about why (not "Coming Soon").
• Smoke tests cover the block-theme detection signal and the template-slug resolution for at least one archive variant and the blog-index case.