I've been incrementally setting up a web server for research and testing purposes. The "server" is running Windows XP and I initially installed Apache Server 2.2 and PHP 5.3. That's been working great for a while. I am now needing to setup MySQL which I downloaded and installed MySQL v5.5. I am able to interact with MySQL via the command-line interface. In the process of setting up phpMyAdmin, I have encountered difficulties getting PHP and Apache to play nice with MySQL. Here's what I've discovered and tried:
In the php.ini file, when I attempt to uncomment either the php_mysql.dll or the php_mysqli.dll extension and restart the Apache server, the server crashes when it starts. The Windows event viewer says Apache failed to start due to "faulting module php5ts.dll".
The extension_dir parameter is set to ".\ext" and the php_mysql.dll and php_mysqli.dll files are in that directory.
I have also tried copying the libmysql.dll file from the lib folder of the MySQL directory to the Windows\System32 directory (with no change in behavior).
I'm at a bit of a loss to figure out what the next step is. Any suggestions?
The extension it's looking for is an extension output by php at compile time based on your configured build options. It is not looking for the header files from mysql itself.
Also, ".\ext" is a relative path that may or may not be valid in your installation. You may need to re-compile php to include mysql and mysqli (you should also compile PDO support) into your php build (Or whatever the windows equivalent of re-compiling is).
Also, you should make extension_dir an absolute path not relative.
Related
I recently upgraded Apache and PHP due to security, and I also use PHP to communicate with Oracle databases. The new PHP version only has php_oci8_12c.dll module, so I also installed Oracle 12c client.
After I enable the oci8 module, I noticed the module doesn't show up in Apache when I run phpinfo(), but if I run php -m, I find the oci8 module there. Further checking revealed that the PATH environment variable has not been updated since the upgrade, and that the new path only get appended at the end of the PATH variable.
I paste below the (stripped-down) PATH data from Apache:
C:\oracle\client11gR2_32\bin;C:\www\Apache24\bin;C:\www\php548;C:\database\mysql5528\bin;C:\oracle12c\client12c_32\bin;C:\www\php562;C:\www\php562\ext
Compared with system PATH variable:
C:\oracle12c\client12c_32\bin;C:\oracle\client11gR2_32\bin;C:\www\Apache24\bin;C:\www\php562;C:\www\php562\ext;C:\database\mysql5528\bin
I tried restarting the Apache service, and also uninstall/reinstall, but none works. It seems that the data somehow get 'cached' in a separate location, but I can't tell where. If I renamed the Oracle client 11g HOME folder, then the oci8 module is detected and loaded in Apache.
I've searched all around the internet for 'resetting' the Apache PATH variable, but to no avail, therefore I post it here. Please help.
There are two possible reasons I can think of:
The path to the 12c client is a user variable, not a system variable (but then I would expect it to be at the end of the path list)
The 12c client installer has directly modified the registry to add the path, and therefore the system environment has not recognised the change yet. (If you are running Apache as a service then just because your account can see the path change doesn't mean the SYSTEM account can see the change.)
Assuming the latter case, a server reboot would fix the problem. If you can't reboot the server then you can try stopping Apache, opening the Environment Variables dialog, and simply pressing OK (on this and all parent dialogs) to 'reinitialise' the system environment. Start Apache again and it should pick up the new setting.
On a related note: You should really replace the bundled OCI driver (1.4.10) with the most recent build from PECL (currently 2.0.8). As stated in the PECL description:
Use the older PHP OCI8 1.4.10 when using PHP 4.3.9
through to PHP 5.1.x, or when only Oracle Database 9.2 client
libraries are available.
The Windows download contains php_oci8.dll, php_oci8_11g.dll, and php_oci8_12c.dll. So you wouldn't have needed to try changing the Oracle client installation.
We are migrating from a Windows SBS 2011 to Windows Server 2012 R2.
We have an internal website that connects to our Oracle database using PHP.
I am trying to migrate this to the new server and so far I have:
Installed IIS Server Role
Installed PHP
Downloaded Oracle Instant Client to C:\instantclient
Added C:\instantclient to PATH System Variable
Added php_oci8.dll to php.ini and checked that PHP is actually using this php.ini
Restarted server
I am still getting error messages like oci_ commands not being recognised etc.
I'm lost. I've searched online and the instructions match what I have done from memory.
I haven't found a single thing online that I haven't done.
Depending on the version of InstantClient you have installed you might need to include the bin folder in the path, like so:
C:\instantclient\bin
To check if the DLL files are available in the path enter where oci*.dll in a command prompt. It should return a list of matching files.
Also, remember that just because your account can see the DLL files doesn't mean IIS/PHP can. That runs under a different account that might not have permission to access the files. Check your IIS error log and PHP php_errors.log file for any specific error messages.
Edit
After a rather lengthy chat, the problem was resolved by:
Updating the InstantClient from 10.1.0.5 to 10.2.0.5 (as mentioned in the module requirements: On Windows, the php_oci8 DLL needs Oracle client libraries from version 10gR2 or greater.)
Adding a copy of msvcr71.dll to the InstantClient folder.
Downloading and manually configuring PHP from php.net instead of using PHP Manager for IIS.
Ensuring the Path environment variable correctly pointed to the InstantClient and PHP folders.
try this:
extension=php_oci8_12c.dll
(instead of php_oci8.dll) - that is what I am using and you probably downloaded the same instant client as I did.
Trying to upgrade from PHP 5.2.5 to 5.2.17 (and then to 5.3.6 once that works) on IIS 6.0, installing the language itself runs just fine and I changed the PHP.ini/ect locations that IIS uses for PHP, everything still works but when I run PHP info on my site it still says it's running PHP 5.2.5. Restarted IIS, restarted the server even, no difference. What do I do to change which version/what location of PHP IIS is using?
When I install PHP 5.3.6 the site no longer works, so I know installing different versions is doing SOMETHING, but I think it might only be changing the PHP.ini my server is using, not the version of PHP.
In addition to installing the windows binary release of PHP I've also tried installing PHP from Microsoft's Web Platform Installer (both 5.3.6 and 5.2.17), after installing neither showed up as the current version in phpinfo either.
If you want to use php 5.3, you must install IIS FastCGI extension and run PHP as cgi script. From php 5.3 isapi is not supported. But everything works fine if you configure it, and as benefit you can use more php version simultaneously. IIS 6 is not a problem. Download PHP non thread safe.
For details see this, for example: http://learn.iis.net/page.aspx/247/using-fastcgi-to-host-php-applications-on-iis-60/
Download the latest VC11 x86 Non Thread Safe version of PHP from http://windows.php.net/download/
Once the zip is downloaded, right click on the zip file and select properties. Make sure you unblock the file.
Rename your current PHP folder to PHPold.
Find your php.ini file and rename it to phpold.ini
Extract the zip file to c:\temp\php.
Copy the php folder from c:\temp to wherever your old PHP folder was.
Go to your new php folder and copy php.ini-production and paste it to where your old php.ini file was
Rename php.ini-production to php.ini
On the server, make sure you have Notepad++ along with the Compare plugin. If you need the compare plugin, use these steps. http://www.davidtan.org/how-to-compare-two-text-files-using-notepad-plus/
In the location that stores your phpold.ini and php.ini, right click on each of those files and open them with Notepad++. On the php.ini, only make changes to the lines with the >> next to them.
Once the changes have been made, make sure you save php.ini.
Go to Services and restart IIS.
Solution has been to move to Apache in my case. IIS 7 has better tools but IIS has proven to be a poor environment for development in this case.
I need to install or use php on a windows 2003 server that already has php 5.2.0.0 installed due (I think) to setting up symantec backup exec. I don't want to interfere with backup exec's php.ini settings - and would rather be able to control my own configuration of php.
searching for php shows that php.exe and other php files are currently installed in
c:\program files\symantec\backup exec\
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
There is no PHPRC entry in the server properties > environment variables and I'm pretty sure that the php.exe location is not included in the PATH variable. ...unless the actuall install location is different from the c:\program files\symantec\backup exec\ dir.
Any suggestions on how to proceed?
I'm almost certain that installing the current version of php 5.2.8 to c:\php would be disastrous or calamitous in some way.
What makes you say that :) I've run separate PHP versions on the same machine side by side and not run into bother.
AFAIK the Symantec install should not conflict with your own installation, nor should the separate php.ini files conflict with each other.
[Response to comment]
First thing to note is that I have no experience of Backup Exec or what it uses PHP for. I'm guessing it uses it for its own internal stuff and doesn't spread itself over the OS. Test this by searching for php.ini and php DLLs on the file system. I'm betting it's all quite self contained. PHP searches for the config file as noted here: PHP Site . As you note, BE hasn't set the PHPRC variable. Check it hasn't used those Registry entries either. On a different tack, has BE installed an admin site already on IIS? If so, check the IIS Web Service Extensions to make sure it hasn't already registered the PHP ISAPI dll or PHP CGI exe. IF not, I think you should be okay for your new install.
To be on the safe side, do a manual PHP install as illustrated here: PHP Site. That way, you know exactly what you have installed, and can easily remove the files again if they cause a problem. I can't imagine a problem here that would require you to reinstall BE.
I am trying to install PHP onto my development box (XP SP3 / IIS 5.1) I've got PHP 5.2.6 stable downloaded (the MSI installer package) and I am getting an error "Cannot find httpd.conf". After that the install seems to breeze by quickly (more quickly than I would have expected) and when I try to execute a simple PHP script from my localhost test directory that I created, I get a slew of missing DLL errors. I have seen posts out there which indicate that its possible and has been done. I dont see any bug reports for this MSI at PHP.NET support. Any ideas?
Not sure if you already have this but I use WAMP from http://www.wampserver.com/en
It's easy and simple to set up, it has an icon in the system tray to show that its active and you can make it go online or available to the outside by clicking the icon and setting it. I used this when I was first learning PHP since it has everything in one, no need to setup any other service like IIS.
Probably the installer didn't configure your server to use PHP properly. Check out Microsoft's page on enabling PHP on IIS or alternatively switch to Apache if that's a viable option.
I'll see if I can remember it correctly:
Unzip PHP zip file into c:\Program Files\php (or run the installer)
Copy php5ts.dll into c:\windows\system32
Copy php.ini.dist into c:\windows and rename it to php.ini
Edit c:\windows\php.ini and look for extension dir - make it point to c:\Program Files\php\extensions (or wherever you put it)
This is where my memory gets fuzzy: Edit your IIS application settings, add a script map for .php files, and set the executable to php5ts.dll
Profit!?!??!?!