wp_widget_rss_output with show_summaryshows two ellipses

[aaroncampbell]

You should be able to see this by looking at the WordPress Development Blog feed on the dashboard. One is actually three periods, and one is …

It looks like the problem is that feeds (including those created by WordPress) often have a description that is shorter than 360 characters and already ends in [...], which means that the string is not shortened at all, but is treated as though it was. The … is added in wp-includes/default-widgets.php on line 804:

$desc = wp_html_excerpt( $desc, 360 ) . ' […]';

[ShaneF]

Going to work on a patch right now for it.

[tosak]

Patch only adds […] if strlen is over 360.

[nacin]

Patches are only "fixed" once they are committed to the codebase.

[nacin]

Patch attached to remove double ellipses appearing at the end of a description.

[westi]

Not sure this is the best solution also as it is not a regression I am going to move it to 3.0

[nacin]

Ah, thanks, I meant to punt this.

Not sure if this is the best solution either, but the problem is that you can't simply remove any [...] or […] that appear in a description. They're sometimes used to denote the removal of information in a quote, for example, so they might not always be deliberately at the end of a description. The patch avoids using regular expressions or multiple substr to check if the ellipses appear at the end of the description.

Then again, a simpler way might just be to check mb_strlen for < 360.

[nacin]

Noticed that patch 2 was missing a space before the [&hellip;]. This one adds it.

[Denis-de-Bernardy]

mb_strlen() is not available on all servers, as can be seen based on the couple of forum support tickets related to Magpie failing to convert UTF-8 into UTF-8

[Denis-de-Bernardy]

an alternative approach could be to try to remove ellipses using preg_replace()

[nacin]

We use a handful of mb_* functions, though perhaps that should be addressed. In this case, I used mb_strlen() since wp_html_excerpt() uses mb_substr(). So really, the latest patch works fine until we rid core of mb_* functions.

I had wanted to avoid preg_replace() but yes, that would do it as well.

[nacin]

Replying to nacin:

We use a handful of mb_* functions, though perhaps that should be addressed. In this case, I used mb_strlen() since wp_html_excerpt() uses mb_substr(). So really, the latest patch works fine until we rid core of mb_* functions.

I stand quite corrected. Every time an mb_* function is used, its existence is first checked, except for mb_substr, which has a fallback in compat.php.

[nacin]

New patch, using preg_match.

Checks for existence of [...] or [&hellip;] at the end of an excerpt. If neither is found, it adds [&hellip;]. If [...] is found, it converts it to [&hellip;].

[nacin]

Using regular expressions

[hakre]

sometimes a substr does work as well:

$desc = preg_replace( '/\[...\]$/D', ' […]', $desc );

might be faster then a preg_replace. even with an if and a str_replace().

[nacin]

[13328] Don't show two ellipses in wp_widget_rss_output(). Fixes #11244 props miqrogroove