Skip to content

Enhance WP_REST_Posts_Controller with writable PreparedPost and static analysis fixes#11336

Draft
westonruter wants to merge 16 commits intoWordPress:trunkfrom
westonruter:fix/rest-posts-controller-phpstan
Draft

Enhance WP_REST_Posts_Controller with writable PreparedPost and static analysis fixes#11336
westonruter wants to merge 16 commits intoWordPress:trunkfrom
westonruter:fix/rest-posts-controller-phpstan

Conversation

@westonruter
Copy link
Member

This primarily is for fixing calls to wp_unique_post_slug() in \WP_REST_Posts_Controller::create_item() and \WP_REST_Posts_Controller::update_item(). However, as part of that I also looked at WP_REST_Posts_Controller::prepare_item_for_database() and all methods that called it to ensure that they also had their static analysis issues addressed. I don't intend to commit this entire PR as-is. Subsets would be committed at a time, ideally with tests to catch the holes identified by static analysis

Trac ticket: https://core.trac.wordpress.org/ticket/64921

Use of AI Tools


This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.

westonruter and others added 16 commits March 23, 2026 12:41
PHPStan treats object{} shape properties as read-only by default.
Since prepare_item_for_database() returns a stdClass that callers
mutate (e.g. setting post_type, post_name), the PreparedPost type
needs to be intersected with stdClass to indicate properties are
writable.

See: phpstan/phpstan#10079
See: https://phpstan.org/writing-php-code/phpdoc-types

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@github-actions
Copy link

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

  • All changes will be lost when closing a tab with a Playground instance.
  • All changes will be lost when refreshing the page.
  • A fresh instance is created each time the link below is clicked.
  • Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
    it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant