Plugin Installer; Limit desciption length in search results

[DD32]

I'm not sure if this should be done Server-side, or client side, But i think it'd be a good idea to limit the short description length of plugins displayed on the Search results pages.

Currently for example, if you search by tag for "content" you'll see what i mean, A few plugins which are drastically longer than the others, It makes it much harder to browse through them.. And if the user is interested from the short description, they can click through to view the full length version.

Thoughts?

[rmccue]

Definitely agree. Some descriptions are much too long to display.

[Denis-de-Bernardy]

server side if anything. there is a short description that limits you to 255 characters. if plugin search returns anything else, than it should be fixed.

[DD32]

from memory, The API returns the Long description if the short description is empty, substr($long_desc, 0, 255); could solve it all.. But some fancy '....' could be added too.

[Denis-de-Bernardy]

then again, given how long it takes for wordpress.org tickets to get closed (makes you occasionally wonder if it shouldn't be named "Oubliette"), maybe this should get fixed after all. :-P

[hakre]

@DD32: substr($long_desc, 0, 255); might break HTML used in the descriptions. do the content search example.

an idea: div-ing the content, giving a maxlen, overflow: scroll. can be solved by css then.

[DD32]

The function that makes the Automatic Excerpts could be used as well, That takes care of breaking mid-tag/word i think, with balance_tags() it should work out alright..

[hakre]

Div & Style

[hakre]

I think this overflow:auto stuff looks crappy. 255 chars might be way much better, wp_kses is used an might handle unclosed tags.

[hakre]

substr (0, 255) variant

[hakre]

this looks way much better. the only thing ignored here is the case that substr() might cut and utf-8 bytesequnce apart and leaving the doors open for an ijection then.

[Denis-de-Bernardy]

I don't think your worry about utf8 injections is valid. it would get crippled by the ... that get added. patch applies cleanly against today's trunk.

[hakre]

There is a type of attack based on crippled UTF-8 with a constant bytesquence following (this time '...'). If it is the case with '...' I do not properly know but generally spoken, stuff should be done the correct way. This is not the case here in terms of taking care of the encoding. infact, no care is taken about the encoding. That is what I wanted to note to the patch.

[Denis-de-Bernardy]

Well, yeah... bit if any such attack affects this patch, there arguably are scores (and I mean scores) of other areas where mb safe functions should be used instead of default php functions.

My personal hope is that php will eventually merge the mb_ functions' code into the normal string functions. I mean, heck, it's the only reasonable way to fix all of the broken php code around. The overload ini setting just isn't enough, and using wrapper functions with conditionals on every built-in string function adds lots of overhead.

[hakre]

probably, yes. as said, just for reference.

i think php 6 will have explicit binary strings next to better utf8 support in strings. see ​http://php.oregonstate.edu/manual/en/language.types.type-juggling.php and the cast to (binary) fyi.

just overloading standard string function with mb functions (which is possible since some more time) does not help per se and can create new fields of problems instead. see the ​css classnames implementaion page for more utf8 related php links.

[Denis-de-Bernardy]

Actually, overloading currently isn't possible. I mean, it affects only a handful of functions (and it breaks *huge* amounts of scripts, precisely due to that).

[hakre]

Replying to Denis-de-Bernardy:

Actually, overloading currently isn't possible. I mean, it affects only a handful of functions (and it breaks *huge* amounts of scripts, precisely due to that).

I meant ​the overloading for certain string functions.

[Denis-de-Bernardy]

yaya, me too. tried it, hated it. broke everything.

[ryan]

Should we use wp_html_excerpt() here?

[DD32]

Should we use wp_html_excerpt() here?

I was thinking Not, since that strips tags. however... If we limit the descriptions length.. it doesnt really need HTML tags anyway (And thats extra complexity than just a substr())

Mind you, I dont see a real need to allow html in there now since it can be shortened. - A short Text blurb should be enough..

[hakre]

so shall it be. last patch ok.

[hakre]

related plugin area ui ticket #9743

[dd32]

attachment 9576.diff added

• Based off wp_html_excerpt()
• Strips HTML
• Limits to 400char (multibyte safe), and adds an horizontal ellipsis(…) if its shortened
  • Doesnt use mb_strlen(), So its not entirely mb nice, any mb strings of > 200char & < 400char will end up with an ellipsis when its not needed - WordPress doesnt currently have a compat function for it.
• Finally, re-converts multiple lines
  • And strips consecutive lines/leading/trailing lines

[ryan]

(In [11362]) Trim long descriptions in plugin installer search results. Props DD32. fixes #9576