I have set up a view to show a node body with fields Node:Body
Label: blank
Trim this field to a maximum length: True, length=1200
Trim only on a word boundary: true
Add an ellipsis:true
Field can contain HTML: true

The elipsis is not appearing on a trimmed entry

Comments

axel pressbutton’s picture

Priority: Normal » Critical

Bumping this as I have a similar sounding problem that has been quite difficult to trace the cause of...but I think I may have found the answer (no idea how to fix though obviously)

I have a textarea field that is being used in a view, it is set to;

1) Trim this field to a maximum length
2) Maximum Length = 200
3) Trim only on a word boundary
4) Add an Ellipsis

I traced the problem to content that has a para break before the max length is hit. It was a nightmare to detect as Firebug shows everythign to be OK with the HTML but on viewing source code i find that the text has been trimmed, no ellipsis has been added and a malformed close para tag is inserted.....

<div class="views-field-field-my-story-value">
    <div class="field-content"><p>My story is typical, cliché and full of sadness and joy.</p...></div>
</div>

I guess the code that adds the ellipsis needs to fire before closing the para when max length hasn't yet been reached, that or carry on and read the next section of content and do some kind of join.

Hope this sheds some light on this matter - I've set it to critical as I think it's a pretty major bug....please shout at me if not considered so.

Cheers

axel pressbutton’s picture

Title: Elipsis not shown » Malformed HTML output causing Ellipsis to not show

Was "Elipsis not shown"

Sorry, thought I'd best change the title to make it possibly warrant the raised priority. As previously mentioned this issue causes problems in Browsers such as IE6, 7 and 8 as well as Opera (9.63) as well as 'not doing what it says on the can'

axel pressbutton’s picture

Priority: Critical » Minor
Status: Active » Closed (works as designed)

Just noticed the "Field can contain HTML" option - I didn't actually count the automatically inserted closing paras and breaks when I glanced at it before. My apologies.

axel pressbutton’s picture

Priority: Minor » Normal
Status: Closed (works as designed) » Active

Thought that had fixed it but it hadn't, it still breaks if the "Trim only on a word boundary" is set and the content contains breaks and paras in the text it's trimming.

dawehner’s picture

did you tryed out to remove the ellipsis?, just a guess of mine

this is a core bug, because http://api.drupal.org/api/function/_filter_htmlcorrector/6 should work as expected

axel pressbutton’s picture

Yes, I've tried that as well :(

It seems to be breaking if I have it set with "Trim only on a word boundary" and the text in question contains a natural line break before the letter count is reached.

I had to view source to see this as can't see it with thngs like firebug and IE's tools. Firefox ignores the malformed <br</p> b ut IE 6, 7 and 8 don't along with Opera :(

merlinofchaos’s picture

Status: Active » Fixed

This should be fixed in 2.4; I extended the broken HTML tag regex to check the entire thing.

axel pressbutton’s picture

Thanks for your response merlinofchaos. And thanks for all the hard work you put in.

I've just upgraded to 2.4 and checked again; I now get the following output...

Without Field can contain HTML checked

<div class="field-content"><p>Name: FREDbr...</div>

As you can see, I now lose the </p> as well as the < at the start of the offending broken <br...

With Field can contain HTML checked

<div class="field-content"><p>Name: FREDbr...</p></div>

In this case i have the </p> but sadly still have the remants of the 'br'.

Other settings are still;

1) Trim this field to a maximum length
2) Maximum Length = 200
3) Trim only on a word boundary
4) Add an Ellipsis

Hope this helps. I was hoping to not have to control the input format for this particular field and to be honest wasn't expecting users to put short paragraphs and line-breaks in right at the top. It's meant mkore for a longer paragraphs. Also note that the name is data enter by the user, not generated.

Thanks again for your help.

jschrab’s picture

Version: 6.x-2.3 » 6.x-2.4
Status: Fixed » Needs work

I hate to say it but I think this is still not quite right. I still get mangled tags.

Generated View code example:

<div class="field-content"><p>WBCC is deeply saddened to lose one of the strongest advocates&nbsp;in our efforts to end breast cancer in Wisconsin. Mildred Leigh-Gold was a long time WBCC supporter, 3-term Board Director, and true heroine for those affected by breast cancer. Words cannot describe how much we will miss this special person. Read about Mildred on <a class="views-processed" title="Mildred Leigh-Gold" href="http://www.jsonline.com/news/obituaries/39270452.html" target="_blank">JSOnline</a>./p...</p></div>

Option settings:

Maximum Length [512]
[X] Trim only on a word boundary
[X] Add an ellipsis
[X] Field can contain HTML

merlinofchaos’s picture

Status: Needs work » Active

#8: I don't know where the < at the beginning of the br went, but I don't have anything that will just remove those I don't think, unless I totally messed something up. It should chop everything from the < on. Other than that, it looks like it's working. I'll see if I can reproduce that, though, but I didn't get any mangling like that in my tests. Though it does appear that jschrab is seeing a similar issue. =(

merlinofchaos’s picture

It does appear that a change to the regex is now just removing the < rather than everything after it. :/ Need to twiddle that regex. Again.

axel pressbutton’s picture

Brilliant, Thanks for looking into this for us merlinofchaos....much appreciated :)

jschrab’s picture

Version: 6.x-2.4 » 6.x-2.5

I do believe that 2.5 licked this problem! Very nice job; the simplest of regex's give me a headache.

coreyp_1’s picture

I think my problem stems from the same issue.

I have a node with this as the node body (edited, but using the same # of characters):
<p>******** University senior Matt ****** knows his roots as a stand-up comedian.<br /><br />&ldquo;I&rsquo;m a big fan of George Carlin,&rdquo; ****** said.&nbsp; &ldquo;I wish I could write like him, and I try, but nobody writes like Carlin.&rdquo;</p>

Settings are:
Trim to maximum length: 150
Trim only on a word boundary: yes
Add elipses: yes
Strip HTML tags: yes
Field can contain HTML: no (actually, I get the problem whether this is set to yes or no)

This is output:

******** University senior Matt ****** knows his roots as a stand-up comedian.
&ldquo;I&rsquo;m a big fan of George Carlin,&rdquo; ****** said.nbsp...

As you can see, the &nbsp; is being mangled, presumably since it appears on the word boundary.

Let me know if I need to file this as a separate issue.

-Corey

WeRockYourWeb.com’s picture

Version: 6.x-2.5 » 6.x-2.7

I'm having the opposite problem - in my aggregator source view, HTML is present, but in my Views block, the HTML (with the exception of link (a) tags) in the <span class="field-content">...</span> gets filtered out, even though I haven't told it to "strip" html. Any ideas?

Pav-2’s picture

Did you fix it? I have the same problem.

avner’s picture

subscribing

Dracolyte’s picture

The problem is actually in the "Trim only on a word boundary" code. If that's checked, by the time the _filter_htmlcorrector function gets the text, its tags have already been mangled. You can just print out the $text param in the filter.module to see it what it's getting.

function _filter_htmlcorrector($text) {
print '<br> Debug: ' . $text;
Letharion’s picture

Status: Active » Fixed

The original question here is now over a year and half old, the last update on the issue was regarding a Views version that is now rather old, and no-one has touched the issue in nearly 6 months.

As both so much time and so many releases have passed, I'm going to close this as fixed.
If this remains a problem, please open a new issue.

Status: Fixed » Closed (fixed)

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