Please consider querystring support in 2.x

Please consider querystring support in 2.x - Printable Version

+- CodeIgniter Forums (https://forum.codeigniter.com)
+-- Forum: Archived Discussions (https://forum.codeigniter.com/forumdisplay.php?fid=20)
+--- Forum: Archived General Discussion (https://forum.codeigniter.com/forumdisplay.php?fid=21)
+--- Thread: Please consider querystring support in 2.x (/showthread.php?tid=31698)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Please consider querystring support in 2.x - El Forum - 08-02-2010

[eluser]Clooner[/eluser]
[quote author="amosmos" date="1280767548"]
I don't think you are fully reading the posts, which is OK because there are so many of them now and it can get a bit confusing.

1. CI doesn't work out of the box for me and I *have* to change the protocol to "REQUEST_URI". So the first step you are telling me to do I already do because I have to.

2. Now you say to add the "?=&" characters to the allowed characters. Well like I wrote before, I tried that but then if I do it this way CI thinks the entire thing is the controller (or method) name and don't understand it needs to ignore the "?" character and everything that follows it. That's why in this case I get a "404" error (and not the "The URI you submitted has disallowed characters" error).

So, like I said, I don't even get the page loaded at all.

WanWizard, hope I could hear your input on this...

Thanks[/quote]

Well since you changed your uri protocol to request_uri your segments are different yes. probably it can't find your controller now. Your segment array will look like something like this which is not like default.

Code:
Array

(

    [1] => path

    [2] => index.php

    [3] => welcome

    [4] => index

    [5] => ?par1=tada&par2=tada2

)

There are actually 2 easy fixes for it. (very basic examples). This fixes the routing problem.

Code:
$route['(:any)/index.php/(:any)/(:any)/(:any)'] = "$2/$3";

or

$route[':any'] = 'welcome';

Please consider querystring support in 2.x - El Forum - 08-02-2010

[eluser]amosmos[/eluser]
[quote author="clooner" date="1280768090"][quote author="amosmos" date="1280767548"]
I don't think you are fully reading the posts, which is OK because there are so many of them now and it can get a bit confusing.

1. CI doesn't work out of the box for me and I *have* to change the protocol to "REQUEST_URI". So the first step you are telling me to do I already do because I have to.

2. Now you say to add the "?=&" characters to the allowed characters. Well like I wrote before, I tried that but then if I do it this way CI thinks the entire thing is the controller (or method) name and don't understand it needs to ignore the "?" character and everything that follows it. That's why in this case I get a "404" error (and not the "The URI you submitted has disallowed characters" error).

So, like I said, I don't even get the page loaded at all.

WanWizard, hope I could hear your input on this...

Thanks[/quote]

Well since you changed your uri protocol to request_uri your segments are different yes. probably it can't find your controller now. Your segment array will look like something like this which is not like default.

Code:
Array

(

    [1] => path

    [2] => index.php

    [3] => welcome

    [4] => index

    [5] => ?par1=tada&par2=tada2

)

There are actually 2 easy fixes for it. (very basic examples). This fixes the routing problem.

Code:
$route['(:any)/index.php/(:any)/(:any)/(:any)'] = "$2/$3";

or

$route[':any'] = 'welcome';

[/quote]

That's not true - the first option won't work as there isn't a "/" between the last uri segment and the query string, and the second option will break the way the URI helper works.

I appreciate your trying to help, but my actual question is really to WanWizard who's solution really fixed the way CI handles uri's by separating the purpose of "enable_query_string" to 2 different config options, but he only did that in the AUTO protocol, which unfortunately I can't use. I wanted to know how he did that, and if my guess that he actually didn't do it but based it on the "AUTO" protocol original ignorance of the "?" character (after the first "if" block).

Thanks

Please consider querystring support in 2.x - El Forum - 08-02-2010

[eluser]Clooner[/eluser]
[quote author="amosmos" date="1280768591"]
That's not true - the first option won't work as there isn't a "/" between the last uri segment and the query string, and the second option will break the way the URI helper works.

I appreciate your trying to help, but my actual question is really to WanWizard who's solution really fixed the way CI handles uri's by separating the purpose of "enable_query_string" to 2 different config options, but he only did that in the AUTO protocol, which unfortunately I can't use. I wanted to know how he did that, and if my guess that he actually didn't do it but based it on the "AUTO" protocol original ignorance of the "?" character (after the first "if" block).

Thanks[/quote]

Ok have it your way! For the routing example it will work! As described it is only a basic example and you would want to replace that by a reasonable easy regex which takes care of your 'slash' example. Personally I would go for this simple solution which doesn't mess with the core.

Please consider querystring support in 2.x - El Forum - 08-02-2010

[eluser]WanWizard[/eluser]
I don't have a GoDaddy account, so I don't know what is so special about their environment that you have to hardcode REQUEST_URI as uri_protocol.
If you want you can PM me a var_dump of $_SERVER, to I can test it here.

All I can say that if I set my uri_protocol here to REQUEST_URI, and feed my application the URL "http://ci_testbed.catwoman.exite.local/en/homepage.html?foo=bar&bar=foo", It still routes to 'en/homepage', and I still have the keys 'foo' and 'bar' in the $_GET array. Which indicates that my fix is totally transparent to the uri_protocol used.

Which in itself is logical, the URI method _fetch_uri_string(), that uses the uri_protocol, does only that: getch the uri. It doesn't strip anything, or otherwise alter the url.

Which also means that a simple

Code:
class MY_Input extends CI_Input

{

    function _sanitize_globals()

    {

        $this->allow_get_array = TRUE;

        parent::_sanitize_globals();

    }

}

would do the trick just fine, without changing the core.

Please consider querystring support in 2.x - El Forum - 08-02-2010

[eluser]skunkbad[/eluser]
[quote author="WanWizard" date="1280779444"]I don't have a GoDaddy account...[/quote]

You should consider yourself blessed. :-)

Please consider querystring support in 2.x - El Forum - 08-03-2010

[eluser]pbreit[/eluser]
Clooner, can you summarize your complete solution again. Should it work for most hosting situations?

Ellis Labs, please, please, please add reliable querystring support by default.

Please consider querystring support in 2.x - El Forum - 08-04-2010

[eluser]Clooner[/eluser]
[quote author="pbreit" date="1280915779"]Clooner, can you summarize your complete solution again. Should it work for most hosting situations?

Ellis Labs, please, please, please add reliable querystring support by default.[/quote]

With this line you simply rebuild the $_GET variable on most hosting services.

Code:
parse_str($_SERVER['QUERY_STRING'],$_GET);

There is nothing more to it than that.

Please consider querystring support in 2.x - El Forum - 08-04-2010

[eluser]Clooner[/eluser]
[quote author="pbreit" date="1280915779"]Clooner, can you summarize your complete solution again. Should it work for most hosting situations?

Ellis Labs, please, please, please add reliable querystring support by default.[/quote]

You understand why EllisLab disabled the $_GET variable?

Please consider querystring support in 2.x - El Forum - 08-04-2010

[eluser]WanWizard[/eluser]
Disadvantage of that solution is that you parse the raw query string, including all nasty stuff inside it. Be sure to check and clean it before using it.

That's wy the extension of the Input class, and overloading _sanitize_globals(), is a better solution. It re-enables $_GET within the normal CI flow, so all checks, XSS cleaning, etc, will be done for you.

And no, I don't understand why it is disabled. It is perfectly fine to have it enabled, without it interfering with CI URI design or routing. Plenty of external services require query strings, so it's normal to expect this to work.

Please consider querystring support in 2.x - El Forum - 08-04-2010

[eluser]Clooner[/eluser]
[quote author="WanWizard" date="1280925602"]Disadvantage of that solution is that you parse the raw query string, including all nasty stuff inside it. Be sure to check and clean it before using it.

That's wy the extension of the Input class, and overloading _sanitize_globals(), is a better solution. It re-enables $_GET within the normal CI flow, so all checks, XSS cleaning, etc, will be done for you.

And no, I don't understand why it is disabled. It is perfectly fine to have it enabled, without it interfering with CI URI design or routing. Plenty of external services require query strings, so it's normal to expect this to work.[/quote]

So why not simply use?

Code:
$this->input->get('var1');