Skip to:

Opened 3 years ago

Closed 19 months ago

#4265 closed defect (bug) (fixed)

WP 3.4/BP1.5.6 – issue with quotes on SWA

Reported by: chouf1 Owned by:
Milestone: 2.0 Priority: normal
Severity: normal Version: 1.7
Component: Component - Activity Keywords: has-patch 2nd-opinion


In the WP mo file there is a translation for curly quot opening and closing quot 8220 and 8221 to respectively laquo and raquo

This is welle translated in forum post and comments, and NOT in the site wide activity witch ouput 2 closing quote.

The only way actually is to not translate the quote and using the original 8220/8221, but this gives english quotes; In french we use laquo and raquo.

I searched and tried many things, but couldn’t isolate the origin who sits probably between wp-includes/formating.php and buddypress/…/…/backpress/functions_kses.php and some filter in bp-activity-filter.php

The wrong things are the two closing quotes in french.
For better understanding you can read here, but’s in french:

This problem was also under WP 3.3.2/BP 1.5.4

Attachments (1)

4265.diff (1.4 KB) - added by imath 2 years ago.

Download all attachments as: .zip

Change History (15)

#2 @DJPaul
3 years ago

  • Keywords reporter-feedback added

chouf1, can you look at #4297 -- might this be your problem? Do the wrong quotes always appear, or is it only when they are loaded/posted with AJAX?

#3 @boonebgorges
3 years ago

I'm afraid I'm unable to reproduce this. chouf1, can you give exact details on how to reproduce the issue? When I put the following text into an activity update, it works fine:

Je teste les « guillemets » français

The guillemets come though my activity stream looking just fine. (WP 3.4.1, BP 1.5.x/trunk)

#4 @chouf1
3 years ago

  • Version set to 1.5.6

Hello Boone and DJPaul,

i actually use bp 1.5.6 standart and WP 3.4.1 french edition.
The problem sits in WP, i guess because BP looks fine now.

Before latest update, I changed the WP 3.3.2 translation for curly quotes from 8220 to « (alt+0171) to have something correct.

This is what you can see under the link i give in my first post here.

Since update to 3.4.1 (with use of the original FR translation) quotes seems to be correctly outputed. That said, this FR translation missed the closing curly cote in the 3.3.2 version)

When posting on a forum, the quotes are OK for now. But inserting code with tags or bakcsticks in a forum post or an answer is completly weird. Same thing in blog post and comments.

To reproduce, try with this exemple with php and html who looks awfull:

