Make WordPress Core

Opened 15 years ago

Closed 11 years ago

Last modified 11 years ago

#8119 closed defect (bug) (duplicate)

Attempts to edit deleted categories are not properly handled

Reported by: mrmist's profile mrmist Owned by: westi's profile westi
Milestone: Priority: normal
Severity: minor Version: 2.7
Component: Taxonomy Keywords: has-patch
Focuses: Cc:


Fairly obscure.

If one user has the edit cats view open, then another user deletes one of those categories, and the first user then attempts to edit the deleted category, they get - not unreasonably - an empty view on the edit screen. (As the data has been correctly deleted.) Ok. Not too much we can do about that. However, after that, it falls down.

It seems that if you replace the various data and then press "edit category" it can go one of two ways -

  1. The user recieves the message

Your attempt to edit this category: "" has failed.

  1. The user recieves the message

Fatal error: Cannot use object of type WP_Error as array in /home/www/misthaveneu/htdocs/svn/trunk/wp-includes/functions.php on line 1238

Scenerio 2 seems to be vaguely related to using the word "Error" in the description, but that could just be conincidence.

In any event, the handling of this situation is broken. The fact that a category has been deleted since in-between the user viewing the edit category screen and choosing one to edit needs to be recognised. (Even if it's the same sort of nasty wp_die message you get when a post has been deleted.)

Attachments (1)

8119.diff (450 bytes) - added by solarissmoke 13 years ago.

Download all attachments as: .zip

Change History (14)

#1 @jtatum
15 years ago

  • Component changed from General to Taxonomy
  • Resolution set to worksforme
  • Status changed from new to closed

I tried this with today's 2.7 from svn (2.7-almost-rc-9965) and could not reproduce this issue. Edits to the category seem to go through and the screen refreshes to show the category is removed.

#2 @mrmist
15 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

Seems I'm doing a lot of re-opening tonight, but this isn't fixed.

If a user is attempting to edit a deleted category, it's still not handled well.

Warning: Attempt to assign property of non-object in /home/www/htdocs/svn/trunk/wp-admin/edit-category-form.php on line 24

Warning: Attempt to assign property of non-object in /home/www/htdocs/svn/trunk/wp-admin/edit-category-form.php on line 27

Warning: Attempt to assign property of non-object in /home/www/htdocs/svn/trunk/wp-admin/edit-category-form.php on line 30

Warning: Attempt to assign property of non-object in /home/www/htdocs/svn/trunk/wp-admin/edit-category-form.php on line 33

Is shown on the blank edit screen, and any subsequent press of Edit Category after filling in the blanks fails.

It just needs to handle concurrent editing / deleting better.

#3 @jtatum
15 years ago

  • Cc jtatum added


I tried again and could not reproduce those errors. What version of Wordpress did you attempt this with?

#4 @westi
15 years ago

  • Keywords reporter-feedback added
  • Owner changed from anonymous to westi
  • Status changed from reopened to new

mrmist I take it that you have WP_DEBUG enabled?

#5 @mrmist
15 years ago

The above warnings and errors were produced without WP_DEBUG.

With regards to version I reproduced this last night when the svn was up to 9668 I think. Doesn't look like I noted down the original svn revision but I guess it's safe to say that this code hasn't ever changed, because the case to produce it is not that frequently seen.

In case I've not been clear in this note that this is not just about deleting or editing categories. That works just fine and dandy. This is about a situation where you have two concurrent users working on the same category. So, for the sake of reproduction for test purposes it would be -

  1. Log on in one browser as a user, go to categories.php
  2. Log on in another browser as a different user, go to categories.php
  3. As one of the users, delete a category.
  4. As the other user, now attempt to edit the category that was just deleted.

In normal edit, the edit screen now appears, but it's obviously not populated because the cat has been deleted. There's no message to indicate that the category has been deleted, though. (Such as you get if you try to edit a deleted page/post). Instead you get warnings at the top as I noted in my previous comment.

  1. Fill in the edit category box anyway, and press edit category and you get the message "Your attempt to edit this category: "" has failed." You can go back, but you cannot (successfully) progress from the edit category screen.

I cannot reliably reproduce the error message condition which I originally referred to.

If you additionally enable wp_debug, you get the following notices on the edit cat page -

br /><b>Notice</b>: Trying to get property of non-object in <b>/home/www/htdocs/svn/trunk/wp-admin/edit-category-form.php</b> on line <b>52</b><br />

For lines 57,63,69 as well.

Then on the Error page -

Notice: Undefined property: WP_Error::$name in /home/www/htdocs/svn/trunk/wp-includes/category.php on line 201

#6 @mrmist
15 years ago

  • Keywords needs-patch added; reporter-feedback removed
  • Severity changed from normal to minor

Could do with a patch to deal with category deletion concurrency the same way post deletion is dealt with.

#7 @janeforshort
15 years ago

  • Milestone changed from 2.8 to Future Release

Punting due to feature freeze. Reconsider with next release.

#8 @Denis-de-Bernardy
15 years ago

  • Type changed from defect (bug) to enhancement

13 years ago

#9 @solarissmoke
13 years ago

  • Keywords has-patch added; needs-patch removed
  • Type changed from enhancement to defect (bug)

#11 follow-up: @wonderboymusic
11 years ago

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

Trac doesn't have blame/revisions so I can't find the commit, but this was fixed at some point exactly as the patch suggested

#12 in reply to: ↑ 11 @duck_
11 years ago

  • Milestone Future Release deleted

Replying to wonderboymusic:

Trac doesn't have blame/revisions so I can't find the commit, but this was fixed at some point exactly as the patch suggested

[18954] and #18718?

#13 @nacin
11 years ago

  • Resolution changed from fixed to duplicate
Note: See TracTickets for help on using tickets.