Can someone please clarify the position regarding support for $_GET within CI.

I recall somewhere seeing a statement from Rick Ellis that CI doesn’t support it and that any GET values passed to CI are simply destroyed. The reason for seeking clarification is that I’ve just seen the CI changelog for 1.5.4 and discovered some way down the page is an entry suggesting that $_GET had been supported at some point in the past.

I have a particular requirement for this at present because I’m developing an application that links to an external credit card processing services provider whose callback function only provides a response via GET. So I have to find a solution.

Having unsuccessfully tried all the CI options I could find, the only other option I had was to switch to using Kohana. I don’t want to open up a discussion here about the merits or otherwise of Kohana other than to say my strong preference is to stick with CI - provided that it has the tools I need to do the job.

I did come across a forum post from someone who had hacked the Input class to add support for GET. But a hack - however good it is and I’m not suggesting that it’s not a fine piece of coding - suffers from the fundamental problem that it’s not part of the official CI release. So there would always be a support issues and uncertainty every time a there’s a new release of CI.

For myself, the lack of support of GET is a major roadblock to using CI. If it’s not supported - or at least planned within a reasonable time frame then I think my only option would be to look for a completely different framework. I don’t want to do that if at all possible - I really like CI.

So the key question - I guess directed at Rick - will you add support for $_GET

Regards

David Bell

David, you can find CI’s available use of $_GET here.  In a nutshell, GET is available if you have query strings enabled.  It’s under consideration, but there are no plans at the present time to change this behavior.  You can, however, find a variety of workarounds here in the forums and wiki that users have implemented to allow GET on their installations, and you’re certainly free to modify the framework to behave however you like!

Whenever I need to get any type of data from the URL (eg email validation strings or even a message id as you see in every url of the forum) I just use routes?

Do you have no control of the callback url that will be passed back?

No - I’ve got no control whatsoever over the external site. I’m stuck with trying to access values stored in $_GET.  Just to make things harder they don’t even properly document the callback parameters.

Derek Jones - 13 July 2007 04:08 PM

In a nutshell, GET is available if you have query strings enabled.

Yes I looked at that. But if query strings are enabled then according to the documentation the URL helper and other unspecified helpers or parts thereof don’t work any more. That sounds like solving one problem and creating another - albeit more solvable one.

Derek Jones - 13 July 2007 04:08 PM

You can, however, find a variety of workarounds here in the forums and wiki that users have implemented to allow GET on their installations, and you’re certainly free to modify the framework to behave however you like!

The problem with the workarounds is they all seem to involve some sort of hack of the CI codebase. And that creates a significant and unacceptable ongoing support issue for the application I’m developing. Every update to CI would require the hack to be re-evaluated to see if it still functions correctly and that there are no security issues. To be honest - even if I had the time - my PHP skills aren’t up to the task of guaranteeing the security of a modified version of CI.

Regards

David Bell

Well, this may not be ideal, but another workable solution might be a small standalone script whose sole purpose is to receive and convert the GET data into a request that CI will handle in a more friendly out-of-the-box manner.

Derek Jones - 13 July 2007 08:35 PM

Well, this may not be ideal, but another workable solution might be a small standalone script whose sole purpose is to receive and convert the GET data into a request that CI will handle in a more friendly out-of-the-box manner.

Perhaps. What I would need such a script to do would be to validate the incoming data, assemble it into an array and pass the resulting array into CI for further processing.

It’s beginning to sound like I’m having to re-invent the wheel here! And then there’s the question of how I pass the array to CI.

I really don’t understand the reluctance to support $_GET properly. The problem I’m facing is a genuine real-world situation - the sort of thing that a framework should handle effortlessly. So why are you making programmers jump through hoops over this?

Regards

David

I wouldn’t say that it’s hoops; CI just requires you to make a choice: use segments or query strings.  The design of application is largely based around the clean URLs of the segment approach, hence that’s how the Helper’s were designed.  Building your own URLs isn’t too difficult of a task.  It’s noteworthy that the workarounds that some use do not require you to run query strings, and therefore, you can use the Helpers and other URL building functions with impunity.  Are you sure you’ve looked closely at them to see that they will not work for you?

I spent a couple of days trying to find a solution. Having completed most of the application apart from the one method to handle this one callback operation - it’s not entirely straightforward to switch to using query strings at this stage. Maybe I have missed something somewhere. But having spent that amount of time - when I came across Kohana it seemed like the only workable solution.

