WordPress.org

Make WordPress Core

Opened 10 years ago

Closed 6 years ago

#10248 closed defect (bug) (wontfix)

force_balance_tags breaks <!--more-->

Reported by: McShelby Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.8
Component: Formatting Keywords: has-patch needs-testing
Focuses: Cc:
PR Number:

Description

In ticket #9765 balanceTags was replaced with force_balance_tags. This is causing tag balancing for the teaser although a user might have disabled tag balancing in the blog configuration.

This breaks plugins that are relying on unmodified teasers.

If the user doesn't want tag balancing the blog should behave so - not only in some cases. If it breaks her HTML then she still can change the post to make it valid.

Attachments (1)

p.patch (535 bytes) - added by McShelby 10 years ago.

Download all attachments as: .zip

Change History (15)

#1 @Denis-de-Bernardy
10 years ago

  • Component changed from General to Template
  • Keywords close added
  • Milestone changed from Unassigned to 2.8.1

perhaps, but on the other hand, it fixes multitudes of errors related to things like:

<div>
foo <!--more-->
</div>

which are guaranteed to break much about every theme. suggesting wontfix.

#2 @Denis-de-Bernardy
10 years ago

Or, at most, switching this back to balanceTags() after the more... tag. But I still think it should stay the way it currently is.

#3 @McShelby
10 years ago

Having a case like your example is a "bug" in the post markup. I agree that the common user is glad if it is fixed by auto balancing the tags.

If the user choose not to balance tags, then he expects that WP will not balance tags in any way at all.

Besides that, ticket 9765 breaks my Exec-PHP plugin if the user writes PHP code before the <!--more-->. In this case force_balance_tags tries to "balance" the PHP code resulting in breaking the code leading to PHP parse errors.

#4 @Denis-de-Bernardy
10 years ago

Ah, makes more sense... How difficult would it be, in your opinion, to fix balanceTags() to play well with exec-php and the various plugins that do the same thing?

#5 @McShelby
10 years ago

Good question. Till now I was happy not to mess with the balance code ;-) But I'll take a look into it.

Probably the PHP code gets intentionally changed by the balance code to avoid hacking?!? Just a guess...

#6 @Denis-de-Bernardy
10 years ago

more likely is that it tries to do: <?php> </php?>

if we get that part fixed, I'm pretty sure your plugin will work again, and we'll kill two birds with one stone.

#7 @demetris
10 years ago

  • Cc dkikizas@… added

#8 @lloydbudd
10 years ago

  • Milestone changed from 2.9 to 3.0

No patch... bumping out of milestone.

#9 @McShelby
10 years ago

  • Cc McShelby added

#10 @McShelby
10 years ago

  • Keywords has-patch added
  • Milestone changed from 3.0 to 2.9.1

Summary
=======

  • We want to make sure, that the excerpt is balanced correctly. Therefore we are running the balance_code on it unconditionally. I've had time to rethink my previous comments and now think especially http://core.trac.wordpress.org/ticket/9765#comment:6 is worth doing a balance_code here.
  • We have a plugin (here Exec-PHP) that needs to alter the content before anyone else have done it. Particularly Exec-PHP will mess up if WordPress had balanced the PHP code.

Options
=======

  • Don't fix: Then plugin execution will fail if only the excerpt is processed to the user (e.g. on the front page of a blog). -> Unpreferable (to me)
  • Revert #9765: Then the excerpt may generate ill-formatted HTML. -> Unpreferable (to the public)
  • Fix the Exec-PHP plugin: Because the processed PHP code may contain comparison operators that will be processed as unbalanced HTML tags, some further escaping of the PHP code could be done by the Exec-PHP plugin before saving the code and reverting them before displaying the content. The plugin was explicitly designed not to parse any PHP code because it's to costly, errorprone and unnecessary. -> Unpreferable (to me)
  • Fix the balace_code: This alone will not fix the issue because PHP operators will still be handled wrong. -> Will not work
  • Add a new filter: We could add a new filter that is executed before the content is altered by WordPress. That filter would be benefitial to other plugins too. I've added this suggestion as a patch to this ticket.

@McShelby
10 years ago

#11 @McShelby
10 years ago

  • Keywords close removed

#12 @McShelby
10 years ago

  • Keywords needs-testing added; balance tags more removed

#13 @nacin
10 years ago

  • Milestone changed from 3.0 to Future Release

#14 @nacin
6 years ago

  • Component changed from Template to Formatting
  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I think at this point, this ticket should be closed. If there is still a desire to fix this, please reopen. For the purposes of a filter, a new ticket may be preferable.

Note: See TracTickets for help on using tickets.