Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#25113 new defect (bug)

non-latin CPT rewrite slugs fail `wp_safe_redirect`

Reported by: entr's profile entr Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.6
Component: Posts, Post Types Keywords: needs-patch
Focuses: Cc:


If you localize your custom post type rewrite slugs in non-latin language and pass it to wp_safe_redirect it will strip all non-latin characters and attempt to redirect to stripped location.

This can be easely reproduced if your custom post type supports comments and you submit a comment from post type single page as wp_safe_redirect is called after comment submission.

Change History (4)

#1 @SergeyBiryukov
11 years ago

  • Keywords reporter-feedback added

Related: #10690

wp_safe_redirect() passes the URL through wp_sanitize_redirect(). Could you give an example of an affected URL?

#2 @entr
11 years ago

  • Keywords reporter-feedback removed

Yes, with a rewrite set as:

'rewrite' => array( 'slug' => 'продукт', 'with_front' => false ), //BG localization for `product` (cyrillic)

wp_sanitize_redirect returns
instead ofпродукт/post_name
which in my case causes infinite loop

#3 @nofearinc
11 years ago

I've tested a modified version of this snippet which works fine for resolving (and not breaking a list of test domains):

	$url1 = 'продукт/post_name';
	$url2 = '';
	$url3 = '';
	$url4 = '';
	$url5 = '';
	$url6 = '';
	$url7 = '';
	$url8 = '';

However, @nacin said that it's not compatible with the WordPress license, and the original PHP function is supported by PHP 5.3+ only.

I saw that Ryan was working on some IDNA encoder and there are probably other license-compatible solutions, but I'm not sure how much of an overhead would it be to add a 200-400 LoC class for this use case. Thoughts?

Still there are few more related tickets to that problem, but can't decide how urgent or widespread that is.

Note: See TracTickets for help on using tickets.