WordPress.org

Make WordPress Core

Opened 13 days ago

Closed 13 days ago

Last modified 13 days ago

#54462 closed defect (bug) (fixed)

The `post_count` option value isn't incremented when the "Hello world!" post is inserted during blog creation

Reported by: henry.wright Owned by: audrasjb
Milestone: 5.9 Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: has-patch commit
Focuses: multisite Cc:

Description

The "Hello world!" post that is generated during blog creation is inserted using $wpdb methods. wp_insert_post() isn't used. This results in the update_posts_count() function not being called when the post is inserted. Therefore, the post_count option value doesn't equal 1 as expected at this point.

Attachments (1)

54462.diff (402 bytes) - added by henry.wright 13 days ago.

Download all attachments as: .zip

Change History (24)

@henry.wright
13 days ago

#1 @henry.wright
13 days ago

  • Keywords has-patch added; needs-patch removed

54462.diff updates the post_count option value when the "Hello world!" post is inserted during blog creation.

#3 @audrasjb
13 days ago

Maybe it would make sense to change this before #53443. What do you think @henrywright?

#4 @henry.wright
13 days ago

I agree @audrasjb it would make sense. Would you prefer to punt both issues to 6.0 or address them both in 5.9?

#5 @audrasjb
13 days ago

  • Milestone changed from Awaiting Review to 5.9
  • Owner set to audrasjb
  • Status changed from new to reviewing

Let's address them both in 5.9 :)

#7 @henry.wright
13 days ago

When this ticket is fixed, we will need to fix the test added in #53443. See this comment in the PR for #53443 for a suggested fix

#8 @audrasjb
13 days ago

  • Keywords commit added
  • Status changed from reviewing to accepted

All checks passed. Marking for commit.

#9 @audrasjb
13 days ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In 52201:

Posts, Post Types: Increment post_count option value during blog creation.

Previously, the post_count option value was not incremented when the default "Hello world!" post is inserted during blog creation on a multisite installation.

Props henry.wright.
Fixes #54462.
See #53443.

#10 @prbot
13 days ago

audrasjb commented on PR #1909:

This change was committed. Now closing this PR.

#11 @dlh
13 days ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

[52201] will cause the post_count option to also be created in single-site installations, which didn't previously occur, as far as I can tell.

Would a change to something like the following be appropriate?

if ( is_multisite() ) {
	update_posts_count();
}

#12 @audrasjb
13 days ago

  • Keywords dev-feedback added; commit removed

That's a fair point. I'm still checking everywhere but yes it looks like the option wasn't created before on single-site installs.

In that case, I'm not sure update_posts_count is better than update_option( 'post_count', 1 );.

It looks like wp_install_defaults can not be overridden by any hook, so I'd say that updating the option directly is more straightforward. Any thoughts @dlh?

#13 @henry.wright
13 days ago

@dlh why would we not want post_count to be incremented for single site installs?

A single site install can become a network install at a future date, at which point it will get a post_count option value

#14 @henry.wright
13 days ago

@dlh I agree though the is_multisite() condition would avoid adding the option to single site installs unnecessarily.

#15 @dlh
13 days ago

@audrasjb Sure, either works. The function call is just a small amount of future-proofing should it become possible to change the default content or should core install two posts by default.

@henrywright For one thing, I don't think the value would be incremented properly on a single-site installation, would it? The only two calls to update_posts_count() currently are in ms-blogs.php. Expanding post_count to work in single-site installations might still make sense, but it seems like a separate effort.

Last edited 13 days ago by dlh (previous) (diff)

#16 @audrasjb
13 days ago

  • Keywords dev-feedback removed

I agree this would be a separate effort.
Let's use the change you proposed @dlh then, you're right it's better in case the current implementation change in the future.

#17 @henry.wright
13 days ago

@dlh agree it wouldn't be incremented or decremented in a single site install. Expanding post_count to work fully in a single site install was my thoughts but I agree that effort is for another day :)

Last edited 13 days ago by henry.wright (previous) (diff)

#18 @audrasjb
13 days ago

@dlh @henrywright do we agree on the patch proposed in comment11 ?

if ( is_multisite() ) {
	update_posts_count();
}

It looks good to me.

Last edited 13 days ago by audrasjb (previous) (diff)

#19 @henry.wright
13 days ago

Looking good to me. Good catch @dlh

#20 @dlh
13 days ago

Works for me!

#21 @audrasjb
13 days ago

  • Keywords commit added

#22 @audrasjb
13 days ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 52202:

Posts, Post Types: Increment post_count option value only on multisite installations.

Avoid the post_count option to be created on single-site installations.

Follow-up to [52201].

Props dlh, henry.wright.
Fixes #54462.

#23 @audrasjb
13 days ago

Thanks @dlh for spotting this 👍

Note: See TracTickets for help on using tickets.