Make WordPress Core

Opened 20 years ago

Closed 19 years ago

Last modified 3 years ago

#53 closed defect (bug) (fixed)

WordPress deletes some text when HTML tags incorrectly nested

Reported by: anonymousbugger's profile anonymousbugger Owned by: matt's profile matt
Milestone: Priority: normal
Severity: minor Version: 1.2
Component: General Keywords: has-patch has-unit-tests
Focuses: Cc:


If I use HTML in my post, it has to be correctly nested. If I accidentally forget to close a tag, Wordpress closes that tag for me, but a few characters that were entered after the tag are deleted.


I have a page of lists. Each one starts with a paragraph (with opening and closing p tags). After each one is an unordered list (ul) with many li's. If I leave one li open, it gets closed, but a few characters afterwards are deleted.

Attachments (1)

0000053-balancetags-patch2.diff (2.6 KB) - added by anonymousbugger 19 years ago.

Download all attachments as: .zip

Change History (16)

#2 @coffee2code
20 years ago

I've encountered a fair number of WordPress formatting bugaboos. If someone wishes to easily reproduce this particular bug, here is a sample. In the entry body of a post, input this:

<li>Won't close this item.
<li>But will close this one.</li>
<p>0123456789ABCDEFGH Note the LI wasn't closed.</p>

Here's what you'll wind up with:

<li>Won't close this item.
<li>But will close this one.</li>
<p>ABCDEFGH Note the LI wasn't closed.</p>

WordPress just ate 10 characters (the numbers 0 - 9). From what I've seen, it's always 10 characters that it eats.

The other formatting bugs I came across can be found here, if interested:
<a href=""></a>

edited on: 06-30-04 19:21

#3 @coffee2code
20 years ago

Of course, you'd actually use the '<' character instead of &lt;

#4 @anonymousbugger
20 years ago

yup I brought this up in the forums before they added the bug tracking feature, but got no reply. any chance that a wordpress developer may pass this report and have a look?

#5 @coffee2code
20 years ago

I've attached the file balancetags-patch2.diff to this bug report. The diff contains modifications to the function balanceTags() -- found in wp-includes/functions-formatting.php -- that is responsible for this bug. In addition to eating user text, the original balanceTags() function would in certain circumstances not do its job of balancing tags or would do so incorrectly. I've posted an analysis ( ) of the various problems with the function (not the same as the link I provided in my previous comment to this bug). I've also posted an explanation ( ) of the changes I made to the code, as well as a copy of the new function in its entirety.

The fixes to the function aren't really all that numerous, and have been tested by at least one other person on the wp-hackers list. The fixes:

  • prevent user text from ever being deleted
  • properly balances tags immediately nested within themself (particularly list elements with missing &lt;/li> tags)
  • closes unclosed known single-entity tags
  • recognizes any properly-defined single-entity tag
  • prevents insertion of non-sensical &lt;/> tag
  • balances tags in the situation where the original wouldn't

At the very least the fixed function definitely improves upon the original and can hold down the fort until a more thorough XHTML-validator/fixer-upper comes along.


edited on: 08-16-04 14:16

edited on: 08-16-04 14:17

#6 @anonymousbugger
20 years ago

thanks a lot for the diff - seems to be working ok now

#7 @2fargon
20 years ago

  • Patch set to Yes
  • Severity changed from major to minor
  • Version set to 1.2

#8 @matt
19 years ago

  • fixed_in_version set to 1.5
  • Owner changed from anonymous to matt
  • Resolution changed from 10 to 20
  • Status changed from new to closed

Applied patch, seems to be working.

This ticket was mentioned in Slack in #core by westonruter. View the logs.

7 years ago

This ticket was mentioned in PR #1598 on WordPress/wordpress-develop by jrfnl.

3 years ago

  • Keywords has-patch has-unit-tests added

### Tests: add test for wp_schedule_single_event() when there are no scheduled crons

This tests proves a bug introduced in Trac 44818 / [44917].

### Cron: fix bug in wp_schedule_single_event()

In wp_schedule_single_event(), the cron info array is retrieved via a call to _get_cron_array() and straight away cast to an array, but as the documentation for that function (correctly) states, the return type of that function is array|false, where false is returned for a site where no cron jobs have been scheduled (yet).

In the case that _get_cron_array() would return false, this would now unintentionally create an array with a single entry with key 0 and as the value false.

This is a bug. Fixed now by adding validation to the output of _get_cron_array() and initializing $crons to an empty array if false was returned.

Note: this may need an upgrade routine to be added to clean existing cron arrays in which this false entry was inadvertently introduced.


### To do:

  • [ ] Open Trac ticket
  • [ ] Update @ticket tag in the test with the trac ticket number
  • [ ] Add link to the Trac ticket to this PR & set it to "ready for review"

Trac ticket:

peterwilsoncc commented on PR #1598:

3 years ago

I've opened a trac ticket, number 53950.

I'll leave you to add the link proper to the description if you are happy with the PR.

jrfnl commented on PR #1598:

3 years ago

Thanks @peterwilsoncc. Updated the test to contain the right ticket number and marked ready for review now.

peterwilsoncc commented on PR #1598:

3 years ago

Note: this may need an upgrade routine to be added to clean existing cron arrays in which this false entry was inadvertently introduced.

BTW, I am still considering this thus my lack of opinion in the review.

As it's an edge case bug, my inclination is to check for false in wp_upgrade() and remove it if necessary rather than a cron array upgrade routine and version update.

I need to think over the pros and cons over the next 24 hours or so.

peterwilsoncc commented on PR #1598:

3 years ago

Tonya asked if this is ready for commit, as we're going to discuss an upgrade routine in I've suggested commit be held for a few days.

JRF and I are discussing 34913, which will need an upgrade routine, so the outcome of that discussion may affect the upgrade/clean up for this ticket.

hellofromtonya commented on PR #1598:

3 years ago

Committed via changeset 51916.

Note: See TracTickets for help on using tickets.