#46201 [Bgs]: Bug #44625 is NOT bogus!
ID: 46201 User updated by: jrhernandez05 at gmail dot com Reported By: jrhernandez05 at gmail dot com Status: Bogus Bug Type: Apache2 related Operating System: Windows Vista Home Premium PHP Version: 5.2.6 New Comment: This is indeed a bug, or at the very least a documentation error. According to http://www.php.net/manual/en/configuration.php, the first place that PHP will look for the INI file is based on the PHPIniDir directive, if specified. In this case it was specified and I set it to C:\Windows, and PHP did display this path in the "Loaded Configuration File" section, yet C:\php\php.ini was the one actually being parsed. Also, I do not have any of those registry settings set. Previous Comments: [2008-09-30 10:13:06] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Due to the volume of reports we can not explain in detail here why your report is not a bug. The support channels will be able to provide an explanation for you. Thank you for your interest in PHP. You don't need to set PHPIniDir, there are a few places that are tried by default. Directory of binary HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath registry value c:\Windows You found the issue and its not a bug. [2008-09-30 02:41:17] jrhernandez05 at gmail dot com Description: This is a duplicate of bug #44625, since I cannot add comments to "bogus" bugs and cannot change the bug status. I was able to confirm this bug. I set PHPIniDir correctly inside httpd.conf to C:\Windows, and the Loaded Configuration File in phpinfo() returned "C:\Windows\php.ini", yet my include_path still had an old value. After many different attempts, I found out that if there is a php.ini inside the directory where the php executable is, that file will be read instead of what's specified in PHPIniDir. My workaround was to remove the php.ini from C:\Windows and set PHPIniDir to the php.ini inside the php executable directory. P.S. This is NOT bogus, it's a real bug in Windows Vista (I am a ZCE, so this is not a "n00b" error). -- Edit this bug report at http://bugs.php.net/?id=46201&edit=1
#46201 [NEW]: Bug #44625 is NOT bogus!
From: jrhernandez05 at gmail dot com Operating system: Windows Vista Home Premium PHP version: 5.2.6 PHP Bug Type: Apache2 related Bug description: Bug #44625 is NOT bogus! Description: This is a duplicate of bug #44625, since I cannot add comments to "bogus" bugs and cannot change the bug status. I was able to confirm this bug. I set PHPIniDir correctly inside httpd.conf to C:\Windows, and the Loaded Configuration File in phpinfo() returned "C:\Windows\php.ini", yet my include_path still had an old value. After many different attempts, I found out that if there is a php.ini inside the directory where the php executable is, that file will be read instead of what's specified in PHPIniDir. My workaround was to remove the php.ini from C:\Windows and set PHPIniDir to the php.ini inside the php executable directory. P.S. This is NOT bogus, it's a real bug in Windows Vista (I am a ZCE, so this is not a "n00b" error). -- Edit bug report at http://bugs.php.net/?id=46201&edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46201&r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46201&r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46201&r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46201&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46201&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46201&r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46201&r=needscript Try newer version:http://bugs.php.net/fix.php?id=46201&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46201&r=support Expected behavior:http://bugs.php.net/fix.php?id=46201&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46201&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46201&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46201&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46201&r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46201&r=dst IIS Stability:http://bugs.php.net/fix.php?id=46201&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46201&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46201&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46201&r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46201&r=mysqlcfg
#29378 [Com]: foreach() doesn't work with arrays returned by __get
ID: 29378 Comment by: jrhernandez05 at gmail dot com Reported By: chernyshevsky at hotmail dot com Status: No Feedback Bug Type: Zend Engine 2 problem Operating System: Windows 2000 PHP Version: 5.0.0 New Comment: I have tried the original reproduce code using the latest PHP snapshot, and have also tried it using some similar code I'm using in my application, and it's working fine now! My environment is Windows 2000 using Apache2. Previous Comments: [2005-03-14 01:00:20] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open". [2005-03-06 20:52:40] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-02-11 15:42:50] l0cky at jolt dot co dot uk The simplest solution I have is //Copy works foreach($array = $object->array as $element) { print($element); } However, if you want to access the array elements by reference instead of copy, then you're in trouble. Even this produces the same error: $array_ref =& $object->array; [2004-10-25 23:14:57] benneh at gmail dot com I've just run into this problem, here is my test case Testcase: - class Language { private $lang_bits = array(); public function __get($lang_bit) { global $$lang_bit; if(!isset($this->lang_bits[$lang_bit])) { $this->lang_bits[$lang_bit] = $$lang_bit; } return $this->lang_bits[$lang_bit]; } } $page = array('bla' => 'xyz'); $lang = new Language; foreach($lang->page as $lang_key => $lang_bit) { echo $lang_key.' => '.$lang_bit; } Expected Results : -- bla => xyz Actual Results : Fatal error: Cannot access undefined property for object with overloaded property access Just confirming its presence in 5.0.2 WinXP SP2 Apache 1.3.31 [2004-07-28 01:02:28] chernyshevsky at hotmail dot com I know the class doesn't have a member called 'cows'. That's what __get() and __set() is for after all. If I change the code to $O->cows = array("Betty", "Agnes", "Jeff"); $temp = $O->cows; foreach($temp as $cow) { echo "$cow"; } Now why should it fail just because the property access is through foreach()? The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/29378 -- Edit this bug report at http://bugs.php.net/?id=29378&edit=1