. . .
. . .
Eventual setup issues
If extensions are not found, add the path to PHP and the path to the extensions to the system path. (Issue << 20101030°0411)
Problem: When starting Apache, error '.. extension .. not found' appears .. curl .. mysql (about 10 extensions). But in php.ini those extensions are activated. extension_dir points to ext, which normally works fine. Could not find, what is wrong. Workaround: placing the absolute path extension_dir = "D:\work\gipsydrive\app.php\trunk\php-5.3.2-Win32-VC6-x86\ext". Now PHP starts fine without error messages.
; extension_dir = "ext" ;;; experimentally opened (20100322°1601)
extension_dir = "D:\work\gipsydrive\app.php\trunk\php-5.3.2-Win32-VC6-x86\ext"
(2) When then debugging a PHP file with NetBeans, the fiel run, but debugging did not work, but an error appears, xdebug were not available. So we applied the same fix to the xdebug lines at the beginning of php.ini
. . .
. . .
This is a developers log file, created on the fly, not meant to enjoy a reader, but to catch knowhow, to be digged out in eventual later odd circumstances.
Getting PHP run on from the usb drive is easy. We just installed it on a local machine and then copied the created local folder to the usb folder.
During installation, we were asked for the Apache location. and some other things (installation screenshots are found in the downloads archives folder 20100309°1921).
The only machine specific thing it had done during installation,
seems to be appending something to httpd.conf:
#BEGIN PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
LoadModule php5_module "C:/Programme/PHP/php5apache2_2.dll"
#END PHP INSTALLER EDITS - REMOVE ONLY ON UNINSTALL
That's all? We can''t believe it! Perhaps there were entries in the Windows registry, as screenshot 20100312°1541 indicates.
Of course we have to adapt the path from C: to our usb path, as we already had adapted many other pathes in httpd.conf during the Apache installation.
It seems obvious what the lines mean: Apache needs to know where PHP resides, and Apache needs to load the PHP module.
Encountering the Problems with OXID eShop complaining a missing PHP MySQL module, we install phpMyAdmin in the meanwhile (download 20100322°1921). It is easy to install, just copy the unpacked file into the target directory. It comes with a nice documentation file. What will it say about the somehow missing MySQL Module?
Ok, let's go to MySQL and give user root passort root. Hahaha, there is pitfall: I did as the tutorial told me and created the password with quotes. This was a mess, resulting in scratching the workspace and checking out new (see MySQL chapter). Only after creating the password nicely, phpMyAdmin went on.
After resetting shutting down and restarting all components, with the next start of phpMyAdmin comes the next goodie:
In the Apache access log we find
127.0.0.1 - - [23/Mar/2010:00:42:00 +0100] "GET /phpmyadmin/error.php?lang=en&dir=ltr&type=Error&error=Cannot+start+session+without+errors%2C+please+check+errors+given+in+your+PHP+and%2For+webserver+log+file+and+configure+your+PHP+installation+properly. HTTP/1.1" 200 1209
and the Apache error log says
[Tue Mar 23 00:41:52 2010] [error] [client 127.0.0.1] File does not exist: G:/work/downtown/app.apache/trunk/htdocs/favicon.ico
Really? A missing favicon shall be the reason, phpMyAdmin is giving up?! And hey, the icon is not missing in the phpMyAdmin's folder, but in the calling folder. Why should phpMyAdmin care about?
Fine, in php.ini we find a line
;session.save_path = "/tmp".
We activate it and -- the error is gone.
|This was a nice text-book example of "Never trust an error message!" The sequence goes: (1) phpMyAdmin's english error message is vague. (2) Apache's error log charges favicon.ico. (3) The phpMyAdmin german error message is more concrete, it points to session.save_path, Schreibrechte. (4) Finally, the culprit was not the access rights, but the plain existence of the variable.|
Now phpMyAdmin obviously runs! So why does OXID eShop complain about "MySQL Modul für MySQL 5"?!?!?
As we learned in chapter OXID eShop Setup Details, PHP 5.3.2 is not the right version here, we have to downgrade.
We fetch the the lates PHP 5.2.x version from windows.php.net/download
As opposed to above of PHP 5.3.2 setup, we now want save the roundabout way over a local installation from the MSI file. Instead we just unpack php-5.2.13-Win32-VC6-x86.zip and place it directly on the USB. (What we don't know yet: Instead of saving us time, this way will cost us time, but as well give valuable insights into details of an Apache/PHP/MySQL setup ;)
The system adaptions then are:
That is all? We immediately are told different.
When starting our utility batchfile console-php-help.bat containing only the one commandline php-5.2.13-Win32-VC6-x86\php.exe -h, we receive the following error cascade:
We remember similar errors when running (the old 5.3.2) PHP for the first time on a machine different from the one we had the MSI installation. It looks as if pathes are not set correctly somewhere.
Inspecting the machine's environment path variable:
The path variable contains a path C:\Programme\PHP\, which was probably set with our initial MSI installation on this machine. The pointed-to-directory contains DLLs, but not php_pdo.dll. It contains ext\php_pdo_mysql.dll.
We should try to set a path inside the calling batch file first. Only, this would not work systemwide, as we finally like. To set systemwide pathes, we need would need Pathman.exe from the Windows ResKit-Utility, or the like. That might hamper a public portable project. We should set the path within a batchfile of the project, perhaps the one that starts Apache might be the right point. Don't know yet.
A first quick test should be easy. Upgrade php-help.bat with the line set path=%path%;G:\work\downtown\app.php\trunk\php-5.2.13-Win32-VC6-x86. No, this does not help. We make other experiments with pathes, but mostly are stuck with the following error.
Stuck with this error.
Even though in php.ini, we already have opened the line extension=php_pdo.dll, the module 'pdo' seems not be loaded.
Something is wrong with the PHP setting. Attempting to start Apache raises the Visual Studio Debugger(!), and Apache refuses to start. If we shutdown the lines loading the PHP module in httpd.conf, Apache starts.
We remember the PHP 5.3.2 MSI installation to automatically add lines to httpd.conf and decide also to have this done for PHP 5.2.13. So we make a MSI installation, just to see, what lines exactly it would write to httpd.conf. Hahaha -- see the surprise during the installation:
Manually configure the webserver! The only little thing why we made this installation at all, it did refuse to serve us with!
We study http://www.php.net/manual/en/install.windows.installer.msi.php . It contains some keywords worth to follow, e.g.:
Windows Registry PHP entries (see as REG file).
After some zigzag, somehow we got things running again (can't photograph each and every little step). One little fly crap remains for the moment:
That seems not so important for the moment, we can care about later. Most important is this screen:
Heureka! Notice the little green sqare at "MySQL module for MySQL 5". To toggle this one from red to green, all the today PHP downgrading session was about! The remaining red square about Apaches rewrite module should not be such big problem then.
Let's call it a day.
During the PHP downgrade session above we already notized a problem loading PHP modules e.g. "php_pdo.dll not found". Obviously, that was a missing path in the Windows environment.
Similar effects happen when running our portable PHP from the USB drive attached to a station, which has not yet seen this specific PHP.
We have to consider where and how to inject the path into the system. Setting it in a simple console window does not help, this would work only on that shell.
Using pathman.exe from the Windows Ressource Kit is not a preferred option because of license issues when publishing it in a open source project.
A nice description of possibilities we found at http://vlaurie.com/computers2/Articles/environment.htm
We try the registry manipulation.
We try the registry manipulation. The new path is shown immediately in a new shell window. But it is not shown in phpinfo(), where we finally need it. It works, but only after restarting the machine.
The question remains: How to introduce the necessary pathes on a new machine on the fly?
CHECK - We have to examine the possibility to set the path when starting Apache via a batchfile. If the path were set in the correct point of our command chain, it might propagate up to PHP.