Project:Paging
Version:6.x-1.x-dev
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:active

Issue Summary

This module occasionally inserts "<!--paging_filter--> " into content. This has happened with us for the "quote" module (inserts into quotes placed into the body or content section of most themes) and the "cck teaser" module.

Comments

#1

Status:active» closed (duplicate)

This was earlier reported for paging as well in #179456. The best was done to strip that text from the output. However, the problem persists for some due to #97182, iirc.

Perhaps paging shouldn't play with inserting <!--paging_filter--> anymore and upgrade to some better solution.

#2

Title:Occasionally inserts "<!--paging_filter-->"» The garbage in displayed code
Version:6.x-1.0-beta3» 6.x-1.x-dev
Status:closed (duplicate)» active

#179456: <!--paging_filter--> not removed from HTML output - bug in version 5.
Version 6.x-1.x-dev contains the the error still!
Most blocks contain garbage at the beginning :(

#3

Blocks?

What modules (providing filters) are you using? How do I reproduce this bug?

#4

Yes, all blocks with the filter.

1) /admin/settings/paging - the all types of nodes removed

2) The block has format MY_TYPE

3) /admin/settings/filters/MY_TYPE/order

If the filter has a weight of -10, I see in result html: &lt;!--paging_filter-->...
If the filter has a weight of 10, I see in result html: <!--paging_filter-->...

#5

Blocks what? What does paging have to do with blocks?

I'll try weighing paging to see if I can reproduce the same.

#6

Disable HTML corrector and see?

#7

Status:active» postponed (maintainer needs more info)

#8

Priority:normal» critical

Just upgraded my WAMP test site from 5.19 to 6.13 and upgraded all contributed modules. Enabled paging for the desired content types.
Now I am seeing <!--paging_filter--> at the head of content node or teaser. If the content originally used <!--pagebreak--> in 5.19 THE PAGEBREAK DOESN'T HAPPEN and <!--pagebreak--> appears where the pagebreak should have been. Checked all the settings in the FCKEditor (in fckeditor.config.js) and they are as they were in 5.19.
This is a show stopper for my upgrade to 6.x on the live site. Any help would be appreciated.

Drupal v6.13
FCKEditor module v6.x-1.4-rc1 and FCK Editor v2.6.4.1
Paging module v6.x-1.0-beta3
Apache 2.0.58
PHP v5.14
MySQL v5.0.22

UPDATE:
I followed the suggestion from Keyz (http://drupal.org/node/176456). I set the paging filter weight to 10 and all others above it and cleared the db cache tables using phpMyadmin. That got rid of the random <!--paging_filter--> instances and the paging is working. But now I am seeing <!--break--> in all the places where I have a teaser break. The teaser works correctly but the <!--break--> appears when you view the full node. Curioser and curiouser.

#9

Priority:critical» normal

Apparently the <!--break--> problem was due to "operator error". I readjusted the input filters and reset one of the node entries to use full HTML instead of filtered HTML and that solved the problem.
It's been a learning experience.

#10

Priority:normal» critical
Status:postponed (maintainer needs more info)» active

I just upgraded a 5.x site to a 6.15, and am running 6.x-1.0-beta3 version of this module.

All my Full HTML blocks are still outputting < ! --paging_filter-- > above the actual content of the block.

Lines 711 to 715 of paging.module says:

    case 'process':
      // The filter gets called before the nodeapi 'view' so,
      // add a comment to the body to inform the nodeapi hook to apply the filter.
      return '<!--paging_filter-->' . $in_text;
      break;

the comments indicate that this is for nodeapi - but filters are also run on non-node objects (like blocks, comments, panel panes, etc).

To make my blocks render correctly, I commented out the case for process so my code now looks like this (note: this change alone will break all the pagers on your nodes!!!)

    /*case 'process':
      // The filter gets called before the nodeapi 'view' so,
      // add a comment to the body to inform the nodeapi hook to apply the filter.
      return '<!--paging_filter-->' . $in_text;
      break;*/

I don't believe this process case would be necessary if line 495 of paging.module were to search my nodes for my actual paging filter indicator, instead of using the hard-coded < ! --paging_filter-- >. My site's actual paging filer is < ! --pagebreak-- > so I did a quick find-and-replace to get the module working on my site.

Jen

#11

Did you adjust the input filters? What about disabling HTML corrector?