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
Comment #1
axel pressbutton commentedBumping 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.....
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
Comment #2
axel pressbutton commentedWas "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'
Comment #3
axel pressbutton commentedJust 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.
Comment #4
axel pressbutton commentedThought 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.
Comment #5
dawehnerdid 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
Comment #6
axel pressbutton commentedYes, 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 :(Comment #7
merlinofchaos commentedThis should be fixed in 2.4; I extended the broken HTML tag regex to check the entire thing.
Comment #8
axel pressbutton commentedThanks 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.
Comment #9
jschrab commentedI hate to say it but I think this is still not quite right. I still get mangled tags.
Generated View code example:
Option settings:
Maximum Length [512]
[X] Trim only on a word boundary
[X] Add an ellipsis
[X] Field can contain HTML
Comment #10
merlinofchaos commented#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. =(Comment #11
merlinofchaos commentedIt does appear that a change to the regex is now just removing the
<rather than everything after it. :/ Need to twiddle that regex. Again.Comment #12
axel pressbutton commentedBrilliant, Thanks for looking into this for us merlinofchaos....much appreciated :)
Comment #13
jschrab commentedI do believe that 2.5 licked this problem! Very nice job; the simplest of regex's give me a headache.
Comment #14
coreyp_1 commentedI 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 />“I’m a big fan of George Carlin,” ****** said. “I wish I could write like him, and I try, but nobody writes like Carlin.”</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:
As you can see, the
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
Comment #15
WeRockYourWeb.com commentedI'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?Comment #16
Pav-2 commentedDid you fix it? I have the same problem.
Comment #17
avner commentedsubscribing
Comment #18
Dracolyte commentedThe 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.
Comment #19
Letharion commentedThe 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.