Module leaves ugly markers in output. You can use the change below or better yet, change the manual pagebreak marker to be an HTML comment which will do no harm.

At bottom of paging_nodeapi('view')

// Inexplicably, the constant for MANUAL_BREAK is a translated string.
elseif ($paging == 1) {
  $node->content['body']['#value'] = str_replace('[ pagebreak ]', '', $node->content['body']['#value']);
}
CommentFileSizeAuthor
#5 ch10text.zip138.16 KBadam_b
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mundanity’s picture

Hi Moshe,

Not using HTML comments was a design decision, although I'm not particularly attached to the method I'm using. I didn't want users to have to enable a filter in part of the setup, but over time I'm thinking this is a small price to pay. [ pagebreak ] needs to be more flexible than just a string (ie random whitespace), and as such is using regex's to determine matches (and sadly to strip out the values after as well). If you have an example of it still showing the marker output, please setup a demo I can take a look at.

mundanity’s picture

Status: Active » Closed (works as designed)
adam_b’s picture

You can find a sample (at the moment - may not be around for long) at
http://cpag.adam-browne.com/node/4785?page=show

First example is [ header = Who can claim housing benefit ]

mundanity’s picture

Status: Closed (works as designed) » Postponed (maintainer needs more info)

Hi Adam,

Hmm, I can't reproduce this in my test environment, could you send me your raw text for that article? Thanks for your help!

adam_b’s picture

FileSize
138.16 KB

Here's the text. The input format is full HTML, and I'm using the WYSIWYG module as input where necessary. I'm also using:
- the Footnotes module, but I don't think there are any here
- the Glossary module normally, but it times-out with this much text so I've turned it off for the moment

I've just noticed on extracting the text that the header's enclosed itself in <p> tags:
<p>[ header = Who can claim housing benefit ]</p>
Maybe this is why? perhaps from the WYSIWYG filter? If so, maybe I need to go the <h3> route.

mundanity’s picture

Hi Adam,

Thanks for the attachment, version 1.4 and above can handle the <p> tags without issue, so it should be parsing fine, theoretically. I'll take a look at the text you sent though and figure out why it's not.

mundanity’s picture

Hi Adam,

Just an update on this, I was unable to reproduce the issue with the text you sent me, but I'll try a few more options with your configuration to see if I can track it down. Are you seeing this on all your nodes, or just this specific one?

adam_b’s picture

I'm afraid I've only experimented with it on the one node, so that's the only example.

mundanity’s picture

Hi Adam,

Unfortunately I'm still unable to reproduce this. Which filters for footnotes are you using? (I doubt it's the issue but I'd like to replicate your environment as best as possible). Also, what order of filters are you using?

mundanity’s picture

Status: Postponed (maintainer needs more info) » Closed (fixed)

Hi Adam,

Unfortunately I was never able to reproduce this. I did notice some memory issues due to the size of the text you provided, and am wondering if that maybe contributed to the text not being parsed or something. If you are able to get me any more information on this please feel free to re-open this.

adam_b’s picture

Hi - sorry I wasn't able to provide more information, but (a) the test node now causes a PHP memory error when I try and edit it, and (b) we're changing the data structure so that long articles will be broken down into separate nodes rather than using pagebreaks. Since nobody else seems to have had the problem, I agree that you're right to close it. Thanks for the attempts to help.