Potential Bug in Profile Comments page

donovanb

If you go here:

http://your.exampleforum.com/profile/comments/1/<user>

And look at the source.. I am getting broken HTML.

Mine looks like this:
<td id="main-he…</div>

Donovan

R_J

Vanilla normally uses id="Uppercase_Underscore" and when I look at the profile page, I do not see a HTML table...

donovanb

Okay, this is a result of importing comments from a vBullitin forum that allowed HTML comments.

It appears that comments page above simply cuts (shortens) a comment to a certain number of characters, then adds '...' to it. If I could find that function, I could perhaps improve it to escape the characters to HTML equivalents or something.. otherwise raw HTML will mess up that comments page.

R_J

The "User feature" in Vanilla is something that is provided by /applications/dashboard. The forum with categories, discussions and comments is the forum application that is provided by /applications/vanilla.
So the ProfileController is defined in the dashboard, but profile/comments is a hook ("profileController_comments_create") that you can look up in the hooks file of the vanilla application: /applications/vanilla/settings/class.hooks.php

You can expect that either
a) the data is fetched in this controller with a special method that returns shortened code (unlikely)
b) the data is fetched and gets shortened in the controller, afterwards passed to the view (that would be clean)
c) the data is fetched and passed in full length to the view

It is the last alternative which might not be the cleanest solution but for people who would like to customize their forum by view overrides, this is the most comfortable solution.

I would expect the view to be /applications/vanilla/views/profile/comments.php but to my surprise it is /applications/vanilla/views/discussion/profilecomments.php, you can see that in the method in the hooks file.

In the view you can find echo sliceString(Gdn_Format::plainText($Comment->Body, $Comment->Format), 250);

donovanb

Thanks, sliceString is defined in library/core/functions.general.php (line: 3325)... but it looks like it is widely used, so I don't want to override it. Instead, I am overriding the view that you pointed to in my theme.

For others, see "Overriding other views" 3/4's down the page:
https://docs.vanillaforums.com/developer/addons/view-overrides/

In my new override view, I simply did:
echo sliceString(Gdn_Format::plainText(htmlentities($Comment->Body), $Comment->Format), 250);

I'll know if this worked when I re-import the data (I had deleted the comments to get the page to view right before).
Guessing it works. ;-)

R_J

If plainText() keeps some HTML markup, then using sliceString() on that would be a bad idea and still an error to report.

Therefore I made a HTML test comment in my forum:

<table><tr><td>1</td></tr></table><table><tr><td>2</td></tr></table><table><tr><td>3</td></tr></table><table><tr><td>1</td></tr></table><table><tr><td>2</td></tr></table><table><tr><td>3</td></tr></table><table><tr><td>1</td></tr></table><table><tr><td>2</td></tr></table><table><tr><td>3</td></tr></table><table><tr><td>1</td></tr></table><table><tr><td>2</td></tr></table><table><tr><td>3</td></tr></table><table><tr><td>1</td></tr></table><table><tr><td>2</td></tr></table><table><tr><td>3</td></tr></table><table><tr><td>1</td></tr></table><table><tr><td>2</td></tr></table><table><tr><td>3</td></tr></table>

Just a bunch of simple tables, since your problem came up with some td element. When looking at the comments, I see this as "1 2 3 1 2 3 1 2 3 1 2 3" without any markup - just what I would expect as the result of a function called "plainText".

Are you sure everything is correct with the initial comment? Does it really have the format HTML?

donovanb

Hi R_J, Your "HTML" comments are likely getting put into the db differently than my imported ones... as you are not seeing the actual HTML <tr><td>... elements in your comments. I was.??

Anyway, if you notice my original error <td id="main-he…</div>. It shows the ... that comes from the sliceString() function, and that is the point at which the page broke.

Maybe this problem is only a problem when importing data? I don't know.

Thanks for all the help / pointers. I'll update this thread when I re-import and let you know if my fix actually fixed my problem.

R_J

But the sliceString slices after plainText has converted to plain text. plainText shouldn't leave any remaining td element at all. The only reasons why they still remain is either the Comment.Format is wrong or the html is malformed

donovanb

