WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#9662 closed defect (bug) (invalid)

get_category_to_edit() wrongly modified description field

Reported by: hailin Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: General Keywords: reporter-feedback
Focuses: 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 5 years ago.
screenshot
9662_term.diff (501 bytes) - added by hailin 5 years ago.
patch

Download all attachments as: .zip

Change History (9)

comment:1 hakre5 years ago

  • 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.

comment:2 hailin5 years ago

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.

comment:3 Denis-de-Bernardy5 years ago

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

hailin5 years ago

screenshot

hailin5 years ago

patch

comment:4 hailin5 years ago

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

comment:6 Denis-de-Bernardy5 years ago

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

Please reopen if not.

comment:7 hailin5 years ago

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

Note: See TracTickets for help on using tickets.