Skip to:
Content

Opened 22 months ago

Closed 4 weeks 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: Activity Keywords: has-patch 2nd-opinion
Cc:

Description

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:

http://bp-fr.net/groups/utilisation-configuration-optimisation-de-buddypress/forum/topic/probleme-de-guillemet-dans-buddypress#post-4986

This problem was also under WP 3.3.2/BP 1.5.4

Attachments (1)

4265.diff (1.4 KB) - added by imath 12 months ago.

Download all attachments as: .zip

Change History (15)

comment:2 DJPaul22 months 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?

comment:3 boonebgorges22 months 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)

comment:4 chouf122 months 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
`if(bp_use_wp_admin_bar())
    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
<pre>if(bp_use_wp_admin_bar())
    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
<code>if(bp_use_wp_admin_bar())
    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
http://bp-fr.net/2012/07/probleme-de-quotes/
And here in a forum topic
http://bp-fr.net/groups/utilisation-configuration-optimisation-de-buddypress/forum/topic/probleme-de-quotes-bis-repetita/

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). ?!!!

comment:5 chouf122 months 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
http://bp-fr.net/groups/utilisation-configuration-optimisation-de-buddypress/forum/topic/probleme-de-quotes-bis-repetita

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

Last edited 22 months ago by chouf1 (previous) (diff)

comment:6 DJPaul16 months 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

imath12 months ago

comment:7 imath12 months ago

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

Hi,

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.

comment:8 DJPaul12 months ago

  • Milestone changed from Future Release to 1.8

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

comment:9 boonebgorges11 months ago

  • Milestone changed from 1.8 to Future Release

comment:10 needle2 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 );

comment:11 boonebgorges2 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.

comment:12 boonebgorges6 weeks 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?

comment:13 boonebgorges4 weeks ago

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

comment:14 boonebgorges4 weeks ago

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