![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
Opened 10 years ago
Closed 10 years ago
#38271 closed defect (bug) (fixed)
`wp-remove-post-lock` Ajax request generates notice in `wp_ajax_wp_remove_post_lock()`
| Reported by: | dlh | Owned by: | adamsilverstein |
|---|---|---|---|
| Priority: | normal | Milestone: | 4.7 |
| Component: | Editor | Version: | 4.7 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: | javascript, administration |
Description
Before [38425], when no #active_post_lock was in the DOM, the POST request from post.js with the wp-remove-post-lock action would not include an active_post_lock key, and wp_ajax_wp_remove_post_lock() would return immediately.
After [38425], when no #active_post_lock is in the DOM, active_post_lock is converted to the string "undefined" when formData is supported (I'm using Chrome 53.0.2785.143).
wp_ajax_wp_remove_post_lock() tries to process that value, leading to Undefined offset: 1 after array_map( 'absint', explode( ':', $_POST['active_post_lock'] ) ).
To replicate, visit post-new.php and refresh the page after it loads.
The attached patch would return before the Ajax request occurs in post.js if data.active_post_lock is undefined.
Attachments (2)
Change History (6)
#3
@
10 years ago
The attached patch would return before the Ajax request occurs in post.js
Right, the first thing wp_ajax_wp_remove_post_lock() does is to return early when either post_ID or active_post_lock is empty. Can do the same in JS too.
@dlh thanks for the patch! This looks reasonable, I tested before and after, verified the error you mentioned and see it is solved by the patch. I am attaching a slightly updated version switching to a Yoda conditional.