WordPress deletes some text when HTML tags incorrectly nested

[anonymousbugger]

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.

Example:

---

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.

[coffee2code]

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:

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

Here's what you'll wind up with:

<ul>
<li>Won't close this item.
<li>But will close this one.</li>
</li></ul>
<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="​http://www.coffee2code.com/archives/2004/06/29/wordpress-formatting-bugs/">​http://www.coffee2code.com/archives/2004/06/29/wordpress-formatting-bugs/</a>

edited on: 06-30-04 19:21

[coffee2code]

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

[anonymousbugger]

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?

[coffee2code]

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 ( ​http://www.coffee2code.com/archives/2004/08/02/examining-balancetags ) 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 ( ​http://www.coffee2code.com/archives/2004/08/03/fixing-balancetags ) 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.

-Scott
​http://www.coffee2code.com

edited on: 08-16-04 14:16

edited on: 08-16-04 14:17

[anonymousbugger]

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

[matt]

Applied patch, seems to be working.

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

Ref: ​https://developer.wordpress.org/reference/functions/_get_cron_array/

### 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:

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.

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

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.

Tonya asked if this is ready for commit, as we're going to discuss an upgrade routine in https://core.trac.wordpress.org/ticket/34913 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.

Committed via changeset 51916.