Editor: Guard PostViewLink against post types without a labels object by Mayank-Tripathi32 · Pull Request #79160 · WordPress/gutenberg

Mayank-Tripathi32 · 2026-06-12T17:02:00Z

Do not merge yet, largely still testing.

What?

Stops PostViewLink from crashing when the current post type is registered without a labels object (e.g. wp_template_part, or custom post types declared without the labels arg). The button now falls back to the default View post label instead.

Why?

packages/editor/src/components/post-view-link/index.js:27 read postType?.labels.view_item. The ?. only short-circuits on postType, so if postType is defined but postType.labels is undefined, accessing .view_item throws TypeError: Cannot read properties of undefined. The reporter hit this on a custom theme; @JNBG also identified wp_template_part as a real-world post type that lacks labels / supports.

How?

PostViewLink: extend the optional chain to postType?.labels?.view_item so a missing labels object falls through to the existing || __( 'View post' ) fallback.
Add a unit test suite for PostViewLink (none existed) covering the regression and the happy path / hidden states.
Add a regression test in PostTypeSupportCheck confirming it already returns null (via the supports = {} default) when the post type has no supports argument — this was the second symptom in the report.

Testing Instructions

npm run test:unit packages/editor/src/components/post-view-link
npm run test:unit packages/editor/src/components/post-type-support-check
Manual: in a plugin, register a post type without the labels argument, then open it in the editor — the View button should display "View post" instead of crashing the editor.

Testing Instructions for Keyboard

No interaction changes.

AI

Yes, Claude

github-actions · 2026-06-12T17:02:13Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: Mayank-Tripathi32 <[email protected]>
Co-authored-by: Mamaduka <[email protected]>
Co-authored-by: JNBG <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

Mayank-Tripathi32 · 2026-06-12T17:07:10Z

While working on this I grepped for the same pattern and found the optional chain stops short of labels in a few more places, so they'd hit the same TypeError for a post type whose REST response has no labels:

