Question

I tested this query in my database, and it works fine:

select * from variables where value = 'commas-:-)';

I get a result. Now, I stored the value in a variable and use the query class.

$value = 'commas-:-)' <<< this is passed as a parameter

$query = "select * from variables where value = '$value'";
$this->db->query($query);

Now, this query works for every other value except for this one – but what’s odd is that if I PRINT out the exact query (print_r of $query) and execute it on the database, it returns the correct result. So I’m left to think that the query class is screwing with my query, which it shouldn’t because everything is properly escaped and $value is a string literal.

What is going on?

Answer 1

I found the issue – it was the rerouting function that was causing the mishap. More specifically, the segment filtering function within the route folder in the system core.

This is what happened:

I created an anchor with the encoded value (commas:-)) and I configured the route to reroute the uri to a function I had in my controller. Each time I clicked the link, the value gets passed, and (supposedly) rerouted to the function. Which it did, for almost all the values I used. Except this one.

1st assumption: the db query function is escaping the values. But I turned off the escape, as well as checked the query by printing. The value was correct. I then tried other query formats, and still no results. Conclusion: There’s nothing wrong with the database query functions.

2nd assumption: the data must be corrupt – although the value is correct (I’m getting commas:-)), it’s not returning anything except when I type in the value manually. So I tested this:
I created a seperate value, and set it equals to the one I typed in(the one that works). I then printed the original value(one passed) and the newly created value using VAR_DUMP.
Turns out, the argument value (one that doesn’t work) is a string with length 14 whereas my new variable was a string with a length of 10. WTF? Conclusion: Something occured during the rerouting / passing process that changed the variable.

I went back to the config folder, and replace the variable $i in the reroute to the literal string value commas:-). And guess what? It worked perfectly. And just to make sure it wasn’t the regex, I wrote my own custom regex and it matched fine, but the value was still being changed. So I decided to get under the hood.

I traced the URI manipulation in the routes class to the _explode_segment() function, which was used to perform the regex and analyse the uri for other variables. It also did this thing …

_filter_uri($str)

for each part of the uri segment that was matched.

What did it do? It replaces programmable characters like ( and ) with their HTML ENTITY. Now, if you don’t know, html entities have long lengths than url encoding. LOL. So what happened was this:

Original segment : commas-%3A-%29 <- very nice!
Filtered segment : commas-%3A-) <- NOOOOOOOOO! (the right paren encoded with &#41.)

urldecode(“&#41”) = string(4)
urldecode(“%29”) = string(1)

Fail.

or WIN?!