I created a webform and noticed <!--paging_filter--> at the top of the form.
I tried different themes and different browsers but still had the problem. I searched the code and found that the "paging.module" file appeared to be the only place where "paging_filter" was used, so I assume it is causing the problem.
I tried ordering my filters so that the paging filter was the last one to be processed, but still had the problem.
Turning off the paging filter eliminates this extra text, but also, of course, prevents paging. Since I don't need paging on any of my webforms, I thought maybe I could just turn off the paging for webforms, so I went to admin/settings/paging and selected Webform. However, I could not find a way to turn off paging for that one element.
The source code of the displayed webform has several <!--paging_filter> tags in the file. I didn't study the code in the "paging.module" file closely, but it appears to use this tag temporarily and then remove it before continuing on. There are 5 instances of this tag in my HTML, each one immediately preceding a <p> tag. The 5th instance is the problem. the opening "<" has been converted to <. I see this:
<div id="content-inner" class="content-inner block">
<div id="content-inner-inner" class="content-inner-inner inner">
<h1 class="title">Test Webform</h1>
<div id="content-content" class="content-content">
<div id="node-180" class="node odd full-node node-type-webform">
<div class="inner">
<div class="content clearfix">
<span class='print-link'></span><!--paging_filter--><p><!--paging_filter-->
</p><p>This is from the body of the webform</p>
This code is immediately before the actual <form> tag itself. I don't know why there are so many div's or why there are 2 <!--paging_filter--> tags right in a row, along with the extra paragraph tags.
I am using Drupal 6.15,
Paging 6.x-1.0-beta3, and
Webform 6.x-3.0-beta1.
Maybe that's too many betas?
| Comment | File | Size | Author |
|---|---|---|---|
| #7 | paging_clean_tag.patch | 556 bytes | jcmarco |
Comments
Comment #1
inmalagadesign commentedI am getting the same problem in my right hand blocks after creating a news area in views. I have had to disable paging at present any idea how i can hide the paging filter tag in my sidebar to solve this problem?
Comment #2
volocuga commentedI faced the problem too. All my blocks contain
<!--paging_filter-->and I think it's a little bit wrongComment #3
volocuga commentedOk,I solved my problem by sorting filters for input format. Just placed "HTML corrector" at the first position.
Comment #4
john.kenney commentedi'm having similar problems with
<!--paging_filter-->printing to live pages.it is showing in at least 2 spots: in one of the fields on a page with many CCK fields and a custom .tpl.php template. and the other spot is in a views layout for my blog. it shows at the top of every post teaser on the main blog page. it does not show on the individual blog posts.
it is not showing on my webform nodes, thankfully.
all these pages use php input filter. i have tried putting the paging at the top, at the bottom, in several spots in the middle. makes no difference. it shows up regardless of the position. i cleared cache repeatedly as i did this.
pager is otherwise working nicely and i've just spent a lot of time configuring it before seeing these other troublespots.
any suggestions?
Comment #5
john.kenney commentedupdate:
i got rid of the problem with the CCK field by changing the variable reference from [view] to [value]. i'm not completely sure what the difference is technically, but [value] worked and the other didn't (although it did before I installed paging module).
not sure how to get rid of it in my blog front page. the HTML snippet is showing in the body field. if i change that field to strip HTML tags, then
<!--paging_filter-->goes away. but i can't have that as i actually need HTML tags in the teaser.when that option is enabled, then apparently HTML corrector filter goes into motion and i guess that's where the problem comes from based on the comments on this thread and elsewhere. i'm not sure where or if I can modify the order of those views filters. does someone know?
Comment #6
john.kenney commentedupdate #2:
finally killed the final one of these off. the one in views just would not go away regardless of filter order or anything else.
first clue comes on this thread: http://drupal.org/node/269039#comment-2442120
fix comes from the patch here: http://drupal.org/node/222926#comment-2275520
apparently, problem isn't ultimately to do with order of input filters (which made no difference for me anyway), but some kind of longstanding bug in HTML Corrector code. you can read all about it on that thread if you want.
or you can just apply the patch to the filter module in core and it should clear up the problem. it worked for me.
Comment #7
jcmarco commentedEven applying the patch in http://drupal.org/node/222926#comment-2275520 (btw, already committed to core), I still find the
<!--paging_filter-->.The way that paging works is that the hook_filter always add this comment tag in order to process the paging in the hook_nodeapi.
On this paging_nodeapi, it apply the paging and delete any existing
<!--paging_filter-->tag, but it only happens when the content type has the paging feature on,but for the rest of content types the tag added by the paging_filter, is left there.
Other approach could be to finish the job not done by the paging_nodeapi, cleaning the support tag for the rest of content types if the tag is in the content.
I have created this patch using the same code from the paging module but cleaning the content for the rest of content types.
It works fine for me independently of the core patch and filter order.
Comment #8
jenlamptonI can confirm that this patch removes the unwanted HTML comment, so committing to fix this bug.
However, I would be open to a cleaner solution of only adding the comment when it's actually needed, or finding a way to do what we need to do without adding this comment at all. Please see #433604: Search content for actual paging filter rather than placeholder <!--paging_filter--> for work on that front.