Opened 6 years ago
Last modified 5 years ago
#3224 assigned defect (bug)
No capability to edit own reply when loaded via AJAX
Reported by: | wpdennis | Owned by: | johnjamesjacoby |
---|---|---|---|
Milestone: | 2.7 | Priority: | normal |
Severity: | normal | Version: | 2.5.14 |
Component: | Component - Replies | Keywords: | dev-feedback reporter-feedback |
Cc: |
Description
If replies are loaded in an AJAX call the edit links aren't showing for non moderators.
Reason seems to be that the capability "edit_reply" will be mapped to "edit_other_replies" instead of "edit_replies" here:
<?php case 'edit_reply' : // Get the post $_post = get_post( $args[0] ); if ( ! empty( $_post ) ) { ... // User is author so allow edit if not in admin } elseif ( ! is_admin() && ( (int) $user_id === (int) $_post->post_author ) ) { $caps = array( $post_type->cap->edit_posts ); // Moderators can always edit forum content } ... } else { $caps = array( $post_type->cap->edit_others_posts ); } ... } break;
For an AJAX call is_admin() is true so it always falls back to the else block for non moderators.
The is_admin() check was introduced to #2389. I think in 2.6 it would be more robust to check if editing is still allowed with something like:
<?php ... // User is author so allow edit if not locked } elseif ( ( (int) $user_id === (int) $_post->post_author ) && ! bbp_past_edit_lock( $_post->post_date_gmt ) ) { ...
Change History (4)
Note: See
TracTickets for help on using
tickets.
bbPress traditionally uses it’s own theme-side, non-admin-area AJAX handler, largely to avoid
is_admin()
being misleadingly true during rendering of it’s many template parts.Is this behavior something you’ve experienced outside of bbPress core? That determines if we fix the code or the docs, IMO.