Opened 17 years ago
Closed 16 years ago
#6867 closed defect (bug) (fixed)
single_tag_title() prints empty string on non-latin1 data
Reported by: | reinkim | Owned by: | ryan |
---|---|---|---|
Milestone: | 2.6.1 | Priority: | high |
Severity: | critical | Version: | 2.6 |
Component: | Template | Keywords: | |
Focuses: | Cc: |
Description
single_tag_title() in wp-includes/general-template.php returns tag_id 0 on non-latin tag value (like 한글).
So, the tag_id value is 0, it returns (or displays) empty string on the screen.
It breaks archive page in many themes -- including WP default theme.
Change History (15)
#3
@
17 years ago
- Milestone changed from 2.9 to 2.6.1
- Priority changed from normal to high
- Severity changed from normal to critical
Please check this bug immediately! There are above 1 million wordpress in east asia.
Japanese, Korean, Chinese are all headache about this bug.
#4
@
17 years ago
- Version set to 2.6
This bug only exist in 2.6.
All previous version behaves normal including 2.3 series and 2.5 series.
#7
@
17 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
I am a Chinese user.
Actually, this bug does exist in 2.6 and does not exist 2.3, 2.5 and 2.5.1. The bug behaves exactly like the reinkim said, but I do not confirm it will occur in Korean in 2.6.
Here are the details and example:
- When the tag slug is English and the tag name is Chinese. It behaves normally.
Example URL: http://fairyfish.net/tag/database/
- When the tag slug and the tag name are both Chinese. The single_tag_title() returns nothing.
Example URL: http://www.clearstudy.cn/archives/tag/%e8%87%aa%e5%ae%9a%e4%b9%89
(the tag is '自定义')
In condition 2, get_query_var() functions abnormal. When single_tag_title() calls it, get_query_var('tag_id') will return a 0.
I am not a PHP developer, I hope you can fix it. Thanks.
#8
follow-up:
↓ 9
@
17 years ago
- Resolution set to fixed
- Status changed from reopened to closed
I just did. :-)
#9
in reply to:
↑ 8
@
17 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Replying to ryan:
I just did. :-)
I am not joking, I am serious. As well, I confirm this is a new bug of 2.6 and it behaves exactly as reinkim reported.
I hope you can leave this ticket open if you were not sure to confirm. This bug referred to East asian language, I think there may be some difficulties for European developers to deal with.
The Chinese Wordpress community is discussing this bug. Maybe some Chinese PHP developers can find a solution and then upload the solution here.
Thanks.
#10
follow-up:
↓ 11
@
17 years ago
- Resolution set to fixed
- Status changed from reopened to closed
I just FIXED it. See [8364]. Don't reopen unless you test the fix and confirm that it does not work. You can test it by replacing your existing wp-includes/taxonomy.php with the version here:
http://trac.wordpress.org/export/8364/branches/2.6/wp-includes/taxonomy.php
#11
in reply to:
↑ 10
@
17 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
Replying to ryan:
I just FIXED it. See [8364]. Don't reopen unless you test the fix and confirm that it does not work. You can test it by replacing your existing wp-includes/taxonomy.php with the version here:
http://trac.wordpress.org/export/8364/branches/2.6/wp-includes/taxonomy.php
As you said, I have replaced the taxonomy.php of 2.6 by the older one as below. Now it works fine in Chinese.
if ( 0 == $term ) return 0; $where = 't.term_id = %d'; } else { if ( '' === $term = sanitize_title($term) ) return 0; $where = 't.slug = %s'; } if ( !empty($taxonomy) ) return $wpdb->get_row( $wpdb->prepare("SELECT tt.term_id, tt.term_taxonomy_id FROM $wpdb->terms AS t INNER JOIN $wpdb->term_taxonomy as tt ON tt.term_id = t.term_id WHERE $where AND tt.taxonomy = %s", $term, $taxonomy), ARRAY_A); return $wpdb->get_var( $wpdb->prepare("SELECT term_id FROM $wpdb->terms as t WHERE $where", $term) );
Besides, I have also test it in Korean (the bug reporter's language). It also has the same problem in 2.6.
It is a new bug of 2.6, maybe you can check the examples I provided above.
- When the tag slug is English and the tag name is Chinese. It behaves normally. Example URL: http://fairyfish.net/tag/database/
- When the tag slug and the tag name are both Chinese. The single_tag_title() returns nothing. Example URL: http://www.clearstudy.cn/archives/tag/%e8%87%aa%e5%ae%9a%e4%b9%89 (the tag is '自定义')
#12
@
17 years ago
I know it's a new bug in 2.6. This fix will be in 2.6.1. I have tested with all examples given on this ticket.
Are you saying that you tested with the new file and that it fixed the problem. If so this ticket should be resolved as fixed.
#13
@
17 years ago
The reporter reinkim is Korean. As I tested, this bug can not reproduced in 2.5.1 when the tag name and tag slug are both Korean. But with your new file (or fresh new 2.6 version), the bug can reproduced in Korean.
The Chinese language is the same. the tag title behaves normally in 2.5.1 and prints empty string in 2.6 version.
#15
@
16 years ago
- Resolution set to fixed
- Status changed from reopened to closed
smreg
I am korean.
I test it using fresh 2.6 installation and trunk, 2.6-branch-svn.
Korean Result
2.6 : Bug exist, not resolved
trunk : Bug not exist, resolved
2.6-branch-svn : Bug not exist, resolved
Chiness Result
2.6 : Bug exist, not resolved
trunk : Bug not exist, resolved
2.6-branch-svn : Bug not exist, resolved
Test suite
- tag-name is korean(or chiness) and tag-slug is english.
- tag-name is korean and tag-slug is korean(or chiness).
- tag-name is english and tag-slug is korean(or chiness).
All test is success when using 2.6-branch-svn.
If slug of tag is stored in latin1 and tag name is not in latin1, single_tag_title() returns correct (non-empty) tag value.
eg) tag-id : 10
Then, single_tag_title() function returns tag-name value correctly.