Undefined Index

[Geates]

I just got PHP 5 working with IIS7. I'm getting an "Undefined Index" error when the script references $_GET['dir']. Obviously, the error indicates that the index 'dir' is undefined in the GET verb. Defining the index resolves the problem - I have never had to do this in the past. It seems apparent to me that I've overlooked a PHP/IIS7 configuartion setting for strictness. Any idea?

-Geates

 

[jpadie]

it will be in the error reporting settings. for production platforms you may want to reduce error reporting to E_ALL ^ E_NOTICE or leave at E_ALL and turn OFF display_errors. all settings can be adjusted in php.ini. these two settings can equally be adjusted programmatically.

 

[ingresman]

So, if you don't pass in a item called dir (either in the query string or on a form with a get method) and your script used to work, what did it do ??? - sounds like a bug to me (unless I've mis understood your point).
In general it's probabby worthwhile checking to see if dir exists before you try to use it to handle such errors gracefully.

 

[vacunita]

I agree with ingresman here. If its not defined its probably because its not getting passed by either of the 2 methods stated by ingresman.

How are you expecting to get the dir index in the GET superglobal?






----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[Geates]

This is what I'm getting...

PHP Notice: Undefined index: dir in G:\Development\Websites\index.php on line 22.

<?php

$strDir = "g:\\development\\websites";

if (!empty($_GET['dir']))
	$strDir .= $_GET['dir'];
//else
	//$_GET['dir'] = $strDir;
	
$arrFolders = scandir($strDir);
foreach($arrFolders as $strFolder)
	if (is_dir($strDir."/".$strFolder))
	{
		$arrFolderContents = scandir($strDir."/".$strFolder);
		if (in_array("index.php", $arrFolderContents))
			print "<a href=\"/$strFolder/index.php\">$strFolder</a><br>";
		else
			print "<a href=\"index.php?dir=".$_GET['dir']."\\$strFolder\">$strFolder</a><br>";	
	}
?>

  Uncommenting the $_GET['dir'] definition on line 8 resolves the error.  I never had to declare indexes in previous PHP/IIS configuartions.

-Geates

 

[vacunita]

Well of course, because what happens when it is empty?

What your code says is:

If its not empty, assign its value to $strDir.

But does absolutely nothing when it is empty. It just happily moves on and even tries to sue it even though it may be empty.

but brings up another point, why do you need GET['dir'] if you just set it to a hard coded value anyway.





----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[Geates]

The script lists the contents of the directory. If 'index.php' exists within that directory, a link is created to dir/index.php. Otherwise, a link is created to the dir. Both links point back to this script. $_GET['dir'] comes into play when a child directory is passed within the URL (index.php?dir=images). Initially, the index is unused. Subsequent iterations contain valid indecies.

It's not a big deal to initially define it - in fact, that's a better coding practice. I just want to know what PHP setting is responsable for this "strictness" which I have never encountered.

-Geates

 

[vacunita]

Its not strictness, its logic, and standard variable handling.

If the variable is not defined it can't be used.

It happens when nothing is passed to it in the url string.

Your code is flawed in that even though it checks the variable for contents, it does nothing at all if there is no content, that is if its empty, or if its not actually set.
Why because if the variable is empty or not set, your code just moves on to the code regardless, and attempts to use it anyway.







----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[jpadie]

but php allows implicit variable declaration, which is why many big ole programs (wordpress included) assume that E_NOTICE errors are suppressed and use late declarations.

from memory php also recommends suppressing E_NOTICE for production platforms.

 

[vacunita]

Its still a poor coding practice to not check whether a variable is available or not before attempting to use it.

And while I agree a production server should be set not to display minor warnings and notices I still think variable checking should always be done.




----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[Geates]

Its still a poor coding practice to not check whether a variable is available or not before attempting to use it.

My coding practices are completely irrelevant and aren't condusive to answering my question.

Why would this error appear after several years of flawless operation running on various PHP/IIS configurations?

-Geates

 

[vacunita]

jpadie answered that already: the settings for error_display and error_reporting.

If it worked before it was likely due to those settings being setup differently.




----------------------------------
Phil AKA Vacunita
----------------------------------
Ignorance is not necessarily Bliss, case in point:
Unknown has caused an Unknown Error on Unknown and must be shutdown to prevent damage to Unknown.

 

