Opened 3 years ago
Closed 3 years ago
#11244 closed defect (bug) (fixed)
wp_widget_rss_output with show_summaryshows two ellipses
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | low | Milestone: | 3.0 |
| Component: | Widgets | Version: | 2.9 |
| Severity: | trivial | Keywords: | has-patch |
| Cc: |
Description
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 ) . ' […]';
Attachments (5)
Change History (18)
- Component changed from General to Administration
- Owner set to ShaneF
- Status changed from new to accepted
- Resolution set to fixed
- Status changed from accepted to closed
Patch only adds […] if strlen is over 360.
- Resolution fixed deleted
- Status changed from closed to reopened
Patches are only "fixed" once they are committed to the codebase.
- Component changed from Administration to Widgets
- Keywords has-patch added
- Owner changed from ShaneF to nacin
- Priority changed from normal to low
- Severity changed from normal to trivial
- Status changed from reopened to accepted
Patch attached to remove double ellipses appearing at the end of a description.
- Milestone changed from 2.9 to 3.0
- Owner changed from nacin to westi
Not sure this is the best solution also as it is not a regression I am going to move it to 3.0
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.
Noticed that patch 2 was missing a space before the […]. This one adds it.
- Keywords needs-patch added; has-patch removed
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
an alternative approach could be to try to remove ellipses using preg_replace()
- Keywords dev-feedback added
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.
comment:10
in reply to:
↑ 9
nacin — 3 years ago
- Keywords dev-feedback removed
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.
comment:11
nacin — 3 years ago
- Keywords has-patch added; needs-patch removed
New patch, using preg_match.
Checks for existence of [...] or […] at the end of an excerpt. If neither is found, it adds […]. If [...] is found, it converts it to […].
comment:12
hakre — 3 years ago
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().
comment:13
nacin — 3 years ago
- Resolution set to fixed
- Status changed from accepted to closed

Going to work on a patch right now for it.