I recently updated to EE v. 1.6.6 (build 20081114). I had been remiss about doing regular updates, so I went straight from v.1.6.2 to 1.6.6.

The problem: the text formatting in my wiki module has now gone all wonky.

Background: I’ve had a wiki (with over 200 articles on it) on my site for quite a while. Almost two years. It was working fine before the recent update.

Now the wiki seems to be randomly ignoring many div tags (but not all of them). And it won’t automatically recognize line breaks within div tags. And it inserts a line break after an “underline” tag (u).

The issue seems to be related to the TOC plugin that I have installed. The issues manifest when I have text formatting set to “Wiki TOC”. Unfortunately, setting the text formatting to “auto br” resolves some of these issues but creates others, because (for some reason) it causes the text size and line-height to shrink down so much that it becomes almost unreadable.

Like I said, I had none of these problems before I upgraded to v. 1.6.6. That was the only change I made.

Any idea why the update might have caused these formatting issues?

I notice that other people have recently been reporting similar formatting issues with their wikis, but these issues seem to resolve upon upgrading to the latest build. But as far as I know, I’ve installed the latest build. But I’m still encountering these problems.

Hi, Alex,

The TOC plugin really should not be used as the text formatting for a field; it is really intended purely to create a table of contents.  Is there a reason you set it as the field formatting?

Hi Lisa,

I’m not sure what you mean when you say the TOC plugin shouldn’t be used as the text formatting “for a field.”

I set Wiki TOC as the formatting option in my Wiki preferences, as it specifies to do in the instructions for the Wiki TOC plugin. This is what I meant in what I wrote above. If I don’t set the formatting option to Wiki TOC, then I don’t think the plugin will create a table of contents.

Hi, Alex - my fault, I was incorrect; it has been awhile since I worked with that plugin. Do you have a link to one of the affected pages we could see?

Sure, here’s my page of Loch Ness Monster Hoaxes in my wiki.

There are a bunch of things wrong with this page. First, here’s what the code looks like for the top two lines:

It should be maroon colored, but the wiki is just ignoring this line of code.

Second, the “Nessie Haiku” box near the top. I use div tags to create this box (the wiki is recognizing these tags), but it’s not inserting any automatic line breaks inside the box.

Finally, the line height of the text throughout the article has become very small. I don’t understand why.

These formatting issues only appeared when I updated to v.1.6.6.

What do you have set for “HTML Formatting for Articles”?  You need that set to “Allow all HTML”.

Yes, that’s what I have set for HTML Formatting for Articles.

As I said above, everything was working fine, formatting correctly, etc., for the past two years. It was only when I upgraded the system a few days ago that things started acting strangely.

Thank you for the rundown Alex; I am further researching this and will be back with you as soon as I have more information.

Thanks, Lisa.

Just one further observation. I think the use of div tags may be triggering the formatting problems, because the problems only occur on those pages where I’m using div tags. For instance, here’s a page in my wiki that doesn’t include any div tags in the article. It’s formatting correctly.

Alex,

As a quick test, can you make two quick test wiki articles with some lorem ipsum text?  One with div tags and one without.  Hit us with the links to both articles.

-greg

Hi Greg,

I did one better: I made three lorem ipsum test pages.

The first one is straight text, no div tags. Everything renders correctly.

The second one has some div tags. The maroon text displays correctly. However, in the box floating to the right, all the text is being run together (there should be automatic line breaks).

The third page is exactly the same as the second, except for the addition of a TOC tag. Now the text has lost all the automatic line breaks throughout the article. In addition, the text following the first header has become oddly squished together.

Alex,

Interesting.  I’ll do some checking to see if this is intended or not.  Hang tight and we’ll get back with you.

Thanks,

-greg

The second one is- I think- correct.  The one thing that has changed is the table.  And the current typography class (using xhmtl) does not automatically add br or p tags inside tables.  They’re protected now, so p/br needs to be added manually when inside a table.

However- since #2 is correct it does suggest something is indeed wonky with #3.  I’ll try to replicate and see what’s going on there.

Hm- I can’t replicate on mine, but it looks like there are no p tags added when you use the TOC.  Can you do me a favor- ‘edit’ the TOC test one, copy everything in the field to a text file, zip it up and attach it.  I want to see if I can replicate with that.

Hi Robin,

Attached is the file. (Unfortunately I don’t have the means to zip it on my laptop).

I fiddled with it a bit (removed the table from inside the div tag), but the basic problem remains the same.

Greg and Robin,

I’ve been experimenting around with my wiki a bit more, trying to see if I can make sense of how it’s behaving. What I know is that changing the text formatting option of my wiki from “auto br” to “wiki TOC” definitely changes the formatting a lot. Auto br causes a much smaller font-size and line-height to appear. I don’t know why. I have wiki TOC set to use ExpressionEngine’s XHTML Typography class. Does “Auto BR” perhaps use a different typography class?

Also, the underline tag “u” now triggers a line break. I can’t figure that one. Is the u tag no longer recognized? Should I be using css to underline phrases?

If I create new pages I can use a div tag to change the color of text. But that’s not working on my old pages.

Anyway, it looks like I’m probably going to have to re-edit every page in my wiki (sigh…), but if I do that, what’s the most stable, long-term option I can choose? i.e. should I not use Wiki TOC?

Sorry I was slow, Alex.  I can replicate with the text you sent over.  Oddly, I couldn’t with my own.  There’s a quirky interaction going on and I haven’t narrowed in on what exactly triggers it.

I did get a fix in place, but I’d like to clarify why exactly it’s breaking like it is.

Let me shift to the ‘bug’ forum and poke just a bit more.

OK- got a new file up, tweaked for compatibility with the current typography class.  Should do the trick for you, so just grab a fresh copy and replace the old plugin.

Thanks for the nice catch- the bug only showed up under certain circumstances, making it harder to find.  If you do run into any trouble with it, just let me know.