Opened 10 years ago
Closed 10 years ago
#29044 closed defect (bug) (fixed)
TypeError: Cannot read property 'avatar' of undefined
Reported by: | michalzuber | Owned by: | johnbillion |
---|---|---|---|
Milestone: | 4.1 | Priority: | normal |
Severity: | minor | Version: | 3.6 |
Component: | Revisions | Keywords: | has-patch |
Focuses: | javascript | Cc: |
Description
To reproduce you need to have an unsaved revision and click on Next in the revisions subpage.
Created a screencast of it https://youtu.be/UHa8of1v_J8
Attachments (3)
Change History (11)
#2
in reply to:
↑ 1
@
10 years ago
I brought this up with Nacin at WordCamp NYC contributor day and he pointed out that you could also get the same situation after using the WordPress importer which would create posts lacking revisions. Opening one of these posts and letting the autosave fire would likely reproduce the bug.
Therefore, I'm going to look at two possible solutions:
- creating the initial revision on the fly in PHP in the same way that we upgrade revisions previous to 3.6 when upgrading to 3.6;
- creating the missing data on the fly in JS - lacking an initial revision, use the current editor content instead.
Replying to adamsilverstein:
This appears to be a data issue with the sample data provided by WordPress. The post you edited has no initial revision, so the 'first' comparison doesn't work correctly.
Here are the rows in my database (screenshot below) - you can see the bundled data Sample post (red) has just two rows, the original content and the autosave. The actual Test post I created (blue) has an initial revision that matches the post content when saved as well as the autosave, and the issue is not reproducible.
This is either won't-fix, or we need to adjust the bundled data to include the initial revision.
@
10 years ago
When viewing revisions and only one revision present, create a dummy revision copy of current post
#4
@
10 years ago
Thanks adamsilverstein, nice job.
I didn't import data. It was on the site that I use to test WP trunk (vanilla install).
Patch fixed issue.
#7
@
10 years ago
- Keywords dev-feedback removed
- Milestone changed from Awaiting Review to 4.1
strtotime( $post->$modified_gmt )
should say strtotime( $post->post_modified_gmt )
. Apart from that, it's good to go.
Note that when viewing the first revision it gets compared to the autosave, not to the current post. That can go into another ticket.
This appears to be a data issue with the sample data provided by WordPress. The post you edited has no initial revision, so the 'first' comparison doesn't work correctly.
Here are the rows in my database (screenshot below) - you can see the bundled data Sample post (red) has just two rows, the original content and the autosave. The actual Test post I created (blue) has an initial revision that matches the post content when saved as well as the autosave, and the issue is not reproducible.
This is either won't-fix, or we need to adjust the bundled data to include the initial revision.