Force visibility to password when editing a post in quick edit.

[Hug0-Drelon]

Visibility is never set for password when using quick edit, thus edit_post() cannot unset sticky status in https://github.com/WordPress/wordpress-develop/blob/6.9.1/src/wp-admin/includes/post.php#L308-L322.

Looking at it, I thought that wp_ajax_inline_save() would handle that like it does for private status. But it might be dead code around https://github.com/WordPress/wordpress-develop/blob/6.9.1/src/wp-admin/includes/ajax-actions.php#L2117-L2122.
Removing it doesn't affect the feature (remove sticky status when a post is private).

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

---

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.

[github-actions]

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.

Core Committers: Use this line as a base for the props when committing in SVN:

Props hugod, wildworks, abcd95, motylanogha.

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

[github-actions]

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.

[Copilot]

Pull request overview

Ensures Quick Edit requests correctly treat posts with a post_password as “password-protected” visibility so that edit_post() applies the existing visibility handling (notably unsetting sticky) for password-protected posts.

Changes:

• In edit_post(), infer visibility = 'password' when post_password is present in the incoming post data.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[himanshupathak95]

Hi @Hug0-Drelon, do you have the bandwidth to address the reviews and add some test coverage for this PR?

[wppoland]

The ticket carries needs-unit-tests, added by @wildworks in comment:6 ("a PR review is needed, but it appears to be missing unit tests at a minimum"), and this PR is fix-only, so here's a regression test for it.

It reproduces Quick Edit's actual payload: sticky is posted, visibility is not. On trunk the case 'password' branch in edit_post() is never reached, so the unset( $post_data['sticky'] ) never happens and the post stays sticky with a password set. With this PR the inferred visibility reaches that branch and the post is unstuck.

	/**
	 * Ensures that giving a sticky post a password through edit_post() unsticks it,
	 * even when the caller never sends an explicit `visibility` value.
	 *
	 * The block editor sends `visibility`, so `edit_post()` reaches the
	 * `case 'password'` branch and drops the `sticky` flag. Quick Edit never sends
	 * it, so a post could end up both sticky and password protected, a combination
	 * the editor itself forbids.
	 *
	 * @ticket 64810
	 *
	 * @covers ::edit_post
	 */
	public function test_edit_post_unsticks_a_post_when_a_password_is_set_without_visibility() {
		wp_set_current_user( self::$admin_id );

		$post_id = self::factory()->post->create(
			array(
				'post_status' => 'publish',
				'post_author' => self::$admin_id,
			)
		);

		stick_post( $post_id );
		$this->assertTrue( is_sticky( $post_id ), 'The post was not sticky to begin with: check test setup.' );

		// Mirrors Quick Edit, which posts `sticky` but no `visibility`.
		edit_post(
			array(
				'post_ID'       => $post_id,
				'post_title'    => 'Protected and sticky',
				'post_status'   => 'publish',
				'post_password' => 'secret',
				'sticky'        => 'sticky',
			)
		);

		$this->assertSame(
			'secret',
			get_post( $post_id )->post_password,
			'The password was not saved: check test setup.'
		);
		$this->assertFalse(
			is_sticky( $post_id ),
			'A password protected post was left sticky when no explicit visibility was sent.'
		);
	}

It goes in tests/phpunit/tests/admin/includesPost.php, which had no coverage of the visibility/sticky/password interaction at all.

Verified against a local build:

trunk:            Failures: 1  ("A password protected post was left sticky when no explicit visibility was sent.")
trunk + this PR:  OK (1 test, 3 assertions)

Whole file still green with the patch applied: 52 tests, 118 assertions, 0 failures (6 warnings, all pre-existing PHPUnit 10 deprecation notices in test_post_exists_*).

Also attached to the ticket as 64810-tests.diff. Take it into this branch if it helps, no attribution needed.

[wppoland]

Rather than leave the test as a paste, I've opened it as a commit against this branch: Hug0-Drelon#1.

Merging it there brings the test into this PR so the fix and its coverage land as one changeset, and nothing else on your side changes. The fix stays yours; I only wrote the test.