packages/editor/src/components/post-url/index.js (L61) — postType?.labels.view_item
packages/block-library/src/post-date/edit.js (L213, L226) — postType?.labels.singular_name
packages/block-library/src/post-featured-image/edit.js (L269, L273) — postType?.labels.singular_name
packages/editor/src/components/post-card-panel/index.js (L171) — labels?.name.toLowerCase() (labels is guarded but .name isn't)

For context on when labels is actually missing: it's only exposed on the post-types REST schema in the edit context, so it's undefined whenever a type renders in the editor without its edit-context labels (custom/re-registered post types, capability edge cases) — i.e. the same situation reported here. Stock post/page with full edit caps are unaffected, which is why these don't surface on the common path.

I can extend this PR to guard all of them (it's the same one-character ?. fix in each), once we confirm path forward as these are not affecting directly.

Mamaduka · 2026-06-13T03:53:58Z

+				// Guard against post types that don't expose `labels` (e.g.
+				// `wp_template_part` or custom post types registered without
+				// the `labels` argument). Falling back to the default
+				// translatable label below.
+				label: postType?.labels?.view_item,


I think the inline comment here isn't needed.

Mamaduka · 2026-06-13T03:54:40Z

+jest.mock( '@wordpress/data/src/components/use-select', () => {
+	// Allow tweaking the returned data on each test.
+	const mock = jest.fn();
+	return mock;
+} );


We can just return jest.fn(), no need for variable assignment or inline comment.

Mamaduka · 2026-06-13T03:55:41Z

+		// Regression test for #62918: some custom post types are registered
+		// without a `labels` object (e.g. `wp_template_part`). Accessing
+		// `labels.view_item` on those used to throw.


Similarly, we can drop the inline comment and just link to the issue.

Mamaduka · 2026-06-13T03:56:06Z

+		// Regression test for #62918: some custom post types (e.g.
+		// `wp_template_part`) are registered without a `supports` argument,
+		// so `postType.supports` is undefined.


Same, no inline comment is needed. The test description should be enough.

Remove the inline comments added in this PR per review, and collapse the use-select jest.mock factory to a direct `() => jest.fn()`. No functional change; both test suites still pass.

Mayank-Tripathi32 · 2026-06-15T16:43:31Z

While working on this I grepped for the same pattern and found the optional chain stops short of labels in a few more places, so they'd hit the same TypeError for a post type whose REST response has no labels:

packages/editor/src/components/post-url/index.js (L61) — postType?.labels.view_item

packages/block-library/src/post-date/edit.js (L213, L226) — postType?.labels.singular_name

packages/block-library/src/post-featured-image/edit.js (L269, L273) — postType?.labels.singular_name

packages/editor/src/components/post-card-panel/index.js (L171) — labels?.name.toLowerCase() (labels is guarded but .name isn't)

For context on when labels is actually missing: it's only exposed on the post-types REST schema in the edit context, so it's undefined whenever a type renders in the editor without its edit-context labels (custom/re-registered post types, capability edge cases) — i.e. the same situation reported here. Stock post/page with full edit caps are unaffected, which is why these don't surface on the common path.

I can extend this PR to guard all of them (it's the same one-character ?. fix in each), once we confirm path forward as these are not affecting directly.

@Mamaduka I have addressed the comments, do you have any input on this?

Mamaduka · 2026-06-15T16:59:37Z

@Mayank-Tripathi32, those need to be checked case by case. I viewed a couple of listed files, and they're calling getPostType( postType ) and those requests are made in context=edit by default.

labels - even if the post type doesn't declare custom labels, default values will be provided.
support - similar here, post type will have more than one flag if it's available in the editor and via the REST API.

Happy to check again, if you've reproduction steps on how those components can trigger an error for a user.

Mamaduka · 2026-06-16T04:12:14Z

I guess extra checks don't cost anything, but as I said, I don't think they're needed without actual reproduction steps.

Mamaduka

Let's merge this. If you find more cases like this, please create an issue with reproduction steps before moving forward.

Thanks, @Mayank-Tripathi32!

Mayank-Tripathi32 · 2026-06-16T17:33:01Z

Thanks.

Editor: Guard PostViewLink against post types without a labels object

a520a0d

github-actions Bot added the [Package] Editor /packages/editor label Jun 12, 2026

Merge branch 'trunk' into fix/62918-post-view-link-undefined-labels

3c49951

Mamaduka added the [Type] Bug An existing feature does not function as intended label Jun 13, 2026

Mamaduka requested changes Jun 13, 2026

View reviewed changes

Address review feedback: drop explanatory inline comments

8f34a68

Remove the inline comments added in this PR per review, and collapse the use-select jest.mock factory to a direct `() => jest.fn()`. No functional change; both test suites still pass.

Editor: Guard remaining post-type label accesses against missing labels

30e8a1f

Mayank-Tripathi32 requested review from ajitbohra and fabiankaegy as code owners June 15, 2026 20:50

github-actions Bot added the [Package] Block library /packages/block-library label Jun 15, 2026

Mamaduka approved these changes Jun 16, 2026

View reviewed changes

Mamaduka merged commit 6cf51dc into WordPress:trunk Jun 16, 2026
42 checks passed

github-actions Bot added this to the Gutenberg 23.5 milestone Jun 16, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Editor: Guard PostViewLink against post types without a labels object#79160

Editor: Guard PostViewLink against post types without a labels object#79160
Mamaduka merged 4 commits into
WordPress:trunkfrom
Mayank-Tripathi32:fix/62918-post-view-link-undefined-labels

Mayank-Tripathi32 commented Jun 12, 2026 •

edited

Loading

Uh oh!

github-actions Bot commented Jun 12, 2026 •

edited

Loading

Uh oh!

Mayank-Tripathi32 commented Jun 12, 2026

Uh oh!

Mamaduka Jun 13, 2026

Uh oh!

Mamaduka Jun 13, 2026

Uh oh!

Mamaduka Jun 13, 2026

Uh oh!

Mamaduka Jun 13, 2026

Uh oh!

Mayank-Tripathi32 commented Jun 15, 2026

Uh oh!

Mamaduka commented Jun 15, 2026

Uh oh!

Mamaduka commented Jun 16, 2026

Uh oh!

Mamaduka left a comment

Uh oh!

Uh oh!

Mayank-Tripathi32 commented Jun 16, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

Mayank-Tripathi32 commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Testing Instructions for Keyboard

AI

Uh oh!

github-actions Bot commented Jun 12, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mayank-Tripathi32 commented Jun 12, 2026

Uh oh!

Mamaduka Jun 13, 2026

Choose a reason for hiding this comment

Uh oh!

Mamaduka Jun 13, 2026

Choose a reason for hiding this comment

Uh oh!

Mamaduka Jun 13, 2026

Choose a reason for hiding this comment

Uh oh!

Mamaduka Jun 13, 2026

Choose a reason for hiding this comment

Uh oh!

Mayank-Tripathi32 commented Jun 15, 2026

Uh oh!

Mamaduka commented Jun 15, 2026

Uh oh!

Mamaduka commented Jun 16, 2026

Uh oh!

Mamaduka left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Mayank-Tripathi32 commented Jun 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Mayank-Tripathi32 commented Jun 12, 2026 •

edited

Loading

github-actions Bot commented Jun 12, 2026 •

edited

Loading

Mayank-Tripathi32 commented Jun 16, 2026 •

edited

Loading