Opened 10 years ago
Last modified 2 years ago
#31977 assigned defect (bug)
Ping status of pages changes to "closed" in quick edit
Reported by: | JanVoracek | Owned by: | pareshradadiya |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | 4.2 |
Component: | Posts, Post Types | Keywords: | good-first-bug dev-feedback has-patch |
Focuses: | administration | Cc: |
Description
WP version: 4.2-beta4
Every page is created with ping_status set to "open". If the page is edited in the "full" edit form, the ping_status remains untouched. However, if the page is edited in the quick edit form, the ping_status field is changed to "closed" since WP 4.2.
Since pages don't support the ping functionality, I suppose it shouldn't change the field. Maybe "closed" is the propper one, but it should be set on the creation.
It makes testing of our plugin a little bit tricky.
Thanks.
Jan
Attachments (3)
Change History (12)
#1
@
10 years ago
- Keywords needs-patch good-first-bug added
- Milestone changed from Awaiting Review to Future Release
#3
@
10 years ago
- Keywords needs-patch added; has-patch removed
Thanks for the patch, pareshradadiya. A couple things:
- Let's use
<input type="hidden">
rather than hiding with CSS - We should be falling back not on 'open', but on the actual 'ping_status' value for the current post
- Could you fix the whitespace to match coding standards please? :)
#4
@
10 years ago
(Also, we should do the same thing for comment status, which I believe suffers from the same bug.)
#7
@
2 years ago
- Keywords needs-patch added; has-patch removed
- Milestone set to Future Release
It looks like this one is still happening.
Every page is created with ping_status set to "open".
I am finding this is not the case currently in 6.0.1, though. I'm not sure if it's because of how my site is set up (it's just a fresh install), or a change somewhere along the way. But every test page I have created with both the block editor and the Classic Editor have had ping_status
set to closed
. But, if I change it to open
and bulk edit the page, the behavior described above is seen.
31977.2.diff needs a refresh. @pareshradadiya I know it's been a long time (apologies for this one falling through the cracks), but would you be interested in refreshing the patch?
This ticket was mentioned in PR #3473 on WordPress/wordpress-develop by @abozhinov.
2 years ago
#9
- Keywords has-patch added; needs-patch removed
Did a refresh on the changes applied in the latest patch. ( Added hidden input fields containing comment_status and ping_status, changes about those statuses in the .js file )
Trac ticket: [](https://core.trac.wordpress.org/ticket/31977)
I've confirmed the bug, but it doesn't look like it's new to 4.2. As far as I can tell, it's worked this way since the current implementation of Quick Edit went into WP. See https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-posts-list-table.php?annotate=blame&marks=1252,1261#L1234 and https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/ajax-actions.php?annotate=blame&marks=1550,1551#L1542 Can you check again to be sure that this was not a problem in 4.1 and earlier?
It looks to me like the simplest fix is to change https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-posts-list-table.php?annotate=blame&marks=1252,1261#L1234 so that when the
post_type_supports()
checks fail (elseif
) a hidden input with the current value will be output to the screen.