Make WordPress Core

Opened 6 years ago

Closed 5 years ago

#12763 closed defect (bug) (fixed)

"Last edited by" not correct username

Reported by: rooodini Owned by:
Milestone: 3.0 Priority: normal
Severity: normal Version: 2.9.2
Component: Administration Keywords: has-patch tested
Focuses: Cc:


The "Last edited by" text on the edit-post page shows current username, not username who has last edit.

I've done this: - on a clean wordpress, release version 2.9.2 - login as admin - make new post - make new user, type "editor" - login as the new user - go to edit-post page of the created post - it says "Last edited by [username of user with lock] on [date last modified] at [time last modified]"

This description is only subtly different from that of #8556. I followed the same test case (but for release 2.9.2) and got the same result.

Attachments (4)

post.patch (498 bytes) - added by deepak.seth 6 years ago.
Patch updated with respect to root
post2.patch (1.0 KB) - added by deepak.seth 6 years ago.
patch.3.diff (1.0 KB) - added by rooodini 6 years ago.
Typos corrected
patch.4.diff (1.0 KB) - added by rooodini 6 years ago.
add/update checks removed

Download all attachments as: .zip

Change History (27)

#1 @scribu
6 years ago

  • Milestone changed from Unassigned to 3.0

Confirmed behaviour in WP 3.0-alpha.

#2 @rooodini
6 years ago

Hi sorry - Bit of a newb question.. I'm sure this is the wrong place to ask it, but..

I can't tell what this patch is for. It doesn't seem to match 2.9.2, or the nightly build of 3.0. I've just checked out the latest version on svn and it doesn't seem to match there either!

Thanks in advance. I'm sure this is just me being daft.

P.S. The patch itself looks good though - I guessed maybe updating _edit_last at the wrong time could be the problem, so this looks promising.

#3 @scribu
6 years ago

  • Keywords has-patch added

The patch was probably made relative to wp-admin/includes (or wp-includes) instead of being relative to the root wp directory. That's why you're having trouble applying it.

#4 @scribu
6 years ago

There should really be a recommendation somewhere, encouraging people to make patches relative to the root directory, to avoid confusions like this.

#5 @rooodini
6 years ago

Ahhhhhhh! Thanks scribu! I was looking at wp-includes/post.php but it is in fact in wp-admin/includes/post.php

Yes, a patch relative to the root would have helped!

#6 @deepak.seth
6 years ago

  • Cc deepak.seth added

i am extremly sorry for this ,it was my wrong as i wa new with svn.but now i know what mistake i made and will make sure not to repete it.:)

6 years ago

Patch updated with respect to root

#7 @rooodini
6 years ago

  • Component changed from General to Administration

No problem deepak.seth. A recursive grep would have helped me locate the file, but I didn't think of it!

Unfortunately, the patch doesn't quite do the trick.. Although the incorrect author is no longer displayed, it instead results in cases where the author who last edited is not displayed at all.

I'll post a proper test case later today.

#8 @rooodini
6 years ago

I think the patch is halfway there, but now _edit_last is never set. Checking wp_postmeta before and after updating a post reveals this to be the case.

#9 @rooodini
6 years ago

  • Keywords needs-patch added; has-patch removed

6 years ago

#10 @deepak.seth
6 years ago

  • Keywords has-patch added; needs-patch removed

The _edit_last meta variable was actually never set, so made some suaitable changes and it worked for me.

6 years ago

Typos corrected

#11 @rooodini
6 years ago

Brilliant - The new patch works for me!
I've just modified it slightly (patch.3.diff) as there were two small typos in the comments.

Thanks for your work in resolving this, deepak.seth!

#12 @rooodini
6 years ago

  • Keywords dev_feedback added

#13 @rooodini
6 years ago

  • Keywords dev-feedback added; dev_feedback removed

#14 @scribu
6 years ago

  • Keywords tested added; dev-feedback removed

Seems to be working properly.

This line is unnecessary:

if ( !add_post_meta( $post_ID, '_edit_last', $GLOBALS['current_user']->ID, true ) )

update_post_meta() will internally call add_post_meta() if necessary.

#15 @nacin
6 years ago

Yeah, we run that same code for _edit_lock. Both could be updated.

6 years ago

add/update checks removed

#16 @rooodini
6 years ago

Ok latest patch (patch.4.diff) removes the unnecessary if statements for _edit_last and _edit_lock.

Tested and works for me.

#17 @deepak.seth
6 years ago

ya thats an unnecessary check as it creates the field too..!!
Tested working for me..

#18 @dd32
6 years ago

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

(In [14216]) Correct "Last Edited by" username, Updates the last edited username upon save rather than upon a edit lock being created. Props rooodini & deepak.seth. Fixes #12736

#19 @misty9
5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened


Just upgraded to WP 3.0.1 and the Last Updated user still shows the creator of the page instead of the updater. How can I get the fix? Thanks.

#20 @deepak.seth
5 years ago

@misty9: i crossed checked and found it is showing correctly yet if you want a fix can you please provide the test case.

#21 @misty9
5 years ago

Hi Deepak.seth,

Issue: The Last Updated remains the creator of the page rather than the updator
Note: The existing page was created a couple years ago by Admin01 and it's been updated by Admin02.

Here are the steps to reproduce the issue that I have encountered in WP 2.9.2 and 3.0.1

  1. Create a PAGE (not a post) named TEST as Admin01
  2. Edit the PAGE TEST as Admin02 and press the Update button to save the PAGE
  3. Refresh the TEST URL and it still says Admin01 has updated the PAGE:

"Last updated: August 2, 2010 by Admin01"

Let me know if you need anything else from me. Thanks.

#22 @mrmist
5 years ago

I'm unable to reproduce this new issue. At the very least I'd suggest that this be taken up as a new ticket, because the originally posted issue is fixed. More likely this belongs in the forums, it's probably a plugin issue.

#23 @misty9
5 years ago

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

Thanks for your reply, Mr Mist.

I will reopen the original bug that I have logged the other day.

I have entered a question on the forum, but no one seems to have the answer.

Note: See TracTickets for help on using tickets.