Hi @R_J, <, > is plain text... though a browser will still render it as HTML.

I did a re-import, and the issue remained... this is what actually fixes the page rendering for me.:
echo htmlentities(sliceString(Gdn_Format::plainText($Comment->Body, $Comment->Format), 250));

Although, obviously, this eliminates the ability to render HTML.

I'll post a before and after snippet so that people can better understand what is happening.

donovanb

Here is a before the fix image.. note that forum adds are appearing at the bottom of the page:

donovanb

Here is the same page after adding the 'htmlentities' fix. Note the ads appear correctly on the right now. -D

R_J

Your tweak obviously fixed this problem, but I think the problem lies in the malformed content.

Put that into a plugin and visit /plugin/test:

    public function pluginController_test_create($sender, $args) {
        $test = '<table><tr><td>1</td></tr></table>';
        decho(Gdn_Format::plainText($test, 'html'));
    }

You will see that there are no remainders of html in the output.

Can you post the original comment body (enclosed in ~~~) and its Format in the Comment table?

donovanb

Hi @R_J, I'm on the clock just now... would have to perform a SQL statement on the original DB to grab that.. and don't have time right now.

For your test above, that does not necessarily address my issue.. which is that the sliceString function is cutting off the HTML at the 250 character mark... thus munging the HTML.

Donovan

donovanb

Okay.. this also munges it:

R_J

I think we are going in circles.

Yes, if sliceString() works on a html, results are unpredictable. But in the view you find the line echo sliceString(Gdn_Format::plainText($Comment->Body, $Comment->Format), 250);. So sliceString works on the result of plainText

In a long version that is equal to:

$textWhichMightContainHtmlTags = $Comment->Body;
$format = $Comment->Format;
$textWithoutHtml = Gdn_Format::plainText($textWhichMightContainHtmlTags, $format);)

$partOfTextWithoutHtml = sliceString($textWithoutHtml , 250);

echo $partOfTextWithoutHtml;

See what I mean? sliceString() should not get any html tags as input if plainText() doesn't fail. So the problem is either the function plainText() or a malformed comment. It would be nice to know if this is
a) only an edge case based on some weird import
b) a general problem with the porter script for vBulletin
c) a problem with plainText()

donovanb

Hi @R_J, I think you might be mis-understanding what "plain text" is (or maybe I'm not understanding you). All plain text is, is Text... and browsers render text. ;-) If the text happens to be HTML, it is going to try to render it as such because the page is an HTML page.

Okay, so, I simply reverted my profilecomments.php view to the default view, copy pasted my long text example above in a regular forum comment (not discussion), then went to the profile comments page and it indeed munged my page.

So, without me not knowing everything about Vanilla, I would categorize this as a bug personally.

I remember back in the day we (as programmers) would play "skin the cat". The method as to how to create shortened / abridged versions of long text was always a good one to practice with this game. You could count characters, then add the dot dot dot, but that would likely cut a word short and was not too elegant. So, some people would count words.. but then that also had it's own issues at times... for example, one could create a 200 long word. ;-)

In this case, it's just counting (plainText) characters, thus randomly cutting off HTML elements, whatever they may be, at the 250 character mark.

Hope that helps.

Donovan

donovanb

One reason you may not want to categorize this as a bug, is that (it appears) Vanilla does not allow HTML in comments by default. (thus there would never be this issue in a normal install).

EDIT: Well, technically, Vanilla does allow HTML, but it escapes it and displays it raw.

R_J

@donovanb said:
Hi @R_J, I think you might be mis-understanding what "plain text" is (or maybe I'm not understanding you). All plain text is, is Text... and browsers render text. ;-) If the text happens to be HTML, it is going to try to render it as such because the page is an HTML page.

At least now I know what the misunderstanding has been! For me plain text, opposed to "uncategorized" text, is text without markup.

But we do not have to talk about that any more. I found out that I did my test wrong. I've inserted html into the Comment table and that was wrong. My approach was too technical and if I simply insert the html, it breaks the comments page for me, too.

That's clearly a bug. I hope the intention had been that sliceString gets a string without any markup so that cutting it doesn't cause the errors you have observerd.