On a clean install of Drupal 6 beta 3, I added these tags to the Filtered HTML input format: <table> <thead> <tbody> <tr> <td>.

I created a page containing the following code before adding those tags to Filtered HTML:

<h3>Officers</h3>
<table border="1" style="border-collapse: collapse;">
    <thead>
        <tr>
            <td><strong>Position</strong></td>
            <td><strong>Name</strong></td>
        </tr>
    </thead>
    <tbody>
        <tr>
            <td>President and Director</td>
            <td><a href="mailto:xx@yy.zz">Bubba President</a></td>
        </tr>
        <tr>
            <td>Treasurer</td>
            <td><a href="mailto:aa@bb.cc">Bubba Treasurer</a></td>
        </tr>
    </tbody>
</table>

The table tags are predictably stripped out of the rendered output since they are not in the Filtered HTML input filter.

Then I change the input filer to add the table-related tags listed above, edit the page, and save it without modifying it. The output remains filtered even though I changed the filter to allow the table.

Then if I edit the page again, add a space before the close quote in the <table> tag's style attribute, and save the page, I do get the correctly rendered text.

But it gets weirder. If I re-edit the page and remove that space--in effect, reverting to how it was originally--I get the original filtered page with no table tags!

What should be happening:

  • If I re-save a page, even if I don't change its body, the new filter rules should always be applied.
  • Manually making changes to a page's content that happens to revert it to an earlier version--one that happened to exist before the input filter's allowed tags field was changed--should not cause the rendered content to go to an invalid state.
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

webernet’s picture

I'm able to reproduce on a fresh install.

Making any change to the node (such as a hard return or space at the end) makes the filters act correctly.

While testing, I disabled, then re-enabled the HTML corrector filter. After that, I can no longer reproduce the issue.

Could this be a caching issue?

webernet’s picture

Cleared the filter cache and things started working as expected.

Aren Cambre’s picture

Try making a simple change and then later deleting the change. Does it revert to the original version like with me?

webernet’s picture

Reverting a simple change (before clearing cache_filter) reverts to the original stripped tag version.

After clearing the cache, things instantly work as expected - no saving of the node required.

chx’s picture

Version: 6.0-beta3 » 6.x-dev
Priority: Normal » Minor

You can add a line of code to nuke the cache_filter table on HTML filter configuration.

Aren Cambre’s picture

Priority: Minor » Normal

I disagree with this being minor. This can really screw up someone's presentation and cause major heartache figuring this out. This needs to be fixed, especially if it's as simple as perhaps forcing an update on every save.

pwolanin’s picture

Status: Active » Needs review
FileSize
1016 bytes

I'm with chx - this should be pretty trivial. Patch attached - needs testing.

webernet’s picture

Status: Needs review » Reviewed & tested by the community

Tested OK, and looks sensible.

Gábor Hojtsy’s picture

Status: Reviewed & tested by the community » Fixed

Thanks, committed.

Wim Leers’s picture

Thanks a lot for fixing this. :) It has annoyed me many times.

pwolanin’s picture

Status: Fixed » Patch (to be ported)

does this need a 5.x backport?

pwolanin’s picture

Version: 6.x-dev » 5.x-dev
Status: Patch (to be ported) » Needs review
FileSize
1.04 KB

quick re-roll for 5.x

drumm’s picture

Status: Needs review » Closed (duplicate)
drumm’s picture

Status: Closed (duplicate) » Needs review

Wrong issue, reverting status.

drumm’s picture

Status: Needs review » Needs work

Duplicate function name makes a parse error.

pwolanin’s picture

Status: Needs work » Needs review
FileSize
1.05 KB

ok - in my rush I forgot to rename the function. How about this?

drumm’s picture

Status: Needs review » Fixed

Committed to 5.x.

peterpoe’s picture

Status: Fixed » Active

The backport to Drupal 5 broke filter settings. See http://drupal.org/node/208700

webernet’s picture

Status: Active » Fixed
gpk’s picture

Status: Fixed » Closed (duplicate)

Not yet fixed in 5.x, but is a duplicate see #18/#19