Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#9662 closed defect (bug) (invalid)

get_category_to_edit() wrongly modified description field

Reported by: hailin Owned by: anonymous
Priority: normal Milestone:
Component: General Version:
Severity: normal Keywords: reporter-feedback
Cc:

Description

within _cat_row(), I noticed that when the page starts in a subtree, the first few subtree nodes had empty description field;
However, after the following call,

$qe_data = get_category_to_edit($category->term_id);

$category->description becomes '<br />', and that gets displayed.
This is annoying.

Also the liberal use of global var $category in many functions is annoying, quickly one loses sight of which is which...

Attachments (2)

9662_pic.jpg (32.8 KB) - added by hailin 4 years ago.
screenshot
9662_term.diff (501 bytes) - added by hailin 4 years ago.
patch

Download all attachments as: .zip

Change History (9)

  • Keywords reporter-feedback added

I would be great if you provide more information, like the version you are talking about. Then it would be good to know how to reproduce what you are talking about as well what you think what should be the right behaviour.

Please provide additional Feedback.

trunk revision 11073

To reproduce it, construct categories structure so that the second page
starts in a subtree, and the code is supposed to print the parents. (only after you apply patch #9661 to fix the subtree bug)

Those parents have description filed set to <br /> although they were empty before
the call $qe_data = get_category_to_edit($category->term_id).

So get_category_to_edit() modified the description filed unwittingly.

The expected behavior is not to alter the empty description field.

the <br /> tag sounds like something wpautop could have added. any chances that disabling it here fixes the issue?

http://core.trac.wordpress.org/browser/trunk/wp-includes/default-filters.php?rev=11000#L87

hailin4 years ago

screenshot

hailin4 years ago

patch

removed one filter that produced the extra <br />
Tested and verified.

  • Milestone Unassigned deleted
  • Resolution set to invalid
  • Status changed from new to closed

Please reopen if not.

Yes, indeed wp-includes/formatting.php#L117 fixed the issue on 4/22/2009.

Note: See TracTickets for help on using tickets.