[ingresman]

I suspect the OP might not be a php wiz, so if I can just explian 3 things.
When you call a web page from a browser you might type something like

[URL unfurl="true"]www.fred.php?name=john&dir=files[/URL]

In this case the supergloval $_GET will have an variable init called dir (the index) with a value of files and all would be well.
If you typed:

[URL unfurl="true"]www.fred.php?name=john[/URL]

you would no longer have a value called dir in $_GET as it didn't get typed.
Or you might have a hyperlink in the code such as

<a href=showfile.php?dir=file>click me !>

Follows the same rules above
Finaly

<form = doit.php action=GET>
<input type=hidden name=dir value=fred>
</form>

Would also have the same effect.
So this is how variables get put into php scrits. As you can see it is possible to not supply it in which case your code should handle it.

 

[Geates]

I am familiar with PHP, although, my strengths are in VBS, basic, C++, etc. I do understand how POST and GET are handled. What I don't get is why is my script barking at me now. I was written many years ago and never once barked before.

Also, I have error set to E_ALL & ~ E_NOTICE, yet problems persist. A user on another forum thought the issue may be related to OS architecture (64-bit vs. 32-bit). Currenlty, I run Win7x64. I can see this being a potential problem for a 32-bit engine to perform memory allocation.

-Geates

 

[jpadie]

if php is throwing a notice when you have told it not to then either

1. you have not told it not to do so or
2. your installation is fubar.

occam's razor suggests the former. windows supports multiple locations for php.ini. i recommend that you call phpinfo() to determine which php.ini is being used and also what error reporting settings are being reported. perhaps a recent windows upgrade changed or mangled the environmental variable responsible for telling php where to look for its ini file.or perhaps you have recently started using an IDE with a built in php executable which uses an alternative php.ini.

the relevant info in phpinfo is both in Configuration File (php.ini) path AND sometimes in Loaded Configuration File. plus look for 'additional .ini files parsed'

 

[DonQuichote]

I am familiar with PHP, although, my strengths are in VBS, basic, C++, etc. I do understand how POST and GET are handled. What I don't get is why is my script barking at me now.

Apparently not. PHP used to be insanely forgiving, but that does not mean that referring to something that does not exist is not an error. For production systems, you can still hide all warnings, errors and notices, to keep this useful information from people hacking your site. It does not mean it is OK to do so.

Thank goodness PHP no longer tries to outsmart developers by unwantedly injecting quotes into input and hiding errors. So now, by default, you will see your errors. So the reason PHP did not bark before, was that PHP by default put its fingers in its ears and sang "lalala, no problem!", what ever happened.

And now it is finally telling you what you did wrong. Again, thank goodness. Now you can learn from the messages and see what unexpected things happen. Do not cover up the errors, learn from them. Correct them. Check your input before you use it.

Let me repeat that:
Check your input before you use it.

Because that is the basis of security for any web site that handles input. Really. It wish it would be otherwise, but the web has lost its innocence. Automated programs are scanning the web for any vulnerable site to do some harm. Your site also.

+++ Despite being wrong in every important aspect, that is a very good analogy +++
Hex (in Darwin's Watch)

 

[jpadie]

oh ... and don't forget that with SAPI installations you must restart IIS for .ini changes to take effect.

 

[Geates]

Yes, jpadie. I tend to restart IIS after any modification. Perhaps you're right about the environmental variable incorrectly stating the php.ini path. I will check.

-Geates

 

[Geates]

This issue's root cause is system architecture. It was suggested that my Application Pool in IIS was configured to run in x64. I changed the advanced properties of my Application Pool so "Enable32bitAppOnWin64" = "true". A few other mild configurations and my localhost began to run as expected. Thanks mrdenny for pointing out system architecture limitations.

This begs the question. Is PHP x64 stable enough for web development? Are there any client system platform compatability concerns?

-Geates

 

[IPGuru]

I am sorry but I have to agrre with most of the other posters the root cause of your problem is poor coding.

Your "fix" is to hide the problem, yes it may work but that does not make it correct.

if you need to set a default vaule if $_GET['dir'] is not set i would suggest the following single line of code instea of your if - else construct

$setdir=(isset($_GET['dir']))?$_GET['dir']:'<default>';

<default> of course needs to be replaced with whatever you need as the default value.