Teaser not being filter in Views Field

Same here, never on my site do I display "plain" teasers - it is always through the Views, and I need to filter out all "img" tags for teasers fields displayed this way, and htmLawed does not seem to do it.

Ah, this was easily solved in the end - I went into htmLawed filter settings, and made sure "Enabled" is also ticked for the teaser of the specific content type - turns out it is On by default for "body" and "other", but is Off for "teaser". As far as I can see from my tests so far, this does apply "teaser" filtering to what is displayed in the Views output.

Makes me a very happy person :)

I have to report that my joy was premature - after enabling that tickbox everything worked, yet after some time it stopped. Then somehow I managed to fix it - and now it returned to non-working state again. Strangely, it does filter images out of teasers in view listing on content type, and doesn't for another content type.

I am now checking how TinyMCE inserts its pagebreak (it does work oddly), perhaps the filter does not apply if the teaser was not detected and a portion of the node body is shown instead? I will write here once I find something out.

Same here, I just re-tested this on my site, and the settings for htmLawed are not applied to the node teasers displayed in views. I had to turn on "Strip HTML tags" tick on the teaser field in the view, yet this is not good for me, since I need to keep the "a"s in, while have the "p"s and "img"s out.

If you need additional information - please let me know.

Sorry for the accidental mistake... didn't intend to close.

I am changing this issue to 'feature request' as this is not a bug in htmLawed's behavior per se (which is fine with Drupal's default content-types), but an issue seen in conjunction with the Views module.

Thanks, @alpha2zee, any kind of attention to this issue is much appreciated!

I had never used Views before. I tried it today to test the htmLawed issue of this thread. I added a 'View' of type 'node' and added to it the fields 'node:body' and 'node:teaser'. Since I am new to Views, I may not have done things properly, but my observation (using 'Live preview') is that the htmLawed filtering to both 'node:body' and 'node:teaser' is applied as per the settings in 'Default' > 'Other', and not 'Body' or 'Teaser'. So, 'node:teaser' does get filtered by htmLawed, though there is no way to have a separate types of filtering than for 'node:body'. Is that the issue: that a separate type of filtering be allowed?

ps. Re: the comment #2 above, filtering as per 'Teaser' is done on content already filtered by htmLawed as per 'Body'. That's why the enabling is off by default. See http://drupal.org/node/255909.

@alpha2zee, thank you VERY MUCH for investigating this. I tried it again on one view, and, as per #2, it worked for me as required. Yet I noticed two issues:
1. The setting of the "Other" filtering was already what I need (a, strong, em allowed, image and p not allowed) - but before I tried to view and save it it was not applied.
2. For the first view I checked it for it worked, yet when I edited the second view (I needed to disable "strip HTML tags" tick in the teaser field in the view) and saved it, it stopped working again - the img's and p's appeared in both views! So what I had to do was to re-save the htmLawed configuration page again, without making any changes - and it started to work again.

So, from above limited testing, it looks like something that happens when a view is saved somehow resets htmLawed filtering. In order to make it work again I need to go to htmLawed config page and save it - and it works. I am concerned this is not reliable, and at some point something I do on the site may break it again.

Do you have ideas on what could be causing this?

Thanks for your help!

More information: I just edited a block on my site, not relevant to nodes or filters, and the htmLawed filtering does not work on Views teasers again - even though I didn't change anything in the htmLawed at all. Resaving the settings for htmLawed, as I did in #11, does not help :(

I am reverting to stipping all html tags in the view, but I am hopeful that may be with this information this can be solved properly.

