tags:

views:

245

answers:

7

Hi , how check if $_GET is empty ?

+2  A: 
<?php
if (!isset($_GET) || empty($_GET))
{
    // do stuff here
}
john010117
`!isset($_GET)` is not necessary here, `if (empty($_GET))` would be enough
Alexander Konstantinov
Oops, my bad...
john010117
Just FYI: $_GET _can_ be unset, it is however very rare to configure PHP that way (see `variables_order`)
Wrikken
@Wrikken: I think Alexander wasn't addressing this issue. `empty` simple checks itself that the variable is set, so checking with `isset` is redundant.
nikic
Ah, yes, forgot `empty` was a language construct indeed.
Wrikken
+2  A: 

i guess the simplest way which doesn't require any operators is

if($_GET){
//do something if $_GET is set 
} 
if(!$_GET){
//do something if $_GET is NOT set 
} 
sherilyn
-1 given that it could throw a notice error. Using empty to test is a better alternative.
Brad F Jacobs
+1 given for there is no need to use empty(). @premiso got any real-life example to prove why it's better?
Col. Shrapnel
Col, no I actually do not. But I could ask the same of you why yours is "better" and if you can provide me with real-life examples of why your solution is better, the real answer is both are valid (after my vague tests). So yea, I was in the wrong for the downvote and if the user modifies this I will switch it. What it comes down to is preference, I prefer to use the empty. The only reason I can give on this is that empty checks if an item is empty. Given that $_GET not being set returns array(0) from a var_dump, empty seems to be a better choice to use, in my opinion.
Brad F Jacobs
A: 
if (!$_GET) echo "empty";

why do you need such a checking?

lol
you guys too direct-minded.
don't take as offense but sometimes not-minded at all
$_GET is very special variable, not like others.
it is supposed to be always set. no need to treat it as other variables. when $_GET is not set and it's expected - it is emergency case and that's what "Undefined variable" notice invented for

Col. Shrapnel
OMG! OMG! You must use isset()!! Else it's not secure!!!!!1!
mario
@mario got any example to demonstrate?
Col. Shrapnel
There is a ini setting called `variables_order` which allows you to set which variables to set and which not to set. Furthermore the programmer may want to unset `$_GET` - for whatever reason.
nikic
If you know say - "Who'd want to unset $_GET? wtf? That's mental!" probably you are right, this situation is *very* improbable. Maybe you want to do this for some kind of sandboxing or similar. So why not be prepared for even an unlikely case? Furthermore `empty($_GET)` is more verbose. It says what you think ;) I would give you +1 because you do bring up some valid arguments, but I don't like the tone you're arguing with, so I will not.
nikic
@nikic well with notice you will be informed of that terrible sabotage act! What can be better? That is what error messages for - to tell you of such malicious programmers! I have told you it three times! Users will bullet you with complaint's, you come to check logs - voila! there is a problem - $_GET is not set!
Col. Shrapnel
@CS: been joking
mario
Now, I need to disagree. Replacing or even unsetting a superglobal isn't a bad thing per se - that's just like saying that eval was evil. Sure, many people misuse it to do evil stuff, but it isn't evil for itself. And so is unsetting $_GET not bad by itself.
nikic
Off topic, I nowadays use object-style wrappers around $_GET, $_REQUEST and $_POST (which **enforce** input filtering). But that's a ultra specific case, where the _NOTICE-minded empty() folks would also fail.
mario
@niki ok. ok. in general may be. in theory. but for your application that IS using $_GET it's disaster.
Col. Shrapnel
@mario: And `!` wouldn't fail there? @col: So, now we agree, do we? Yes, it is mostly theoretic. But as I do many things with PHP itself, i.e. somehow theoretically, theoretic is not equivalent to impossible for me. Some months ago I could have asked you "Who the hack needs Tokenizer?" but now it is one of the features I do use very much.
nikic
@niki I am not talking of your experience. I m talking of this very example from this very question. And I insist that there is no sensible scenario where you would need to use empty or isset.
Col. Shrapnel
Yes, you are right. Given this very trivial question everybody knowing even smallest PHP is able to answer, it seems stupid thinking about _get not being set. So, in this point you convinced me. But I will still stick to `empty($_GET)` being more verbose. And +1.
nikic
+1  A: 

I would use the following if statement because it is easier to read (and modify in the future)


if(!isset($_GET) || !is_array($_GET) || count($_GET)==0) {
   // empty, let's make sure it's an empty array for further reference
   $_GET=array();
   // or unset it 
   // or set it to null
   // etc...
}
vlad b.
`if (!empty($_GET)) { }` is even easier to read. `empty()` returns `TRUE` if an array doesn't contain items.
kiamlaluno
what if $_GET is a string ? or an object? I've stumbled across scripts that messed up $_GET and i usually check if the variable is the type i "know" it should be...
vlad b.
that's easy. just avoid such scripts :) Honestly, your code is overkill
Col. Shrapnel
I guess you never had to integrate a few php scripts/systems without modifying them but trying to stop them from wreaking havoc when they are used in the same cron job or web page.It might be overkill but i sleep well at night. I usually sanitize, validate and check all variables before i use them if they can be modified by anybody else (via url, ini_set, or anything else). And i log ANY unexpected input (like $_GET not being an array) with all the possible info so i can recreate it at a later date to fix any bugs or special cases...
vlad b.
Might be of interest...http://stackoverflow.com/questions/3388983/php-safe-get-or-not/3389519#3389519
vlad b.
Have separate PHP file for every get variable? man you are True Real Programmer. I am amazed.
Col. Shrapnel
1. It's not that many files 'id' will always be numeric in most projects, 'username' will be a string, etc... <br><br>if these are run before plugins, you could do $_POST['password']=hashing_function($_POST['password']) so no user can actually get the raw <br>2. i use classes more than files but for a small example a file should be enough<br>3. i don't have to write is_string(), is_empty(), is_numeric() etc every time, i usually have a singleton if($get->password->is_set()->is_correct()) { ... } else { ... }
vlad b.
+10  A: 

