PROBLEM

Sometimes the Table of Contents creation fails depending on the markup in the node. The failure is caused by a newline preceeding the closing header tag:

THIS WORKS:

   <h2>Alpha</h2>
   <h2>Bravo</h2>
   <h3>Bravo 1</h3>
   <h3>Bravo 2</h3>
   <h2>Charlie</h2>

THIS DOES NOT WORKS:

   <h2>Alpha
   </h2>
   <h2>Bravo
   </h2>
   <h3>Bravo 1
   </h3>
   <h3>Bravo 2
   </h3>
   <h2>Charlie
   </h2>

SOLUTION

The parsing code needs to be modified. The regex being used to parse the header tag needs to include newline characters as part of the expression.

RATIONALE

Some editors and users will insert newlines before closing tags. This is well-formed HTML/XHTML, and therefore should be correctly parsed. The current code fails silently.

CommentFileSizeAuthor
#3 tableofcontents.pages_.inc_.patch464 bytesstephen.moz
#2 toc200912021853.patch619 bytesstephen.moz

Comments

stephen.moz’s picture

stephen.moz commented

Actually, it appears this problem is more general than the title suggests. I will create a patch that handles this.

stephen.moz’s picture

stephen.moz commented
Priority: Critical » Normal
StatusFileSize
new toc200912021853.patch619 bytes

Here is a patch. This fixes the problem by modifying the replacement regex. Now the user can add newlines before and after the header tags without breaking the auto-generated TOC.

To verify the patch, create a node with the following markup, both before and after the patch:

<!--break-->
<!--tableofcontents-->
<h2>Alpha</h2>
<p> blah blah blah </p>

<h2>Bravo
</h2>
<p> blah blah blah </p>

<h2>
    Charlie
</h2>
<p> blah blah blah </p>

Before applying the patch, only the header "Alpha" shows up in the auto-generated table of contents. After applying the patch, all three headers show up in the auto-generated table of contents.

stephen.moz’s picture

stephen.moz commented
StatusFileSize
new tableofcontents.pages_.inc_.patch464 bytes

Sorry, the previous attachment is the wrong file for the patch, see this one instead.

AlexisWilke’s picture

AlexisWilke commented
Title: Parsing error causes table of content creation to fail if closing H2 tag is preceeded by a newline » Header tags not properly recognized when preceded or followed by newline characters
Version: 6.x-3.1 » 6.x-3.x-dev
Assigned: Unassigned » AlexisWilke

Hi smosley,

Thank you for taking the time to post a patch!

I'd rather use the 's' modifier so the '.' character includes the new line character. As I was at it, I added the 'i' modifier even though it means it will accept (and deal somewhat improperly) the [collapse] tags in uppercase.

More info: http://us.php.net/manual/en/reference.pcre.pattern.modifiers.php

I wrote a test here.

The -dev will have the fix within the next 12h.

Alexis Wilke

AlexisWilke’s picture

AlexisWilke commented
Status: Active » Fixed

Btw, you're using the wrong editor... 9-)
FCKeditor removes those newline characters for you. (in that example, I turned off the editor.)

stephen.moz’s picture

stephen.moz commented

That makes sense. I think I've gotten in the habit of using character classes because not all of the languages I work with on a regular basis have the Perl Regex Engine available. Thus, the Perl-specific modifiers mean I have to change code if I want to port a complex regex to a non-PCRE-supporting language.

I like your additional point on the editor choice though, but this issue came up in a "shared" environment where it's a pain to try to get people to consider alternate tools or approaches unless it's something they think they want on their own. I actually prefer using Firefox + "It's all Text" + a regular desktop editor/IDE to make node edits, since you can run macros, create snippets and do all sorts of things that are still just too cumbersome for an in-browser WYSIWYG. That's what I had been using to deal with the whitespace issue.

But then, not everyone dances to the same beat. It was easier to just offer the patch. :)

At least I am using the right Table of Contents module ;)

Thanks a lot Alexis!

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.