ID: 42613 User updated by: patrick at baynewmedia dot com Reported By: patrick at baynewmedia dot com Status: Open Bug Type: *General Issues Operating System: Windows XP Pro & Windows Vista PHP Version: 5.2.4 New Comment:
mfvivino at vivmedia dot net: That's another interesting problem and frankly I don't expect the path to be missing for seemingly no reason. I'll keep my eyes open for that and see if it does the trick. Thanks for the research though I'm still of the opinion that this shouldn't be required ;) Previous Comments: ------------------------------------------------------------------------ [2007-10-17 11:28:46] mfvivino at vivmedia dot net Patrick at BayNewMedia: Thanks for the suggestion. That was not the issue for me, however, it was close. Evidently the sequence of events went like this: (1) Automated install put c:\php52 (my install dir) in the path (2) Automated install otherwise screwed up royally (3) I uninstalled -- removing c:\php52 from the path! -- only this was not going take effect for system services (like Apache) until after a reboot, whenever I happened to do that (4) Did manual install and configuration, tested; I've done enough of these on Windows before to be sure the path is properly set, buy hey, it was working, and I wasn't thinking! ;) All looked good for awhile...except after a reboot some days later, the path was now missing. So the fix for me was simple: (5) Added c:\php52 back to the path and rebooted. All appears well enough now...so far. However, the win32 installer, as has been pointed out elsewhere here, is a major train wreck and source of confusion. I suspect unix/linux platforms get the priority in terms of attention here, and perhaps that's why responses have not been so forthcoming? Still, I suggest that PHP development folks either tighten up and clarify the win32 installer, or pull it entirely, in favor of one clear and simple win32 installation guide. After all, the PHP site already "recommends" a manual installation in favor of the automated one in any case. After this experience, I very, very strongly second that recommendation. My $0.02. ------------------------------------------------------------------------ [2007-10-16 15:50:27] patrick at baynewmedia dot com [EMAIL PROTECTED]: I did in fact select everything to install. I was under the assumption (mistaken, it seems), that installation doesn't necessarily mean enabling. After all, if I don't install now but at some point in the future decide that I need a new extension, I could simply enable it instead of having to re-install or re-download another package. But that's something to try so I'll give it a whirl. Still doesn't seem like it should work this way though. Maybe the addition of "enabled extensions" in the installation routine may be useful. mfvivino at vivmedia dot net: Wow, that is a little slice of frustration! The thing I found with the PHP.INI file is that, despite loading from a specific location at the time of installation, that location changes on subsequent executions or after reboots. For example, my first installation was in C:\PHP and the INI file loaded from there. I changed a variety of settings in the INI file which were reflected in the next few rounds of execution. One of the suggestions in getting MySQL going was re-booting so I did and after that, the INI file "could not be found". It was still there, but after some searching I discovered it was trying to load from C:\WINDOWS. Why? Who knows...there was no PATH environment variable pointing there (only to C:\PHP), and there were no paths within the INI file itself to anything other than C:\PHP and its subdirectories. Again, this was another case where people were noting these bugs but the folks at PHP kept insisting there was nothing for them to fix. Look, I'm a developer and my work is often far from perfect. I tend to suspect that there's misuse of my software when people report errors and I can understand why the people at PHP would tend towards this as well. At this point, however, it just seems like people are burying their head in the sand. We've all been through the "fixes" here, I'm sure, and it's still failing dismally. That part doesn't bother me at all; what I don't like is that beside these relatively simple fixes, the issue seems to be being ignored. I can run PHP but for most of the applications I need it for now, it's useless. It's at a point where I simply *can't* run it for any useful purposes so the entire PHP project is basically a brick. The complete lack of concern (or if it's there, I'm not hearing a peep about it), is the most troubling aspect of this whole fiasco. Again, is anyone out there listening and looking at this problem? I'm referring to the core PHP developers...does anyone even care that PHP just doesn't have much useful functionality left? Has the PHP project simply been abandoned? It's been two months since I posted this report and no one has mentioned "Oh...it's being looked at now." As far as I can see, absolutely zilch is being done about this. That is, if anyone is even aware that these problems exist. I'm not expecting quick fixes and maybe there's no simple solution, but is anyone even aware? I greatly appreciate the community involvement in trying to address these issues, but this is CORE, BASIC stuff, and no one seems to be bothered by it in the least. Very, very discouraging. Python, Ruby, or Java may be good alternatives. Sucks that I'm being forced to switch because of just plain indifference :( ------------------------------------------------------------------------ [2007-10-16 11:00:20] mfvivino at vivmedia dot net It gets weirder for me. I experienced tons of problems with the installer, so scrapped that (did uninstall) and installed manually via .zip which was easy enough. I ONLY enabled mysql, and amazingly enough, it worked!. I ran a simple test: <?php phpinfo(); ?> which reported mysql as enabled; and I was subsequently able to install PHP shopping cart software. So far, so good... Now for the fun part: after rebooting the machine, mysql is being reported as not enabled anymore, so I checked the apache log and sure enough, I see the same cryptic error as others have reported here: PHP Warning: PHP Startup: Unable to load dynamic library 'c:/php52/etx\\php_mysql.dll' - The specified module could not be found. \r\n in Unknown on line 0. And now of course phpinfo() shows mysql indeed is missing I thought perhaps the reference to '\r\n' had something to do with windows linefeeds, so I ran a dos2unix conversion on the php.ini file -- no go. Still the same problem. For fun, I tried disabling mysql and enabling a different module. Doesn't seem to matter, get the same problem with any and all. As others have already noted, this is extremely frustrating -- and atypical. I am also a very long-time PHP user and have not ever experienced this level of difficulty with basic PHP installation/configuration. ------------------------------------------------------------------------ [2007-10-11 23:55:53] [EMAIL PROTECTED] During the installer you must have selected to install every extension onto the hard disk, this in turn would have enabled all of those extensions some of which don't work. I'm under the impression that the extension maintainer removed the ones that were broken, but one can still shoot themselves in the foot by enabling everything. Uninstall PHP and then re-install, when you do make sure you only enable the modules that you need. ------------------------------------------------------------------------ [2007-10-11 21:38:13] patrick at baynewmedia dot com Good to see that absolutely no progress has been made. Does anyone actually read these bug reports or what? [EMAIL PROTECTED]: If you'd bothered to read what I'd posted, I said I didn't know if I needed all these extensions. They're not listed anywhere and the default php.ini file comes with all of them enabled. Your suggestion "How about the basic .zip file, just unpack that and try with it instead..? " is exactly the type of piddly suggestion I was referring to. It's dismissive and insulting and yes, I tried that many times. azlan01: Good suggestion and thank you for not assuming I'm a complete idiot. Unfortunately, that didn't make any difference. The pear extensions also give me some trouble though somewhat less than the default ones. I've tried disabling all of the extensions erroneously listed in pop-ups...I say erroneously because the pop-up messages don't match the ones on the command line when I run PHP. That's just another problem with the latest PHP release but hardly the biggest. So, now I have a working PHP install once I've disable all of the erroneous DLLs (not all are problematic...anyone care to explain why?). Unfortunately, trying to access a MySQL database has proven to be a complete dead-end. The "libmysql.dll" file simply fails to load. Period. I put it in Windows, Windows/system, windows/system32, the php install directory, the php extensions directory, the c:\ drive; added PATH directions to it...heck, I pointed the php.ini file *directly* at it using a full path. Simply, it doesn't load. I tried a myriad version of the file ranging from the version 4 (PHP) DLL up to the version 5 one, also including the newest ones from MySQL.org. Still nothing. Please please please don't keep ignoring these problems! Maybe there's a very good reason why I can't run PHP successfully but so far the only suggestion has been that it's somehow my fault or that during the last two months I've somehow overlooked the glaringly obvious. "No feedback was provided for this bug for over a week, so it is being suspended automatically." ... won't make it go away! Someone please take some responsibility and look into this! ------------------------------------------------------------------------ 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/42613 -- Edit this bug report at http://bugs.php.net/?id=42613&edit=1