Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

This is happening in more than one section of our website, but in different yet similar ways.

Scenario One:

We have a URL structure like this...

mydomain.com/some-category/?subject=Some+Subject

I'm trying to get pagination properly working. I urlencode() the space and get the +, but it doesn't matter if I use a space or a + ...Wordpress always tries to do this...

mydomain.com/some-category/page/2/?subject=SomeSubject

...instead of this...

mydomain.com/some-category/page/2/?subject=Some+Subject

WordPress is removing the space/+ for some reason. We haven't figured out why just yet. Any help is greatly appreciated.

Scenario Two:

I have predefined slugs that are identical matches to our part codes in our e-commerce system. We have custom-built plugins that associate pages to the e-commerce system by way of the slug matching the part code in our system. In turn, it generates nicely formatted (and automatic) ordering tables for checkout.

Wordpress is removing any "+" that I include in the slug, which may have been part of our part codes. Is there any way to get Wordpress to quit screwing around with our URLs and let us do what we want to? We prefer to think for ourselves, rather than have Wordpress tell us how to think.

share|improve this question

2 Answers 2

up vote 0 down vote accepted

You can hook into WordPress’ slug algorithm and create your own slugs. For an example look into my plugin Germanix URL. I’m not sure if WordPress can accept requests with an + without further tweaking tough.

If just want to allow the slug without much coding, install Germanix and create a second plugin with this code:

<?php # -*- coding: utf-8 -*-
/*
Plugin Name: Germanix plus +
*/

add_filter( 'germanix_translit_list', 'remove_plus_from_transliteration', 10, 1);
add_filter( 'germanix_lower_ascii_regex', 'allow_plus_on_regex', 10, 1);

function remove_plus_from_transliteration( $utf8 )
{
    unset ( $utf8['+'] );
    return $utf8;
}
function allow_plus_on_regex( $regex )
{
    # $regex['pattern'] => '~([^a-z\d_+.-])~';  // was this
    $regex['pattern'] = '~([^a-z\d_+.-])~';  // now this
    return $regex;
}

remove_filter( 'editable_slug', 'urldecode' );

I haven’t tested this now but it should work. :)

share|improve this answer
    
I agree that sanitize_title() is likely the solution, but I have no idea how to roll a function to let plus signs actually exist. That's a bit tricky and any help would be greatly appreciated. Asking product execs higher up the company food chain to change their part code naming mechanism after codes have already existed for some time seems highly unlikely to turn into a productive result in the end. –  Will Ashworth May 23 '11 at 18:19
    
@Will Ashworth I have added some sample code that should guide in the right direction. –  toscho May 23 '11 at 18:31
    
Okay, I'll give that a try. Does the plugin mess with already-existing slugs for the thousands of pages we've created over the past 9 months for this website? I'd hate to install it and find out it messed with URLs we already had in place. Otherwise, I'm good to go :) –  Will Ashworth May 23 '11 at 18:35
    
So we're making some progress here with your plugin....kinda. I go in to edit the slug for one of the pages in question and it doesn't completely strip it out. Instead, it's turning that plus into a space. The end goal is to have the plus sign (+) actually be part of the slug and not be taken away...ever. –  Will Ashworth May 23 '11 at 18:57
    
The conversion happens in urldecode, a default filter. I removed this filter too in the plugin code. Now it is getting somewhat risky. As long as you enter just ASCII characters in the slug field, nothing bad should happen. Oh, and existing slugs aren’t touched. –  toscho May 23 '11 at 20:14

Looks like they're fixing it in 3.3: http://core.trac.wordpress.org/ticket/18086

What they did to fix it was in /wp-includes/canonical.php, add:

$_parsed_query = array_map( 'urlencode', $_parsed_query ); 

...above this line:

$redirect_url = add_query_arg( $_parsed_query, $redirect_url );

So, yes, you're modifying core, but it's only one line and you know the change is going to stay there when you update to 3.3.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.