Home   -   Computerkurs   DemoMatrix   Editpointstatic   Folderwatcher   Gipsydrive   Licenses   Shrinkseries   V4   More...  

Apache   Chrome   Firefox   MySQL   NetBeans   Niwa   Opera   OXID   PHP   Ruby   SharpDevelop   Subversion   Tools  

Previous page Home chapter Next page


Trilo - Downtown - Gipsydrive


Project status:Running


. . .

How to run it

. . .

Q & A

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


(Workaround 20101030°0421)


. . .

Technical details

. . .


Setup log

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.

Local installation from MSI file

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).

PHP installation screenshot
Screenshot from the PHP installation, showing a list of webservers PHP will integrate into by default.

The only machine specific thing it had done during installation, seems to be appending something to httpd.conf:
PHPIniDir "C:/Programme/PHP/"
LoadModule php5_module "C:/Programme/PHP/php5apache2_2.dll"

That's all? We can''t believe it! Perhaps there were entries in the Windows registry, as screenshot 20100312°1541 indicates.

Make PHP start from USB

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.

Add phpMyAdmin

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?

phpMyAdmin's first start

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.

phpMyAdmin passed the starscreen
phpMyAdmin after successful passing the password screen.

After resetting shutting down and restarting all components, with the next start of phpMyAdmin comes the next goodie:

phpMyAdmin throws an error

In the Apache access log we find - - [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] 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?

phpMyAdmin throws an error in german
In german language, the error message is somewhat more explicit (adding "(session.save_path, Schreibrechte)"

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.

phpMyAdmin created a table
phpMyAdmin created a table

Now phpMyAdmin obviously runs! So why does OXID eShop complain about "MySQL Modul für MySQL 5"?!?!?

Downgrading from PHP 5.3.2 to 5.2.13

(Session 20100325°1717)

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 (download 20100325°1741).

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:

  1. Adapt httpd.conf. Since php5apache2_2.dll stays the same, it seems easy, just replace the old pathes against the new pathes:
    ###PHPIniDir "../../../app.php/trunk/php-5.3.2-Win32-VC6-x86"
    ###LoadModule php5_module "../../../app.php/trunk/php-5.3.2-Win32-VC6-x86/php5apache2_2.dll"
    PHPIniDir "../../../app.php/trunk/php-5.2.13-Win32-VC6-x86"
    LoadModule php5_module "../../../app.php/trunk/php-5.2.13-Win32-VC6-x86/php5apache2_2.dll"
  2. Adapt php.ini. We don't just copy our old one to the new place, but make a fresh one from php.ini-recommended. There might be things which exist in the old one and not in the new, or vice versa (remember e.g. zend.ze1_compatibility_mode). Since we marked our changes with ;;; we quickly find the respective lines in the old php.ini.
  3. In php.ini, switch extension dir:
    ;;;extension_dir = "./"
    extension_dir = "ext"
  4. In php.ini activate extensions:
    (BTW, do we really need this one?)
  5. In php.ini activate other things:
    session.save_path = "/tmp"
  6. In php.ini control zend.ze1_compatibility_mode. Fine, it is already set as needed:
    zend.ze1_compatibility_mode = Off
  7. Adapt the pathes in our utility batchfiles, means in

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:

Error one
Error one

Error two
Error two

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:

Inspecting the path environment variable
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
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:

Installer cannot access httpd.conf
The installer cannot access httpd.conf.

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 (20100325°2010 pdf ). It contains some keywords worth to follow, e.g.:

Windows Registry PHP entries
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:

Image 'phpMyAdmin is missing the mcrypt extension'
phpMyAdmin is missing the mcrypt extension

That seems not so important for the moment, we can care about later. Most important is this screen:

OXID starting with PHP MySQL Module being o.k.
OXID starting with PHP MySQL Module being o.k.

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.

Make PHP run on any station

(Session 20100326°2311)

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 (png pdf mht)

We try the registry manipulation.

Manipulating the global environment path via the registry
Manipulating the global environment path via the registry.

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.





Imprint : www.trilo.de