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.
Comment | File | Size | Author |
---|---|---|---|
#16 | filter-cache-194579-5x-16.patch | 1.05 KB | pwolanin |
#12 | filter-cache-194579-5x-12.patch | 1.04 KB | pwolanin |
#7 | filter-cache-194579-7.patch | 1016 bytes | pwolanin |
Comments
Comment #1
webernet CreditAttribution: webernet commentedI'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?
Comment #2
webernet CreditAttribution: webernet commentedCleared the filter cache and things started working as expected.
Comment #3
Aren Cambre CreditAttribution: Aren Cambre commentedTry making a simple change and then later deleting the change. Does it revert to the original version like with me?
Comment #4
webernet CreditAttribution: webernet commentedReverting 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.
Comment #5
chx CreditAttribution: chx commentedYou can add a line of code to nuke the cache_filter table on HTML filter configuration.
Comment #6
Aren Cambre CreditAttribution: Aren Cambre commentedI 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.
Comment #7
pwolanin CreditAttribution: pwolanin commentedI'm with chx - this should be pretty trivial. Patch attached - needs testing.
Comment #8
webernet CreditAttribution: webernet commentedTested OK, and looks sensible.
Comment #9
Gábor HojtsyThanks, committed.
Comment #10
Wim LeersThanks a lot for fixing this. :) It has annoyed me many times.
Comment #11
pwolanin CreditAttribution: pwolanin commenteddoes this need a 5.x backport?
Comment #12
pwolanin CreditAttribution: pwolanin commentedquick re-roll for 5.x
Comment #13
drummDuplicate of http://drupal.org/node/163458.
Comment #14
drummWrong issue, reverting status.
Comment #15
drummDuplicate function name makes a parse error.
Comment #16
pwolanin CreditAttribution: pwolanin commentedok - in my rush I forgot to rename the function. How about this?
Comment #17
drummCommitted to 5.x.
Comment #18
peterpoe CreditAttribution: peterpoe commentedThe backport to Drupal 5 broke filter settings. See http://drupal.org/node/208700
Comment #19
webernet CreditAttribution: webernet commentedContinue in: http://drupal.org/node/208700
Comment #20
gpk CreditAttribution: gpk commentedNot yet fixed in 5.x, but is a duplicate see #18/#19