Would you be able to respond to my query about the reluctance to support $_GET in CI?

Regards

David

Would you be able to respond to my query about the reluctance to support $_GET in CI?

It can be fairly polarizing in the forums here, and there are plenty of existing topics to read through, so I’m going to decline to say anything other than it’s the way the framework is designed.  CI wants you to use URL segments and have clean, query string free URLs.  I understand if that’s not an answer that satisfies you, but I do encourage you to read through the many existing topics on the subject—the workarounds are not very severe nor hard to keep up with across updates.  If it’s a feature that’s very important to you and you want to use CI to build your application, you would either need to modify CI (which is one of the great things about open source frameworks) or be willing to work around it with an external solution.

I’ve already spent a considerable amount of time trawling through the forums trying to solve this problem - without success. I’ve already explained why mods to CI aren’t an option. Look at it this way. If you guys at Ellis Labs can ship CI with security vulnerabilities in as reported this week (I know you’ve fixed them in this weeks release but that’s beside the point) I would be very foolish to think that with my limited PHP coding ability I could guarantee not to introduce some other vulnerability - especially since the mods being proposed are dealing with user input!

I don’t have an issue with CIs use of URL segments - in fact it’s one of the things that led me to it start using it in the first place.

But there’s a real world out there which doesn’t share your perspective and insists on using $_GET. It makes no sense whatsoever to pretend it doesn’t exist. If you seriously want to expand the CI user base you’ve got to provide the tools that allow it to be used to deal with real world problems. Otherwise you’re just shooting yourself in the foot.

This is a serious issue. Please treat it as such and respond properly.

Regards

David

I think my response is both appropriate and fully considerate of your view on the matter, it’s just not what you want to hear, and I’m sorry.  The reality is that an answer that would satisfy you doesn’t exist.  Even if CI were planning to allow synchronous use of URL segments and query strings, I could not guarantee a date for you when it would be implemented, nor the method of implementation, so telling you what you want to hear would not be beneficial to you now for your current project.  We encourage people to make development decisions based on what’s available.  If that means deciding that CI is not the right tool for a particular project, that’s fine too.  CI doesn’t pretend that GET doesn’t exist, it simply asks you make a choice in your application as to whether or not your application will utilize it; and it’s pretty up front about that in the User Guide, allowing developers to make informed decisions before investing time in developing their application.

Hi David, welcome to CI - I’m sorry it has to be like this.  The only proper response we can give you is the honest one.  We’re not trying to fool you, at this point CI can’t do what you want it to.  Currently CI doesn’t use GET.  Its not that we haven’t considered it, and I’m not saying it will never support it, but at this point it doesn’t support it. 

The reasons are partially design choice, partially historical (legacy code from the way ExpressionEngine was designed).  As a workaround, without hacking the core, you could do as Derek J suggested above with a small standalone script that changes page.php?var1=val1&var2=var2 into either a post submission to a CI controller, or into a segment based url.

david_ais - 13 July 2007 02:24 PM

So the key question - I guess directed at Rick - will you add support for $_GET

Wouldn’t the approach suggested here work for you?

You rebuild the $_GET array within your controller.

I am have a similar requirement for a project I am working on at present.

I use one script that is excluded from the rewrite rule (tracking.php).

This takes a get string, cleans up the data, and then uses that to trigger something else.

I could probably tweak the code to take the GET string and convert it into a URL string that can be processed in the uri_to_assoc function in CI.

If you want to post the get string you want to process, so I can see what to expect, I’d be willing to have a crack at rewriting my function for you.

EDIT

Something like this perhaps:

I have recently added $_GET support to my CI project.

I wanted to do this in such a way as to avoid hacking the CI code. Its actually quite simple.

Firstly, set the config item for uri_protocol to use PATH_INFO:

This ensures that query string parts dont get treated like the rest of the CI uri structure (resulting in lots of 404 not founds).

Secondly, you need to extend the default Input library in order to stop it clearing the $_GET variable. Place the following file (called MY_Input.php) in your application/libraries/ folder:

This basically overrides the Input.php class to allow $_GET variables, but does not open up CI to query string URI routing (as it would if we simply set $config[‘enable_query_strings’] = TRUE).

Of course you will need to make sure that your config file specifies you subclass_prefix to be ‘MY_’, i.e.:

If its not, you can change the filename and classname of the above code accordingly!

That works for me anyway. Does it work for you?