Opened 13 years ago
Closed 11 years ago
#4265 closed defect (bug) (fixed)
WP 3.4/BP1.5.6 – issue with quotes on SWA
Reported by: |
|
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:
This problem was also under WP 3.3.2/BP 1.5.4
Attachments (1)
Change History (15)
#2
@
13 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
@
13 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
@
13 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 `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). ?!!!
#5
@
13 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
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
#6
@
12 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
#7
@
12 years 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.
#8
@
12 years ago
- Milestone changed from Future Release to 1.8
Let's see if we can figure this out for BP 1.8
#10
@
11 years 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
@
11 years 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
@
11 years 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?
Here a comment on group activity showing the 2 closing french quotes
http://bp-fr.net/groups/utilisation-configuration-optimisation-de-buddypress/forum/topic/probleme-de-guillemet-dans-buddypress#post-4976