You said it yourself, check that it's empty:

if (empty($_GET)) {
    // no data passed by get
}

See, PHP is so straightforward. You may simply write, what you think ;)

This method is quite secure. !$_GET could give you an undefined variable E_NOTICE if $_GET was unset (not probable, but possible).

nikic
good point. a bit late but still good :)
Col. Shrapnel
To get a notice is always good. isn't it?
Col. Shrapnel
no, your code should not generate any notice-level errors.
Frank Farmer
@Frank It is true... when everything is going well. But isn't a notice is what do you expect if $_GET happen to be not set? Isn't it the only purpose of such a notice?
Col. Shrapnel
No, you never want to have your code throw you a notice. Source code throwing errors of any type is always considered bad.
nikic
well what's the purpose of all these errors then? any suggestions?
Col. Shrapnel
To tell you, that you made a mistake whilst coding. If I get a parse error, I can correct the mistake. If I get a undefined var / index notice, I can correct it. That's the purpose. But production code oughtn't throw errors. (And if it does they ought be suppressed and logged.)
nikic
quite good explanation. well, suppose we've got our notice whilst coding. is it good or bad? Please make your mind at last ;)
Col. Shrapnel
Yes, getting a notice is always bad, because it tells you that you did something wrong.
nikic
But it helps you to repair what you did wrong - isn't it? How else will you know? Isn't it good to know what is the problem?
Col. Shrapnel
Notice errors are good in the sense that they tell you where an error is. But they should be fixed and handled properly. An unhandled error is just laziness, imo. So doing a proper check with the empty, which avoids the notice error and allows you to properly handle the data is the better way to go, as if it is empty and you are expecting it to be populated, well yea you can now handle that with a user error message etc.
Brad F Jacobs
@premiso like many others here you are talking right words. right in general. but they are not applicable in this very case. There will be no difference in error handling whenever will you use empty() or not. You all were good pupils and learned your lesson well. But now you need not to recite it mindless but to think a bit. To apply your knowledge to the very particular case. There is not a single reason to use empty() here
Col. Shrapnel
Error handling and error reporting are two different things, and they do not interfere. Error reporting should be as high level as possible. Every error message is your friend. Handle error as you wish but do not gag the message
Col. Shrapnel
Now, I don't get this. Are you telling me, that it is better to have an application that bullets you with errors or one that runs smooth and doesn't complain?
nikic
It's better to have application that runs smooth, BUT bullets you with errors **if something goes wrong**. You still cannot distinguish these 2 states - normal and emergency ones. Error messages for the latter one.
Col. Shrapnel
Okay. I think I perfectly agree with you. Simply we have different opinions of what "goes wrong" means. An unset $_GET variable is "wrong" in your eyes but perfectly normal in mine. So, let's stop this pointless argument, shall we?
nikic
it is wrong not for darn me. it's wrong for darn application what expect that darn array as it seems from darn code we are discussing here
Col. Shrapnel
`it is better to have an application that bullets you with errors or one that runs smooth?` as a matter of fact, your application will not run smooth if there will be no $_GET array when it's expected. and your `$_GET=array();` would not make it work. So it can only fail smooth. That's what I am am talking about. Your approach is good for any other variable. But for $_GET it's useless. That's first thing for you to understand.
Col. Shrapnel
And second thing for you to understand: there is noting bad in the error message. There can be always emergency cases and you cannot handle em all. unsupported function for example. missing extension. you cannot test every function before calling - it's overkill! And useless. ou have to just get in touch with error message and take appropriate action. You just mixing up `application flow errors` which should be properly handled, and system errors, which you cannot handle all and have to just log/display it.
Col. Shrapnel
Can't i do `$_GET = array()`? That is very odd, indeed. @Second thing: You know, I'm not stupid. We simply have different opinions whether $_GET not set is an error or intentional! But if you really cannot write to `$_GET` as you say and may not `unset($_GET)` than I'm sorry, I didn't know.
nikic
+2  A: 

Easy.

if (empty($_GET)) {
    // $_GET is empty
}
Martin Bean
+3  A: 

Just to provide some variation here: You could check for

if ($_SERVER["QUERY_STRING"] == null)

it is completely identical to testing $_GET.

Pekka
+1 I thought of the same thing but wasn't sure against what you need to check. Against `!isset`, `null` or `''`. Does `null` work here, have you tested?
nikic
@nikic yup, tested and works. Because it comes from Apache, it will always be set - even if it's empty - so no `array_key_exists()` check is necessary.
Pekka
anything will work, niki
Col. Shrapnel