#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=46201edit=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=46201edit=1 -- Try a CVS snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=46201r=trysnapshot52 Try a CVS snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=46201r=trysnapshot53 Try a CVS snapshot (PHP 6.0): http://bugs.php.net/fix.php?id=46201r=trysnapshot60 Fixed in CVS: http://bugs.php.net/fix.php?id=46201r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=46201r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=46201r=needtrace Need Reproduce Script:http://bugs.php.net/fix.php?id=46201r=needscript Try newer version:http://bugs.php.net/fix.php?id=46201r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=46201r=support Expected behavior:http://bugs.php.net/fix.php?id=46201r=notwrong Not enough info: http://bugs.php.net/fix.php?id=46201r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=46201r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=46201r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=46201r=php4 Daylight Savings: http://bugs.php.net/fix.php?id=46201r=dst IIS Stability:http://bugs.php.net/fix.php?id=46201r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=46201r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=46201r=float No Zend Extensions: http://bugs.php.net/fix.php?id=46201r=nozend MySQL Configuration Error:http://bugs.php.net/fix.php?id=46201r=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 div$cow/div;
}
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=29378edit=1
