WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#29847 closed defect (bug) (fixed)

get_default_post_to_edit() stomps on assigned post_name

Reported by: danielbachhuber Owned by: boonebgorges
Milestone: 4.1 Priority: normal
Severity: normal Version: 3.0
Component: Posts, Post Types Keywords: has-patch commit
Focuses: Cc:

Description

When creating a new post, I'm assigning a secure post_name via the wp_insert_post_data filter:

/*
 * Generate a secure hash for our responses
 */
add_filter( 'wp_insert_post_data', function( $post_data ){

	if ( 'my_post_type' !== $post_data['post_type'] ) {
		return $post_data;
	}

	if ( empty( $post_data['post_name'] ) ) {

		$secure_hash_values = array();
		foreach( array( 'AUTH_KEY', 'SECURE_AUTH_KEY', 'LOGGED_IN_KEY', 'NONCE_KEY', 'AUTH_SALT', 'SECURE_AUTH_SALT', 'LOGGED_IN_SALT', 'NONCE_SALT' ) as $constant ) {
			if ( defined( $constant ) ) {
				$secure_hash_values[] = constant( $constant );
			}
		}

		$secure_hash_values[] = time();
		shuffle( $secure_hash_values );
		$post_data['post_name'] = hash( 'sha256', serialize( $secure_hash_values ) );
	}

	return $post_data;
});

get_default_post_to_edit() stomps on my post_name in post-new.php context because it blindly resets the value in the database.

This hack properly resets the post object from database:

/*
 * Hack to restore the post_name that get_default_post_to_edit() noops
 * Our assigned post_name via wp_insert_post_data can get fubar on post-new.php
 *
 * @see https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/post.php#L588
 */
add_filter( 'post_updated_messages', function( $messages ) {
	global $pagenow, $post;
 
	if ( 'post-new.php' == $pagenow && empty( $post->post_name ) ) {
		$post = get_post( $post->ID );
	}
	return $messages;
});

Attachments (1)

29847.1.diff (620 bytes) - added by danielbachhuber 6 years ago.
Relocate post_name declaration

Download all attachments as: .zip

Change History (5)

@danielbachhuber
6 years ago

Relocate post_name declaration

#1 @ocean90
6 years ago

  • Version set to 3.0

Related [12987].

#2 @boonebgorges
6 years ago

  • Keywords commit added

I've looked back over the logs and the related tickets and I can't see a reason why a special exception was made for 'post_name'. Maybe the auto-draft cleanup routine once had a 'WHERE post_name = ''' clause? Or maybe there are some other post-related queries that would get tripped up by a non-empty 'post_name' on auto-drafts? If so, I'd call it a separate bug. 29847.1.diff seems fine to me.

#3 @boonebgorges
6 years ago

  • Owner set to boonebgorges
  • Resolution set to fixed
  • Status changed from new to closed

In 30626:

In get_default_post_to_edit(), let 'post_name' be passed to filter.

Previously, it was being overridden after the default post had been inserted
into the database, making it cumbersome to override with the 'wp_insert_post_data'
filter.

Props danielbachhuber.
Fixes #29847.

#4 @nacin
6 years ago

I remember digging through this when this ticket first came up (or maybe on Twitter, in IRC, etc.), and came to the same conclusion, that this was fine to change.

What I suspect happened is post_name was set to '' during the development of [12987], because before the changes to wp-includes/post.php in [12987], it was necessary to avoid an empty slug for a title of "Auto Draft". By the time it was committed, though, it no longer needed to be overridden.

Note: See TracTickets for help on using tickets.