Posting some code inside backsticks
    return bpln_get_notifications_for_wpadminbar();
	$html= '<li id="bp-adminbar-notifications-menu"><a href="' . $bp->loggedin_user->domain . '">';
	$html.=__( 'Notifications', 'buddypress' );

	if ( $notifications = bp_core_get_notifications_for_user( $bp->loggedin_user->id ) )
            $html.="<span>".count( $notifications )."</span>";`

Posting code using pre tag
    return bpln_get_notifications_for_wpadminbar();
	$html= '<li id="bp-adminbar-notifications-menu"><a href="' . $bp->loggedin_user->domain . '">';
	$html.=__( 'Notifications', 'buddypress' );

	if ( $notifications = bp_core_get_notifications_for_user( $bp->loggedin_user->id ) )
            $html.="<span>".count( $notifications )."</span>";</pre>

Posting code using code tag
    return bpln_get_notifications_for_wpadminbar();
	$html= '<li id="bp-adminbar-notifications-menu"><a href="' . $bp->loggedin_user->domain . '">';
	$html.=__( 'Notifications', 'buddypress' );

	if ( $notifications = bp_core_get_notifications_for_user( $bp->loggedin_user->id ) )
            $html.="<span>".count( $notifications )."</span>";</code>

You can see it here in a blog post
And here in a forum topic

Output changes a little bit if i remove those filters via functions.php

remove_filter( 'bp_get_the_topic_latest_post_excerpt', 'bp_forums_filter_kses', 1 );
remove_filter( 'bp_get_the_topic_post_content', 'bp_forums_filter_kses', 1 ); 

Even if this ticket looks as a WP problem, it seems to me that there is somwhere a double filtering by calling a WP filter and adding a BP filter (or more). ?!!!

#5 @chouf1
3 years ago

Oups, forgot to give you the way to reproduce
Write something between quotes with no space and with space
"test" and " test "

The first one is correct, the second shows 2 closing quotes.

Is correct on the forum activity
View here in the reply

Is not correct on the swa, nore in a swa comment

Last edited 3 years ago by chouf1 (previous) (diff)

#6 @DJPaul
3 years ago

  • Component changed from Core to Activity
  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to Future Release

Moving to future release for further investigation

2 years ago

#7 @imath
2 years ago

  • Keywords has-patch 2nd-opinion added
  • Version changed from 1.5.6 to 1.7


If you add spaces between the quote and the word, then wptexturize inverse the quotes, i think it's a WordPress trouble.
example : " guillemets " will be filtered this way : » guillemets « by wptexturize in an activity or a post...

The only thing BuddyPress can look at is the priority of wptexturize. In 1.7, if you post an activity with no space between the quote and the word, then you have this : »guillemets ». In a WordPress post, the quotes are ok.

If wptexturize is applied after stripslashes_deep, then the quotes are ok like on a WordPress post. I suggest the 4265.diff attached to this ticket.

#8 @DJPaul
2 years ago

  • Milestone changed from Future Release to 1.8

Let's see if we can figure this out for BP 1.8

#9 @boonebgorges
2 years ago

  • Milestone changed from 1.8 to Future Release

#10 @needle
20 months ago

Wanted to bump this ticket because I've just had a couple of clients notify me that their activity items don't render correctly. I realise that wptexturize() can behave oddly when there's whitespace between quotes and text, but standard usage should be supported at minimum. imath's analysis seems spot on and his patch (which I implement via a plugin) sorts the issue out for me, but ideally that shouldn't really be necessary.

In the meantime, here's the ncode for anyone who runs into this and doesn't want to alter BP core:

// remove existing filters
remove_filter( 'bp_get_activity_action',                'wptexturize' );
remove_filter( 'bp_get_activity_content_body',          'wptexturize' );
remove_filter( 'bp_get_activity_content',               'wptexturize' );
remove_filter( 'bp_get_activity_parent_content',        'wptexturize' );
remove_filter( 'bp_get_activity_latest_update',         'wptexturize' );
remove_filter( 'bp_get_activity_latest_update_excerpt', 'wptexturize' );

// re-add after stripslashes_deep
add_filter( 'bp_get_activity_action',                'wptexturize', 11 );
add_filter( 'bp_get_activity_content_body',          'wptexturize', 11 );
add_filter( 'bp_get_activity_content',               'wptexturize', 11 );
add_filter( 'bp_get_activity_parent_content',        'wptexturize', 11 );
add_filter( 'bp_get_activity_latest_update',         'wptexturize', 11 );
add_filter( 'bp_get_activity_latest_update_excerpt', 'wptexturize', 11 );

#11 @boonebgorges
20 months ago

  • Keywords needs-unit-tests added
  • Milestone changed from Future Release to 2.0

I think we can fix this but we really need to have unit tests before we go messing with it.

#12 @boonebgorges
19 months ago

  • Keywords needs-unit-tests removed

I messed around for a while trying to write unit tests, but it's not really practical. (wptexturize() loads all the replacement texts into a static variable on the first load, before the test would have access to filter 'gettext'.)

I did manage to reproduce the issue, and I can confirm that slashes appear to be the issue. When our content comes from the db and looks like this: Here are some \"quotes\", wptexturize() first inserts a space to make \" quotes \" and then interprets the quotes to belong to the slashes - thus the incorrect direction on the first one.

My gut feeling is that, instead of backing up wptexturize, we should be running stripslashes_deep() earlier, since the root of the problem is BP's perennial double-escaping. Does anyone see an issue with moving our 'stripslashes_deep' filters back to priority 9, or even earlier?

#13 @boonebgorges
19 months ago

Crud, I forgot to close the ticket with my commit message. Fixed in r8156

#14 @boonebgorges
19 months ago

  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.