[Plugin: WP Ajax Edit Comments] Anyone can edit

Patch to only allow users to edit their OWN comments (versus everyones)

`[Code moderated as per the Forum Rules. The maximum number of lines of code that you can post in these forums is ten lines. Please use the pastebin]

How fantastically unhelpful, for the forum bot to snip out useful code postings and not bother automating transfer of the code to Pastebin’s API.

Automating a method of enacting petty issues is still petty.

Annamarie – thanks for posting your code – would you please re-post it, this time in a place where the bot won’t get offended?

Hurumph. I had the same problem, which means any logged-in user could edit all the comments, regardless of role.

For those who want the solution, here it is In the file /wp-ajax-edit-comments/lib/class.filters.php replace everything starting at line 76 through to the end of the “if (!AEC..” statement ending on line 96 with the code from pastebin. Use at your own risk. Admin roles can edit everything, original comment authors can only edit their own and anonymous editing still works.

Here is what I changed:

• Added “is_user_logged_in” to the top which is where logged in users were getting all their links from. (Discussed below)
• For logged in users, compared the comment owner ID against the logged in user ID or checked for admins.

The crazy thing is that the original code should work! At the top of the IF statement it calls “AECCore::is_comment_owner” which then calls a WordPress function “current_user_can (‘edit_post’..”. But for a logged-in user who is the owner of the comment, that call “current_user_can” doesn’t return true. It should. What’s even more odd is that an anonymous user gets a true back. It shouldn’t. (Latest version V3.4.1) I am stumped and I tested a lot of variants, for example “current_user_can (‘edit_comment’…” doesn’t return true either and yet the current comment and user objects on the page all look correct.

My first guess is a problem with context, or unexposed globals, but those all work when I referenced them directly.

There have been other comments in the forum here where they say that editing is based on IP, as in, if you log in with a different user from the same IP, it gives them access to editing. This hasn’t been my experience, as I tried the site from a different IP with a different user and got the same all-access-editing pass. The fix above worked from the same IP anyway.

Sean

As a side note – the code for the “edit_comment” capability in “capabilities.php” in WordPress is different from the “edit_post” cap, at least at the superficial level I looked at.
Sean.

I found the problem – It comes about when “Selecting “Yes” will allow users registered on your website to edit comments without a time limit.” under AEC -> Settings -> Registered Users. If you turn that setting off, the bug goes away (and your registered users can’t edit timed out posts).

The bug is easily reproducible:

• Setup a clean install
• Add a user, have that user add a comment
• install wp-ajax-edit-comments
• enabled the indefinite editing checkbox
• Yahh, logged in users can edit all comments

I don’t have time to take it the last mile, but if I had to guess the problem is in class.core.php, in the function “can_edit”. If you comment out `if (AECCore::can_indefinitely_edit($comment[‘user_id’])) {
return 1;
}`
all the edit options go away. What is odd is that an is_comment_owner check is done at the top of can_edit. I don’t understand why “can_indefinitely_edit”, being after the is_comment_owner is even there, because only comments *not* owned by the user are passed down.

Maybe the problem is_comment_owner then, because it should be returning true, when it isn’t, allowing the problem to look like it’s coming from can_indefinitely_edit.

Anyway, gotta run.

Sean.

This should be fixed in 5.0.13.