Isset confusion

I have a database field with a string (like photo.jpg) and im trying to make it so that if that field is blank, a different image will display.


            if(isset($row['photo1'])) {
            $image = "<img src=\\"/masterasp/providers/images/".$row['id']."/".$row['photo1']."\\" border=\\"0\\">";
            } else {
            $image = "<img src=\\"/masterasp/providers/images/default.jpg\\" border=\\"0\\">";
            }

for some reason, this evaluates to true even if I delete the content in that field.

How do fix this?

You want to use ![fphp]empty/fphp instead. [fphp]isset/fphp means the variable is defined, it will return true for empty, strings, ints, etc. [fphp]empty/fphp on the other hand, validates whether the provided variable is empty, null, etc.

When faced with a conditional fork, and things do not happen as you expect, you should var_dump the variable to see what VALUE it has and WHAT TYPE it is.


var_dump($row['photo']);

eg if it is an empty string ‘’ of 0 length, then that is what you should be checking for, get into the habid of using triple === to check for matches on type AND content.


if( $row['photo'] === '') {
// then do something
}

Get used to thinking like this “When faced with a conditional fork, …” whenever you are testing a variable otherwise you are destined to be posting such examples on forums like this for ever.

Take a look at this PHP truth table, now do you see how many ways there are to interpret and empty string?

When you know this table by heart, then you can afford to relax and start using if($x) if(isset()) etc.

ps At some point another question you might want to investigate the answer to is, why have I got an empty string in my database at all, should it be a NULL?

I endeavour to validate all content before processing but a programmer friend of mine told me how allegedly Apple program. Apparently they always assume that the data is correct and maybe test for success. If and only if there is an error/exception then relevant error checking code is activated. I can appreciate the logic since extensive tests on the off-chance that the data is not valid must slow down processing. Upon reflection I think I will raise this point in a new PHP thread :slight_smile:

I would be tempted to test and ensure an image exists rather than if the row is set:



# set a default image in your constants.php
 define('imgDEFAULT', "/masterasp/providers/images/default.jpg");

  $img2Display  = ingDEFAULT;
  $img2Validate = "/masterasp/providers/images/".$row['id']."/".$row['photo1']; 
  if( file_exists( $img2Validate ))
  {
    $img2Display = $img2Validate;
  }
  $image = '<img src="' .$img2Display .'" class="imgBdr0" />';


Special note: Code written but not validated :slight_smile:

Be careful, file_exists can be extremely expensive if you need to do this hundreds or thousands of times. I’m not 100% sure where, but I read a thread/article a while back where the person stopped using file_exists because it was cheaper to support 404s through htaccess redirection (showing a default image) than performing file_exists checks. Food for thought.

I was just trying to suggest to the OP a strategy for dealing with simple errors like this by using var_dump() because they’ll find var_dump() much faster than waiting for answers on forums.

Proving whether things match expectations may have to be learned the hard way and while var_dump() maybe its simplest incarnation, but if you get your brain into this “prove it!” mode you should eventually end up using the equivalents of XDebug, [URL=“http://seleniumhq.org/”]Solenium and proper [google]PHP UnitTests[/google] and so on … 'though not everyone gets there, or indeed needs to.

If Apple or anyone else code with the presumption that all values will be as expected, then I’d guess it is probably because those values are verified with banks of tests somewhere else.