Search content for actual paging filter rather than placeholder <!--paging_filter-->

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.

#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 :(

Blocks?

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

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: <!--paging_filter-->...
If the filter has a weight of 10, I see in result html: <!--paging_filter-->...

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

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

Disable HTML corrector and see?

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.

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.

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

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

This looks very similar to #728094: <!--paging_filter--> shows at top of webforms wich was complaining specifically about the <!--paging_filter--> comment appearing on nodes. I'm going to commit the fix there, but leave this issue open so we can find a better solution, eventually removing the need for the <!--paging_filter--> placeholder.

Alright, here's an approach that removes the need for the additional filter.

In node load, we check for the paging separator, and if it exists, we divide the node into pages, and remove the separator. Thus, in node view, we can;t search for the separator, since it was already removed in op load. But, in op load we add two things if the node has pagination, node->pages which contains the content of each page, as well as node->page_count.

This approach checks for the property page_count on node, and removes the paging filter tag. Since the tag is used on the format, and formats are not used on nodes, this should solve the problems we were having with blocks, and anything else that uses input formats.

It looks suspiciously like jenlampton's code has been applied.