#3175 closed defect (bug) (duplicate)
Arabic group URLs for group slugs not always work
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 1.5 |
| Component: | Groups | Version: | 1.2.8 |
| Severity: | 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)
comment:2
boonebgorges — 2 years ago
Could this be a duplicate of #880?
- 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?
comment:4
menelikseth — 2 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.
- 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.
comment:6
in reply to:
↑ 5
menelikseth — 2 years ago
Hey DJPaul,
Thanks for looking into this. I'll head over to the svn and download 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).