#3175 closed defect (bug) (duplicate)
Arabic group URLs for group slugs not always work
Reported by: | Menelik Seth | Owned by: | |
---|---|---|---|
Milestone: | 1.5 | Priority: | normal |
Severity: | Version: | 1.2.8 | |
Component: | Groups | Keywords: | |
Cc: |
Description
Arabic group URL slugs are a hit and miss. Single words seem to always work. URLs with spaces in them sometimes work, but I've come across one particular URL that returns a "Bad Request!" 400 error, whenever I try to create a group using it:
Some notices:
- I set the database and the bp_bp_groups table collocation to cp1256_general_ci
- the ‘name’ field in the wordpress database takes the Arabic text just fine. For example:
جامعة الملك عبد العزيز
- the ‘slug’ field records seemingly random characters instead. For example:
%d8%ac%d8%a7%d9%85%d8%b9%d8%a9-%d8%a7%d9%84%d9%85%d9%84%d9%83-%d8%b9%d8%a8%d8%af-%d8%a7%d9%84%d8%b9%
- I tried following this guide http://is.gd/dusori (Enableing Chinese, Arabic and Other High Unicode in WordPress Slugs
), but it didn’t work (ended up with 404 errors)
Attachments (2)
Change History (8)
#3
@
14 years ago
- Component changed from BuddyPress.org to Groups
- Keywords reporter-feedback added
Menelik, if you create a new group with this data, does the same problem occur? (best to delete the old group first, if you have a testing server). Are you on BP 1.2.8?
#4
@
14 years ago
Sorry for the late reply guys,
Firstly thank you for the replies. Yes, I'm on BP 1.2.8 and WP 3.1.2
What I've done since:
I've dropped the database via PHPMyAdmin, and created a new one. Re-Installed WP and re-activated BP. I'm using a locally hosted XAMPP installation. Let me know if you need additional info. I've attached error400.jpg note the address bar.
#5
follow-up:
↓ 6
@
14 years ago
- Keywords reporter-feedback removed
- Milestone changed from Awaiting Review to 1.3
- Resolution set to duplicate
- Status changed from new to closed
I can't recreate this on trunk, even when I switch to cp1256 and cp1256_general_ci. However, I could easily recreate this on a 1.2.8, even with the default collation. URL in the browser shows it was the issued which we fixed in #880. The fix is in trunk.
It's just the way the slug is stored in the database. I didn't change my database collation from whatever the default was. Per my screenshot, I don't receive any 404 errors (tested on trunk).