Skip to content

Fix map_meta_cap notice by deferring migration until post types are registered - #3639

Open
faisalahammad wants to merge 1 commit into
Automattic:trunkfrom
faisalahammad:fix/3332-migration-cpt-order
Open

Fix map_meta_cap notice by deferring migration until post types are registered#3639
faisalahammad wants to merge 1 commit into
Automattic:trunkfrom
faisalahammad:fix/3332-migration-cpt-order

Conversation

@faisalahammad

Copy link
Copy Markdown

Fixes #3332

Proposed changes:

  • Defer Migration::maybe_migrate to init priority 20 so migration runs after ActivityPub's custom post types are registered at priority 11. On fresh installs the old priority-1 timing inserted extra-field posts before the ap_extrafield CPTs existed, which fired a WordPress map_meta_cap _doing_it_wrong notice.

Other information:

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

Testing instructions:

  • Activate the plugin on a fresh install
  • Confirm no map_meta_cap "post type is not registered" PHP notice appears during migration
  • Confirm the default "Powered by" extra-field post is created for the blog actor
  • Run the focused migration tests: npm run env-test -- --filter=class-test-migration

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

Fixed a PHP notice that could appear when ActivityPub migration ran before custom post types were registered.

Migration::init runs at init priority 1, before ActivityPub's custom post
types are registered at init priority 11. On fresh installs this caused
maybe_migrate to insert extra-field posts before the ap_extrafield CPTs
existed, triggering a map_meta_cap doing_it_wrong notice.

Defer maybe_migrate to init priority 20 (after CPT registration at 11).
Scheduler callback registration stays synchronous at priority 1 because
register_async_batch_callback warns if called after init.

Fixes Automattic#3332
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Did ap_outbox behaviour change?

1 participant