Ticket #569 (closed defect (bug): fixed)
Percent sign (%) in title leads to unusable permalinks
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | General | Version: | 2.1 |
| Severity: | major | Keywords: | bg|has-patch |
| Cc: |
Description
The percent sign (%) in entry titles is incorrectly put into the post slug, breaking the permalink for that entry.
Attachments
Change History
- Owner changed from anonymous to Kitten
- Status changed from new to assigned
- Status changed from assigned to closed
- Resolution changed from 10 to 20
This patch fixes this problem by removing '%' signs from the url completely. Tested, and will clean up old posts that have '%' signs in the title if they're opened for editing and re-saved.
- Status changed from closed to reopened
- Version set to 2.0.2
- Resolution fixed deleted
This is still the case in WordPress 2.0.2.
The problem isn't that the permalink contains '%', this can be allowed, but that the get_permalink function in template-functions-links.php doesn't urlencode $post->post_name, so an invalid url is generated.
comment:7
majelbstoat — 6 years ago
- Keywords bg|2nd-opinion added
Not sure this is useful as it stands. For me, all that this patch seems to do is to make Firefox's status bar less readable:
/path/to/permalink/これは何ですか。/
which is a readable Japanese permalink in the status bar becomes:
/path/to/permalink/2006/07/05/%e3%81%93%e3%82%8c%e3%81%af%e4%bd%95%e3%81%a7%e3%81%99%e3%81%8b%ef%bd%a1/
which isn't so useful. In IE there is no difference, as with or without this patch the URL is seemingly automatically encoded by the browser. Even without the patch applied, Firefox automatically encodes the link correctly. I haven't tried on other browsers, but I imagine that most (all?) modern ones will behave nicely. Besides which doesn't sanitize_title_with_dashes() already sort out the post-slug as it is created?
In any case, this patch doesn't fix the problem as the above permalink still gives a 404 for me on latest trunk even after it is applied. It looks like the permalink containing octets isn't matching the regular expression rules correctly, though I can't see why.
Jamie.
comment:8
majelbstoat — 5 years ago
- Keywords bg|2nd-opinion removed
- Version changed from 2.0.2 to 2.1
- Milestone set to 2.1
I believe I've found the problem. In parse_request() in classes.php, the path info is stripped from the end of the requested URI. However, the path is not URI encoded, so it fails to match in the str_replace. This patch urlencodes the path info (minus slashes) so it can be tested properly.
With the patch applied, all permalinks, including encoded ones, are followable.
majelbstoat — 5 years ago
-
attachment
569.diff
added
urlencode pathinfo before we try to match it in parse_request()
comment:9
majelbstoat — 5 years ago
On second thoughts, urlencoding everything in the path could break plugins that do rewrite rules checking. This new patch only encodes '%' to '%25', which still fixes the non-followable permalinks problem, without potentially causing problems elsewhere.
comment:10
ryan — 5 years ago
- Status changed from reopened to closed
- Resolution set to fixed
