Pagebreak Issue in Content with WYSIWYG

Worker Joined: Dec 26, 2006 Posts: 178

I've looked all over and can't find anything.

But, does anyone know how to fix the pagebreak? The tag shows up in the text and doesn't create a page break.

I found this and don't quite understand it:
[ Only registered users can see links on this board! Get registered or login! ]

Posted: Fri Mar 23, 2007 2:03 pm

Just to be clear, that page break feature only works in the Content module. Are you in Content or are you trying this in News or something?

Posted: Fri Mar 23, 2007 2:08 pm

Yes, I am in the Content module. Could it have something to do with the editor?

I added pagebreak in the allowable html in config.php. It didn't do anything.

Posted: Fri Mar 23, 2007 3:04 pm

Well the pagebreak thing appears in an HTML comment. I suppose the editor may be throwing out comments. What version of Nuke are you using?

Posted: Fri Mar 23, 2007 3:09 pm

Raven's latest, with the WYSIWYG editor

Posted: Fri Mar 23, 2007 5:07 pm

It appears this doesn't work anymore. I have moved this to a RN2.10 forum.

Posted: Fri Mar 23, 2007 6:27 pm

Ok.

I also tried the [--pagebreak--] and it didn't work either.

Posted: Fri Mar 23, 2007 7:34 pm

I had some content that I had prior to RN2.10 that had a page break and it no longer works also. I'll poke around and see what I find.

Posted: Fri Mar 23, 2007 7:42 pm

This seems to be an issue with the WYSIWYG editor. When I turn off the editor it works okay. I believe with the editor on, it is htmlentity'izing the angle brackets in the  tag. When I do a view source with the editor on, I see the  tag, but the brackets are < and >.

I am moving this to the WYSIWYG forum.

Posted: Fri Mar 23, 2007 8:21 pm

I know with the inclusion of TinyMCE, the pagebreak operator was changed from
 to [!--pagebreak--] in newer versions of phpNuke

Posted: Fri Mar 23, 2007 8:24 pm

Ok, this is wierd.

I viewed the source and took any and all html language that was surrounding the  function and it worked.

it looked like this:

<p style="MARGIN-BOTTOM: 0cm; FONT-STYLE: normal"></strong></p>

I removed everything from the left and right side of the  and it worked like it should.

Posted: Fri Mar 23, 2007 8:35 pm

evaders99 wrote:

I know with the inclusion of TinyMCE, the pagebreak operator was changed from
 to [!--pagebreak--] in newer versions of phpNuke

That didn't work either. I'ts definately within the editor, at least that's my noob opinion.

Posted: Fri Mar 23, 2007 9:20 pm

With 7.9 at least it was [--pagebreak--], because my content still has that in there. LOL.

Posted: Fri Mar 23, 2007 9:26 pm

I tell you what, Gremmie, I am learning PHPNuke hard and fast like this Smile

Posted: Sat Mar 24, 2007 1:30 am

I also noticed that the page reads do not change when they are viewed.

Posted: Sat Mar 24, 2007 8:40 am

steve_lemaster wrote:

I also noticed that the page reads do not change when they are viewed.

This last one is a change we made. Since the counter is for the entire article rather than per page, it only makes sense to update the counter if they have read the entire article right? Wink

Posted: Sat Mar 24, 2007 10:05 am

montego wrote:

steve_lemaster wrote:

I also noticed that the page reads do not change when they are viewed.

This last one is a change we made. Since the counter is for the entire article rather than per page, it only makes sense to update the counter if they have read the entire article right? Wink

Ah! I see that it does in fact work.

Posted: Wed Mar 28, 2007 7:27 am

What is the latest on the "page break" issue? I have never had the need for using this feature, but would still like to see a resolution to this if there is one.

Posted: Wed Mar 28, 2007 9:29 am

Some of my content uses it. So I have an interest in seeing it getting resolved. It seems to be related to the advanced editor, because it works when it is off. I will volunteer to go investigate if no one else wants to look at it.

Posted: Wed Mar 28, 2007 9:43 am

I spent an hour or two integrating GCalendar with the advanced editor this weekend so I think I may have a hunch as to what is happening.

Posted: Wed Mar 28, 2007 10:18 am

ok. Thank you sir. BTW, Raven just mentioned to me that he added you and JakeC also to our bug tracker, so if you find this as a bug, please add it there and then one of us can make the fix to the repository.

Posted: Wed Mar 28, 2007 11:24 am

I believe this is what is happening. The content module is reading all the text for the page out of the database into a giant string. It is then exploding the string into an array on . If you have older (pre advanced editor) content, this still works. However if you create content with the advanced editor, the text is apparently htmlentity'ized before saving into the database. So the pagebreaks get turned into .

How to "fix" this? Off the top of my head...

Also explode on  if the first explode doesn't produce any pages.
In the admin part of the content module, before saving the posted text to the database, do a search for .
Pick another pagebreak symbol; 7.9 used [--pagebreak--]. This would break old content but would avoid htmlentity issues.

Any other ideas? Thoughts? I'm leaning towards 1 or 2.

Posted: Wed Mar 28, 2007 12:40 pm

Actually, I am leaning towards a hybrid model, with the end-goal getting away from the entity issue altogether over time:

1) Change so all new content uses the newer [--pagebreak--].

2) Change the page rendering to first explode on [--pagebreak--]. (Over time, as content is read, this will be the case every time and so only one parse through the large string will be necessary (well, sort-of). Read on.)

3) If no page breaks found, then try the older ways.

If there are more pages with page breaks than not, this might be better, but I just hate going through strings multiple times... I'm in a quandry.

----

An alternative to this (better one probably), would be to write a on-time conversion script to convert all the data. Cannot imagine it would be too complex. But, still enforce the newer method with the braces instead of comment.

-----

I guess that I struggle a bit on this one. It really depends upon how many articles have multiple pages. If someone only has a few, well, number 2) or yours would be very easy to "fix" by simply editing the article and click save. However, if there is a ton of this, some kind of conversion might be better.

Posted: Wed Mar 28, 2007 1:24 pm

In the interests of efficiency, I would tend to shy away from anything hard coded which looked for one page break string then the other, or even a reg replace when exploding.

I would be more tempted to simply use the later page break string and have an 'upgrade' script available for those that have too much content to change it manually.

Posted: Wed Mar 28, 2007 2:34 pm

About my option #2. The extra search & replace would only happen at content save time by an admin, with no extra costs on content page views. It would also keep compatibility with RN2.02 and PHP-Nuke 7.6.

OTOH, switching to [--pagebreak--] would nicely avoid htmlentity issues and would be compatible with PHP-Nuke 7.x+, where x > 6 (I'm not sure when FB started using TinyMCE and the [--pagebreak--] convention; 7.7? 7.8?).

It would not be hard to switch RN2.10 to [--pagebreak--] and write a conversion script. The script, I imagine, would be pretty small and could be posted in a forum sticky here.