Skip to:
Content

bbPress.org

Opened 9 years ago

Last modified 7 years ago

#2732 new defect (bug)

pending and draft replies cause menu_order issues

Reported by: tharsheblows's profile tharsheblows Owned by:
Milestone: 2.7 Priority: normal
Severity: normal Version: trunk
Component: Component - Replies Keywords: has-patch
Cc:

Description

When a post is posted as pending or draft, the menu order is set to 0. When either of those is published, the menu_order is incorrect, usually a repeat of the menu_order of the next reply in the topic.

Drafts should probably go to the end and pending posts should go to the end, too? End = the last place in the menu order.

I just noticed this doing something else and haven't come across an issue with it but it could possibly cause problems with bbp_reply_url under quite frankly very rare conditions. Or perhaps the behaviour might be unexpected as the pending and draft replies pop up in the topic when they were initially written rather than at the end of it.

Attachments (2)

2732.diff (1.1 KB) - added by tharsheblows 9 years ago.
set initial menu_order of non-published replies to 0
2732.2.diff (1.5 KB) - added by tharsheblows 9 years ago.
adds in updating menu_order when approving reply

Download all attachments as: .zip

Change History (11)

#1 @netweb
9 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 2.6
  • Priority changed from low to normal
  • Severity changed from minor to normal
  • Version set to trunk

This ticket was mentioned in Slack in #bbpress by tharsheblows. View the logs.


9 years ago

#3 @tharsheblows
9 years ago

Ok, this gives all non-published replies a menu_order of zero rather than doubling up. I was also wrong about the menu_order affecting the order of replies listed. Those have order using the date, so a reply that was pending initially will get the date and time of approval as usual.

@tharsheblows
9 years ago

set initial menu_order of non-published replies to 0

#4 @tharsheblows
9 years ago

This updates the menu_order when approving pending replies. It only does replies with a menu_order == 0, so if a reply goes from publish -> pending -> publish for some reason, the menu_order stays as the original.

@tharsheblows
9 years ago

adds in updating menu_order when approving reply

#5 @tharsheblows
9 years ago

  • Keywords has-patch added; needs-patch removed

#6 @netweb
9 years ago

The below post ID 183 is a normal approved reply in a topic, the second post ID 184 is by a different user using a keyword to trigger the moderation que (moderatedword), note even though the status is pending it is currently assigned the correct menu_order position 5.

IDpost_authorpost_datepost_date_gmtpost_contentpost_titlepost_excerptpost_statuscomment_statusping_statuspost_passwordpost_nameto_pingpingedpost_modifiedpost_modified_gmtpost_content_filteredpost_parentguidmenu_orderpost_typepost_mime_typecomment_count
18312015-03-20 13:38:002015-03-20 13:38:00moderatedword blacklistword publishclosedopen 183 2015-03-20 13:38:002015-03-20 13:38:00 177http://src.wordpress-develop.dev/forums/reply/183/4reply 0
18432015-03-20 13:39:200000-00-00 00:00:00moderatedword pendingclosedopen 2015-03-20 13:39:200000-00-00 00:00:00 177http://src.wordpress-develop.dev/?post_type=reply&p=1845reply 0

Other notes as a sanity check whilst we go through this:

  • post_date is the time the reply was created
  • post_date_gmt is not assigned to the pending reply
  • post_name is not assigned to the pending reply
  • post_modified is the time the reply was created
  • post_modified_gmt is not assigned to the pending reply
  • GUID does not include the site rewrite slug, this can be ignored though as it uses the native WP type

Adding a new reply before approving the existing pending reply:

Everything looks good here except the menu_order of the new approved reply is 5 which is the same as the pending reply above.

IDpost_authorpost_datepost_date_gmtpost_contentpost_titlepost_excerptpost_statuscomment_statusping_statuspost_passwordpost_nameto_pingpingedpost_modifiedpost_modified_gmtpost_content_filteredpost_parentguidmenu_orderpost_typepost_mime_typecomment_count
18512015-03-20 13:55:332015-03-20 13:55:33Reply before approve existing pending reply publishclosedopen 185 2015-03-20 13:55:332015-03-20 13:55:33 177http://src.wordpress-develop.dev/forums/reply/185/5reply 0

Approving reply 184 results in:

  • All four post date fields are update to the time the pending reply was approved and the original post date/time is lost, we need to store the original post date/time and after approving the reply restore this date/time.
  • Post ID 186 is a revision, we can disable this during the approve action but no big deal
  • menu_order of the original pending reply remains 5 which is correct, the follow up reply is also 5 thus when approving a pending reply all replies to a topic should be updated.
IDpost_authorpost_datepost_date_gmtpost_contentpost_titlepost_excerptpost_statuscomment_statusping_statuspost_passwordpost_nameto_pingpingedpost_modifiedpost_modified_gmtpost_content_filteredpost_parentguidmenu_orderpost_typepost_mime_typecomment_count
18312015-03-20 13:38:002015-03-20 13:38:00moderatedword blacklistword publishclosedopen 183 2015-03-20 13:38:002015-03-20 13:38:00 177http://src.wordpress-develop.dev/forums/reply/183/4reply 0
18432015-03-20 14:01:142015-03-20 14:01:14moderatedword publishclosedopen 184 2015-03-20 14:01:142015-03-20 14:01:14 177http://src.wordpress-develop.dev/?post_type=reply&p=1845reply 0
18512015-03-20 13:55:332015-03-20 13:55:33Reply before approve existing pending reply publishclosedopen 185 2015-03-20 13:55:332015-03-20 13:55:33 177http://src.wordpress-develop.dev/forums/reply/185/5reply 0
18612015-03-20 14:01:142015-03-20 14:01:14moderatedword inheritopenopen 184-revision-v1 2015-03-20 14:01:142015-03-20 14:01:14 184http://src.wordpress-develop.dev/184-revision-v1/0revision 0

This ticket was mentioned in Slack in #bbpress by thebrandonallen. View the logs.


9 years ago

#9 @johnjamesjacoby
7 years ago

  • Milestone changed from 2.6 to 2.7

This will require a bit more work to complete than we have in the 2.6 cycle, so I'm moving it to 2.7.

Note: See TracTickets for help on using tickets.