So I’m looking all over the page checking all of my divs and spans trying to fugure out what is shrinking all of my fonts in the second half of the page and then I zero in on it . . . . . 

It appears that the word limit plugin limits more than words. . .  it also removes the closing </p> tag.

That’s just not right. 

Is the formatting for your {main_content} field Xhtml?
The only thing I can think of is that you have manually added <p> tags to your entry which has its formatting turned to Xhtml. That is to say you can see <p> tags in our entry form field rather than adding it by using a paragraph break

have you tried setting your custom field to formatting: none

then using tags this way in your template:

This in theory would work, though i cannot confirm right now.

Just to clarify here Kurt, it sounds like that field has its formatting set to “none” and the markup is keyed in manually as part of the field’s content?  I’m not thinking of a way of changing that plugin that would make sense, as it would need to read and fully understand the intent of HTML markup within a field.  What if someone constructed fields so that the markup did not begin or terminate within that particular custom field?  There could be an intentional lack of a matched pair in that situation.  Also, which markup would be safe to discard from the leftover words and which would be safe to keep?  There’s not really any way again of knowing the publisher’s intent.

If you’re using the word limiter, it might be best to use a format type for the custom field.  But if you always know the intent and what markup is supposed to be there, you could easily modify the Word Limiter plugin to see if there is a closing paragraph tag, and if there’s not, slap one on the end.

That is, if the first x amount of words is in a paragraph   Ive talked about this with a coworker, and decided that it definitely needs some dev time - building an array of opening tag pairs etc, then closing them sequentially.

the_butcher, you could still easily have a problem where your layout was expecting and required <div class=“foo”>bar</div>, but if the opening part of that tag fell outside of the word limit, it would get cut out. In that case the plugin would have to know explicitly what markup for the field is “required”, and the only real way to handle that is for that specific site’s developer to modify the plugin within the parameters of what markup they know their layout requires.

Or even just put layout critical markup within the template itself, or even a different custom field. Good design never hurt anyone.

Just to clarify here Kurt, it sounds like that field has its formatting set to “none” and the markup is keyed in manually as part of the field’s content?

That would be defined version of what I was trying to say

Hello everyone. . .

OK. . . the formatting of the field is set to XHTML and there are no paragraph tags in the entry. . . .

I really don’t want to set the field formatting to none if it can be avoided becuase setting it that way by default will mess with the rest of a very full site, and my poor web-master/publisher has enough to remember about EE already. ;~)

For now I’ve just added a closing </p> to the template and it works. .. . but I’m thinking there must be a better way.

I’m guessing that the XHTML formatting happens before the word limiting. . . .  so is it possible to have the word limiting happen before the XHTML formatting. . .  then we would be home free. . . at least I think we would.

So indeed it is.  A quick solution would be to change the formatting to “none”, and use the XHTML typography plugin around the field and word limit plugin.  The inner plugin will get parsed first, and then XHTML typography applied only to the remaining text.

For now I’ve just added a closing </p> to the template and it works. .. . but I’m thinking there must be a better way.

Yes, me to. For very short entries that are not shortened because they don’t reach the threshold, that actually leads to </p></p>. Well, not much of a problem in reality, if not exactly elegant.

greetings and salutations ...

i am also experiencing the removal of the </p> using both {word_limit} and {word_limit_plus} plugins.
as with kurt my body field has no <p> tags, is XHTML and i’m also loathed to change it for the sake of one template.

but if i manually add a </p> in the template then for entries that are less than xx words then i’ll get an erroneous </p> and the page will fail XHTML validation.

have any of you clever bods out there thought of an alternative answer?

I solved this by just stripping XHTML tags out of the truncated content.  I keep the excerpts small enough that it is fine if it is condensed into a single paragraph.

I use word_limiter_plus and at the beginning of the word_limiter_plus function in the plugin file, I just added “$str = strip_tags($str);”, i.e:

And then I just put my truncated content inside of <p> tags:

And I don’t have to worry about broken tags then.

Other than stripping the tags, you’d have to do some HTML parsing or DOM tree parsing to keep track of the tags in order to properly close them all.

that’s fantastic! many thanks

That’s great dreamscape,

Now if I can just remember what site I was working on back in August . . . I can update their templates. .. .

Thanks.

Man!  Needed that.  This is a great solution even two years later.  Thanks dreamscape.

Glad you were able to find this thread, Grant!  There are other options now as well, including TruncHTML I believe; or possibly Word Limit Plus. =)