htmLawed's settings are stored in the Drupal database's 'variable' table, one record each for all the input formats for which htmLawed is enabled. The module uses standard Drupal API functionalities for fetching or storing the information on settings. I wonder if this is some content-caching issue in the API (e.g., see http://andrewmarsh.com/blog/andrew/stung-by-drupals-filter-caching-again). I will look more into this.

After reading http://drupal.org/node/940572, I am wondering if this issue can be fixed by changing the 'FALSE' in the htmLawed.module file at ~line 70 to 'TRUE'.

case 'no cache':
 	return FALSE; 

@alpha2zee, ok, thanks for checking this, I will try to test tomorrow and let you know.

Btw, I am using Boost on the site, but it should only affect anonymous users - i.e. I shouldn't see the problem if it is caused by Boost, but I do.

I think I can confirm that the issue is solved by setting 'no cache' to TRUE. If you are testing this fix, for it to take effect, remember to save the input format that uses htmLawed and not just the htmLawed configuration for the input format.

With TRUE, Drupal won't cache filtered content for items that use an input format using htmLawed. The default Views templates seem to use filtered content for displays. When htmLawed is in use with 'no cache' set to FALSE, the filtered content seems to have been filtered as per the htmLawed setting for 'Body' and not 'Other'. When 'no cache' is TRUE, Views templates don't use filtered content for displays, and the raw content used by them is rendered as per the htmLawed setting for 'Other'.

These are therefore the possibilities for a resolution for this issue:

1. Release a new version of the htmLawed module with 'no cache' set to TRUE. The drawback is that this will prevent use of cached filtered content and can affect the performance of the sites using the module.

2. Release a new version of the htmLawed module with an option in configuration for 'no cache' to be set to either TRUE or FALSE. The default setting will be FALSE (to not affect current module users). The 'no cache' option will get applied for all types of content for a given input format; e.g., it cannot be selectively enabled for 'Other' and not 'Body' (this is a Drupal API constraint).

3. Suggest editing Views templates to use content that is raw and not already filtered. See http://chrisadams.me.uk/2010/09/12/how-i-am-debugging-drupal-views/ and http://stackoverflow.com/questions/3538505/views-is-stripping-tags-from-... for possible help. A possible drawback is the security risk when htmLawed is disabled but the template is not re-edited.

I am going with #2 and releasing a new version. I hope this fixes the Views issue.

@alpha2zee, thanks for such a deep analysis!

I've changed FALSE to TRUE, and resaved both the input format and the htmLawed config for it. Strangely, it helped for one of the views that I use, and not another one. I've flushed cache (including the views' one) several times, it doesn't seem to change the situation. Also, it is odd that the offending view "previews" fine, while in actual on-page display it seems to be either unfiltered or filtered by the "body" settings.

I will need to test this more (may be add a tag that should be filtered in the "body", to understand what I am seeing), yet I probably won't have more time today - I will try to report on this as soon as I can.

Thank you again for your help.

Ooops, I guess I had the ticket form open while you changed the ticket assignment, so I accidentally reassigned it back to "Anonymous", sorry.

Ok, after more testing I am seeing this:
1. I can confirm that the "good" view continues to work reliably, so the caching fix helped.
2. I tested the "bad" view more - added a script tag (which should not be allowed), and can see that the tag is filtered in the body, in the teaser display, in the "good" view, and in the preview of the "bad" view (!), but not in the display of the view itself.
3. I've compared all the settings of the two views, and they look very similar to me, except for one difference, which may be key: the "good" view is displayed as a page using the standard Views mechanism, while the "bad" view is included in my frontpage template by using this code:
<?php print views_embed_view("frontpage_news_list", "default" ); ?>

I suspect that perhaps this way of calling it may bypass filtering somehow? I will try to read up on this when I have more time again, but if you have any feedback or ideas - I'd really appreciate it.

PS I should note that both views display the nodes of the same type, so this is not connected to htmLawed not being configured for the content type.

Until now I had not used Views, so I don't have an insight from a Views-perspective as of now.

May be I didn't get this, but is it that the display for the 'bad' view gets filtered by htmLawed as per the config. for 'Body' and not 'Other', or is it that it doesn't get filtered by htmLawed at all? If the latter, does it get filtered by Drupal's HTML filter if you make the input format use that filter instead of htmLawed?

ps. The htmLawed module gets the settings for the htmLawed filtering call from the configuration set for the input format. For some reason, if it cannot, it uses a default setting (hard-coded in htmLawed.module file, around line 117 for module version 2.9 for Drupal 6). The default setting doesn't allow 'script' to get through.

added: You can add right after line 76 of the file ("case 'process':") something like "return 'htmLawed was called';" (without the double-quotes) to debug to check if the htmLawed filter gets invoked at all.

It doesn't get filtered at all, since the 'Body' does not allow 'script' either. I will check whether default Drupal filters are applied - if they aren't, then it is not the problem of htmLawed at all.

@alpha2zee, thank you VERY MUCH for providing info in #21 so that I can debug this issue myself, and here's what I found.

When just returning out some debug text of the 'process' case, as you propose, I see that htmLawed is actually called on the offending View. So my assumption that may be Views skips content filtering when being directly embedded was wrong.

So I went further and added numbered debug messages to all of the "return" statements in that case: on line 80, line 128, line 130 and line 133. The result in interesting - the "correct" view returns on line 130, while the offending view returns on line 133 - skipping any htmlawed processing, as far as I can tell. Looking at the offending view in its "preview" in the Views UI, it also returns on line 130, that's why it looks okay there.

I also added $node_type and $for values to the debug output, and here's what it shows:

• correct view: $node_type is empty, $for is "Other".
• offending view: $node_type is empty, $for is "Body" (!!!).
• offending view's preview in the Views UI: $node_type is empty, $for is "Other".
• actual node page: node_type is shown correctly, for is "Body"

So the first thing to note is that the filter would be applied as for "Body", instead of "Other" as it should. But even that does not get applied, since the check for !empty($setting['show']) seems to fail on row 123 and unprocessed text on row 133 gets returned instead of what would be filtered by "Body"...

Can you please look at these findings, and let me know if you see what the problem is, or, may be, what else I can debug in order to find out why incorrect $for is used, and why the 'show' setting is not set?

Thank you very much again!

NPC, thanks for the feedback.

I have edited the module to stop the bypass of htmLawed filtering that you mention (on line 133). Can you try the new version, which should be available soon as a development snapshot? If the snapshot is still unavailable for download, use http://rapidshare.com/files/448530538/htmLawed.module to download the new htmLawed.module file.

Regarding '$for' being 'Body' when it should be 'Other', I can't say why this is so for the offending view but not the offending view's preview. It looks like htmLawed is using a wrong logic to identify '$for'. Can you test this code modification: lines 98-106 of either the new or the old htmLawed.module file changed to --

      elseif(arg(0) == 'node') {
        if(arg(1) == 'add') {
          $node_type = arg(2);
          $for = 'Body';
        }
        elseif(is_numeric(arg(1))) {
          $node_id = arg(1);
          $for = 'Body';
        }
      }

alpha2zee, okay, but I am leaving for 1.5 weeks, so will be able to try this after I get back. I'll let you know then.

I've installed version 2.10 and it does solve the filtering problem! I will try to check the $for logic later (suddenly, time became both rare and valuable for me, and I seem to have none :)).

Thank you for fixing the main problem!