Block editor: ensure meta data is saved before publishing.

[jeherve]

Proposed changes:

This solves federation issues for some posts, on sites using other plugins that may update post meta right before post publication, like Jetpack and its newsletter feature.

In this scenario, we would run into the following error that was blocking federation:

Publishing failed. Could not update the meta value of activitypub_content_warning in database.

In order to fix this, we ensure that the content warning meta is properly saved upon publication.

Other information:

Internal reference: p1749025385229489-slack-C04TJ8P900J

• Have you written new tests for your changes, if applicable?

Testing instructions:

This is better tested on a site where the Jetpack plugin is installed, connected to WordPress.com, and where you've toggled the Newsletter feature on. All WordPress.com simple sites satisfy those requirements.

1. Go to Posts > Add New
2. Write a new post with some ActivityPub content, such as a Federated reply block with any ActivityPub-compatible content like https://mastodon.social/@pfefferle/114502331086451476.
3. Hit Publish
4. Before to confirm publication, check the Newsletter panel, and change the value to "Post only".
5. Hit Publish.
   • The post should be published with no errors.
   • You should see a Create event in the outbox.

Changelog entry

• Automatically create a changelog entry from the details below.

Changelog Entry Details

Significance

• Patch
• Minor
• Major

Type

• Added - for new features
• Changed - for changes in existing functionality
• Deprecated - for soon-to-be removed features
• Removed - for now removed features
• Fixed - for any bug fixes
• Security - in case of vulnerabilities

Message

[Copilot]

Pull Request Overview

This PR ensures that post metadata (like content warnings) is saved via the block editor before publishing to avoid federation errors when other plugins update meta immediately before publication.

• Adds a reusable useSetMeta hook for updating post meta
• Replaces direct useEntityProp/useSelect usage with named imports and handlers
• Updates preview/select calls to use the aliased editorStore

Reviewed Changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/editor-plugin/plugin.js	Introduce useSetMeta hook; swap to editorStore
build/editor-plugin/plugin.js	Mirror hook changes in the built output
build/editor-plugin/plugin.asset.php	Bump asset version
.github/changelog/fix-conflict-sidebar-meta-updates	Add changelog entry

Comments suppressed due to low confidence (3)

src/editor-plugin/plugin.js:31

• The new useSetMeta hook introduces logic for meta updates but lacks unit or integration tests. Consider adding tests to verify that updating meta values persists as expected.

function useSetMeta( metaKey, postType ) {

src/editor-plugin/plugin.js:32

• The hook useEntityProp is used but not imported. Add import { useEntityProp } from '@wordpress/core-data'; at the top of the file.

const [ meta, setMeta ] = useEntityProp( 'postType', postType || 'default', 'meta' );

src/editor-plugin/plugin.js:47

• The useSelect hook is used but not imported. Add import { useSelect } from '@wordpress/data'; at the top of the file.

const postType = useSelect( ( select ) => select( editorStore ).getCurrentPostType(), [] );

[obenland]

Can we use the setter functions in the onChange handlers directly? I'm not sure the wrappers are needed? The setters' function names are also less ambiguous.

[obenland]

I did some more debugging last night, after I was finally able to reproduce the bug. It felt odd to me that it was only activitypub_content_warning that failed to update, and not all the other meta values that get saved in a similar way, too. I looked at the meta registration and noticed the sanitation callback for activitypub_content_warning returns two data types, a string when there is a value, otherwise null, while update_metadata includes this bit that compares incoming values with existing ones with a strict comparison.
I wasn't able to debug further, but changing the sanitization callback to sanitize_text_field as attempted in #1766 fixes that bug for me. Should we try that first?

[jeherve]

changing the sanitization callback to sanitize_text_field as attempted in #1766 fixes that bug for me. Should we try that first?

It fixed it for me too. Let's ship it!

I'll close this PR for now.