ID: 29224
User updated by: marcschroeder at hotmail dot com
Reported By: marcschroeder at hotmail dot com
Status: Bogus
Bug Type: *Configuration Issues
Operating System: Microsoft Windows XP
PHP Version: 5.0.1
New Comment:
In my comment d.d. 3 august 2004 I disliked the dismission of my
configuration issue as 'bogus', when the proposed solution consisted in
a hack of the operating system (which is basically what one is doing
when copying files into the windows/system32 folder).
I understand that PHP is originally developed under unix, and that the
concern of porting it to all other platforms is not the first concern
of the makers. But on the other hand PHP has grown so big these days
that the issue cannot be neglected anymore.
The problems of coying files around rise when one has to upgrade PHP.
On has to remove the old files (which are not recognizable
unequivocally by their names) from the system folder. If you
accidentally remove that one important file which makes windows tick,
then you crash your whole system forever. The installation procedure of
PHP 5 recognizes the issue:
"Upgrading from a previous PHP version: Previous editions of the manual
suggest moving various ini and DLL files into your SYSTEM (i.e.
C:\WINDOWS) folder and while this simplifies the installation procedure
it makes upgrading difficult. We advise you remove all of these files
(like php.ini and PHP related DLLs from the Windows SYSTEM folder)
before moving on with a new PHP installation. Be sure to backup
these files as you might break the entire system."
The installation procedure suggests: "And as you'll soon learn, the
preferred method for installing PHP is to keep all PHP related files in
one directory and have this directory available to your systems PATH."
So PHP makes the installation of PHP dependent on a learning curve,
which is a joke. Any programmer/sys.administrator who in a production
environment dares to think of changing the content of system
directories should be fired on the spot, or at least be deprived of
root privileges.
This is why the classification as bogus made me angry.
In the mean time I found out that the bug IS BOGUS.
I thought that I had a PEAR DB problem. As a matter of fact I had not
enabled MySQL in php.ini by
- enabling the extension:
extension=php_mysql.dll
- settting the directory in which the loadable extension reside:
extension_dir = "C:\php\ext\"
Actually I had tried this several times, but I forgot to restart the
webserver (Apache) afterwards and I tought that I had not done the
correct thing.
I believe that not all submitters adress the originally submitted
issue, therfore I reformulate the bug as it turned out to be. The bug
#29224 is: "MySQL does not work".
It is clear that this bug IS BOGUS, if one realizes that MySQL support
-- disabled in the distributed installation -- has to be enabled
explicitly. This is a good thing in itself, as it is a way to
distinguish "core" PHP from PHP extensions, and makes it possible to
enable alternative ways of supporting MySQL and/or other packages.
Maybe someone should write a Winbdows application which allows to
manage the PHP installation on Microsoft platforms. This is possible
only if PHP adresses all locations on disk by environment variables,
which are described. It seems that this is actually done already. So a
Windows PHP Installation Manager does not seem too far away.
Previous Comments:
------------------------------------------------------------------------
[2004-09-02 13:16:35] marcschroeder at hotmail dot com
In my comment d.d. 3 august 2004 I disliked the dismission of my
configuration issue as 'bogus', when the proposed solution consisted in
a hack of the operating system (which is basically what one is doing
when copying files into the windows/system32 folder).
I understand that PHP is originally developed under unix, and that the
concern of porting it to all other platforms is not the first concern
of the makers. But on the other hand PHP has grown so big these days
that the issue cannot be neglected anymore.
The problems of coying files around rise when one has to upgrade PHP.
On has to remove the old files (which are not recognizable
unequivocally by their names) from the system folder. If you
accidentally remove that one important file which makes windows tick,
then you crash your whole system forever. The installation procedure of
PHP 5 recognizes the issue:
"Upgrading from a previous PHP version: Previous editions of the manual
suggest moving various ini and DLL files into your SYSTEM (i.e.
C:\WINDOWS) folder and while this simplifies the installation procedure
it makes upgrading difficult. We advise you remove all of these files
(like php.ini and PHP related DLLs from the Windows SYSTEM folder)
before moving on with a new PHP installation. Be sure to backup
these files as you might break the entire system."
The installation procedure suggests: "And as you'll soon learn, the
preferred method for installing PHP is to keep all PHP related files in
one directory and have this directory available to your systems PATH."
So PHP makes the installation of PHP dependent on a learning curve,
which is a joke. Any programmer/sys.administrator who in a production
environment dares to think of changing the content of system
directories should be fired on the spot, or at least be deprived of
root privileges.
This is why the classification as bogus made me angry.
In the mean time I found out that the bug IS BOGUS.
I thought that I had a PEAR DB problem. As a matter of fact I had not
enabled MySQL in php.ini by
- enabling the extension:
extension=php_mysql.dll
- settting the directory in which the loadable extension reside:
extension_dir = "C:\php\ext\"
Actually I had tried this several times, but I forgot to restart the
webserver (Apache) afterwards and I tought that I had not done the
correct thing.
I believe that not all submitters adress the originally submitted
issue, therfore I reformulate the bug as it turned out to be. The bug
#29224 is: "MySQL does not work".
It is clear that this bug IS BOGUS, if one realizes that MySQL support
-- disabled in the distributed installation -- has to be enabled
explicitly. This is a good thing in itself, as it is a way to
distinguish "core" PHP from PHP extensions, and makes it possible to
enable alternative ways of supporting MySQL and/or other packages.
Maybe someone should write a Winbdows application which allows to
manage the PHP installation on Microsoft platforms. This is possible
only if PHP adresses all locations on disk by environment variables,
which are described. It seems that this is actually done already. So a
Windows PHP Installation Manager does not seem too far away.
------------------------------------------------------------------------
[2004-09-02 13:16:17] marcschroeder at hotmail dot com
In my comment d.d. 3 august 2004 I disliked the dismission of my
configuration issue as 'bogus', when the proposed solution consisted in
a hack of the operating system (which is basically what one is doing
when copying files into the windows/system32 folder).
I understand that PHP is originally developed under unix, and that the
concern of porting it to all other platforms is not the first concern
of the makers. But on the other hand PHP has grown so big these days
that the issue cannot be neglected anymore.
The problems of coying files around rise when one has to upgrade PHP.
On has to remove the old files (which are not recognizable
unequivocally by their names) from the system folder. If you
accidentally remove that one important file which makes windows tick,
then you crash your whole system forever. The installation procedure of
PHP 5 recognizes the issue:
"Upgrading from a previous PHP version: Previous editions of the manual
suggest moving various ini and DLL files into your SYSTEM (i.e.
C:\WINDOWS) folder and while this simplifies the installation procedure
it makes upgrading difficult. We advise you remove all of these files
(like php.ini and PHP related DLLs from the Windows SYSTEM folder)
before moving on with a new PHP installation. Be sure to backup
these files as you might break the entire system."
The installation procedure suggests: "And as you'll soon learn, the
preferred method for installing PHP is to keep all PHP related files in
one directory and have this directory available to your systems PATH."
So PHP makes the installation of PHP dependent on a learning curve,
which is a joke. Any programmer/sys.administrator who in a production
environment dares to think of changing the content of system
directories should be fired on the spot, or at least be deprived of
root privileges.
This is why the classification as bogus made me angry.
In the mean time I found out that the bug IS BOGUS.
I thought that I had a PEAR DB problem. As a matter of fact I had not
enabled MySQL in php.ini by
- enabling the extension:
extension=php_mysql.dll
- settting the directory in which the loadable extension reside:
extension_dir = "C:\php\ext\"
Actually I had tried this several times, but I forgot to restart the
webserver (Apache) afterwards and I tought that I had not done the
correct thing.
I believe that not all submitters adress the originally submitted
issue, therfore I reformulate the bug as it turned out to be. The bug
#29224 is: "MySQL does not work".
It is clear that this bug IS BOGUS, if one realizes that MySQL support
-- disabled in the distributed installation -- has to be enabled
explicitly. This is a good thing in itself, as it is a way to
distinguish "core" PHP from PHP extensions, and makes it possible to
enable alternative ways of supporting MySQL and/or other packages.
Maybe someone should write a Winbdows application which allows to
manage the PHP installation on Microsoft platforms. This is possible
only if PHP adresses all locations on disk by environment variables,
which are described. It seems that this is actually done already. So a
Windows PHP Installation Manager does not seem too far away.
------------------------------------------------------------------------
[2004-08-27 23:27:52] at989 at earthlink dot net
I think this is a IIS problem, not PHP. I had the same thing several
times, and each time it goes away after I tweak something in IIS.
I changed the dll to which the php extension is maped to see if I got a
similar message or not (to see if this was indeed a php or iis problem).
I got "module not found" message. After I restored the mapping,
everything worked fine :-/
I have no idea why this happened. But i hope this will help someone who
knows more about iis to figure this out.
------------------------------------------------------------------------
[2004-08-23 18:31:01] bentrafford at yahoo dot com
Make that six users with the same problem. I've searched the bug
database, the net, newsgroups, and found no resolution to this issue,
other than PHP developers declaring it bogus.
Well, I've got my path updated, and the following set in my php.ini:
extension_dir = ".;c:/php/ext/"
I'm still getting the same issue as described above. This is either a
bug with PHP or a bug with the documentation.
------------------------------------------------------------------------
[2004-08-03 00:58:50] marcschroeder at hotmail dot com
Who set the status to 'Bogus'? Why?
I pretended that the current installation of PHP 5.0.0. does not
install PEAR DB?
5 users claimed that they could reproduce the bug.
The suggested solutions consisted in moving files around on a computer
to places where "it might work". The solutions only claim to "solve the
problem", but do not claim that there is no problem.
Somebody else suggests that I change the system path.
But I did add the following system variables already:
"PHP_PEAR_SYSCONF_DIR"="C:\\php"
"PHP_PEAR_INSTALL_DIR"="C:\\php\\pear"
"PHP_PEAR_DOC_DIR"="C:\\php\\pear\\docs"
"PHP_PEAR_BIN_DIR"="C:\\php"
"PHP_PEAR_DATA_DIR"="C:\\php\\pear\\data"
"PHP_PEAR_PHP_BIN"="C:\\php\\php.exe"
"PHP_PEAR_TEST_DIR"="C:\\php\\pear\\tests"
Do these environment variables have no effect?
I start to believe that PHP is a tool for hackers only, and that the
need of a controlled installation procedure is not present in the mind
of the PHP community.
This is really sad, as I like PHP a lot.
------------------------------------------------------------------------
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/29224
--
Edit this bug report at http://bugs.php.net/?id=29224&edit=1
