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

OXID eShop logo

Trilo - Downtown - Gipsydrive

OXID eShop

Project status:Running
Dependencies:Apache, PHP, MySQL


This shall become a sample webshop running from an USB drive, serving as a template to branch off customer projects. . . .

How to run it

. . .

Q & A

. . .

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.

Make it start

Download OXID_ESHOP_CE_4.2.0_23610.zip from www.oxid-esales.com/en/download/open-source-ecommerce-solution-oxid-eshop-community-edition [download archives 20100301°0421 ] and unpack it into the usb folder.

Point the Apache webserver via an alias to the OXID folder.

Chapter Apache Setup Details tells, how we set the alias to reach the OXID folder via "http://localhost/oxid". This is necessary, because in our workspace setup, the OXID folder is not a subdirectory of DocumentRoot.

We reach the OXID start screen via "http://localhost/oxid/index.php". Without the /index.php, Apache wants to show the plain OXID folder, but this is prevented by the .htaccess file.

OXID eShop very first start
The OXID eShop very first start. We have to fight the two little red sqares. This it will turn out not to be easy at all.

The little red squares tell, we have a problem with PHP's MySQL module and with the Apache rewrite module.

Is Apache's rewrite module working?

In httpd.conf we have this line:
LoadModule rewrite_module modules/mod_rewrite.so
Is this not what OXID wants?

We need to find out more about mod_rewrite and find first help with http://skiffie.com/... [stack mht pdf png]. It is the -M option which can tell us what modules are loaded at runtime. Using it, we find the rewrite_module being loaded!

View the loaded Apache modules
The loaded Apache modules.

Apache says, it's rewrite module is loaded!. So why does OXID complain?

Garantee the PHP MySQL module working

In php.ini, we find this sequence:
; Directory in which the loadable extensions (modules) reside.
; http://php.net/extension-dir
; extension_dir = "./"
; On windows:
; extension_dir = "ext"

Obviously the extensions are just not activated. We open the last line, now the extensions should be switched on.

But this does not help with the OXID start screen's complaint.

Looking for systematic help at www.oxid-esales.com: Überblick über die Installation [png] , Datenbank neu anlegen [png] , Dateien auf den Server kopieren [png] , Setup aufrufen [png] . Creating a new database first might be a good idea.

Found nice primer article from Andreas Ziethen on t3n.de by the way: Das Open-Source-Shop-System individuell anpassen [png]. He says e.g.: Apache variables REQUEST_URI or SCRIPT_URI must exist. What is this? With phpinfo() we can see, REQUEST_URI does exists.

Our exact problem was asked in the OXID eSales forum: Fehler Schritt 1: MySQL Modul für MySQL 5 [png]. But the solution was to use XAMPP. This is no solution for us.

This one OXID eSales forum thread seems more informative: MySQL Module [png]. Here the answer was to update the PHP version. But we have already the latest stable version 5.3.2.

Little experiment inbetween. We have two different PHP folders app.php\trunk\PHP and app.php\trunk\php-5.3.2-Win32-VC6-x86, we toggle between them. PHP comes from a local installation, php-5.3.2-Win32-VC6-x86 comes from a pristine unzipping (or the like). In the second, we even see the "GDlib v2 [v1] incl. JPEG support" and "mbstring" modules fail, and they function after being switched on in php.ini. So we have at least some comparison, that the PHP MYSql Module is correctly switched on in php.ini, and the problem must be somewhere else.

Looking for more help in Das Deutsche PHP-Forum, article " mysql modul wird nicht geladen " [png] . => we try copying libmysql.dll into apache/bin and system32 and app.php\trunk\php-5.3.2-Win32-VC6-x86. This does not help. Remove the files to cleanup this try.

We included phpMyAdmin in the system, and it runs fine. This should mean, the PHP MySQL module is all right! OXID eShop's error message seems to be misguiding.

Another question/experiment. If we deliberately shutdown the PHP MySQL module in PHP, will phpMyAdmin still run? If then phpMyAdmin does not run anymore, it is confirmed, that the PHP MySQL module really works, and only OXID does not recognize it correctly.

This two lines in php.ini we shut down temporarily:
extension=php_mysql.dll ;;; opened (20100322°1603)
extension=php_pdo_mysql.dll ;;; opened/closed (20100322°1606)

How does phpMyAdmin respond to the shutdown lines?

phpMyAdmin without the PHP MySQL module.
phpMyAdmin complains if the MySQL module is switched off in
php.ini. This confirms that otherwise the module works indeed.

This error screen contains two good links: the online PHP Manual's MySQL section and the local phpMyAdmin documentation, which is telling:

(1.20)   I receive the error "cannot load MySQL extension, please check PHP Configuration".

To connect to a MySQL server, PHP needs a set of MySQL functions called "MySQL extension". This extension may be part of the PHP distribution (compiled-in), otherwise it needs to be loaded dynamically. Its name is probably mysql.so or php_mysql.dll. phpMyAdmin tried to load the extension but failed.

Usually, the problem is solved by installing a software package called "PHP-MySQL" or something similar.

Back to Apaches rewrite module

(Session 20100324°1500)

Since we had bad luck debugging PHP MySQL module, we try debugging Apache's rewrite module. The similar thing in the both cases is: obviously the both modules exist and work, but are not accepted by OXID.

In OXID eSales forum, we find a 2008 thread "Probleme mit Apache mod_rewrite Modul" [png pdf] containing interresting keywords:

  1. Apache can run PHP as a module or as CGI. Someone had the mod_rewrite problem when running PHP as module, and the problem was gone when running it as CGI. This has to be set in httpd.conf.
  2. .htaccess is mentioned several times. (We already had this shutdown by renaming it to .htaccess.SILENCED.)
  3. A crowbar method: in core/oxsysrequirements.php in line 138 delete the text 'mod_rewrite'.
  4. (The original posters solution finally was:) Deletion of the database, deletion of shop files, new upload, setting php_flag register_globals in .htaccess and setting some rights manually.

We try the crowbar method. Since we have a later OXID version, it is not line 138, we guess a sequence in line 146 and temporarily outcomment 'mod_rewrite':
$aRequiredServerConfigs = array(
    /* 'mod_rewrite' */ /* temporarily shutdown (20100324°1601) */

Indeed, this helps against the rewrite module error.

Temporarily overcome the Apache mod_rewrite problem.
Got rid of the Apache mod_rewrite test in core/oxsysrequirements.php

Fine! We found a way to overcome the Apache rewrite module roadblock. Only, then we have a crippled OXID. We will see, at which point this horrid workaround knocks back!

Recall system requirements

At several places in the internet, a list of system requirements can be found. Let's put it here to explicitly work it off.

Run PHP as CGI

In one forum thread, someone mentioned, the PHP MySQL module problem was gone after he switched from PHP module to PHP CGI flavour. Let's try it!

A first hint what is necessary to switch to CGI mode, we find at 2008 Bobulous Configuring Apache to use PHP in CGI mode [png pdf] . For us an even better document seems Configuring Apache to Use PHP as CGI on Windows Systems [png pdf] .

To run PHP as CGI we make the following changes in httpd.conf:

  1. In the <IfModule alias_module> section we add a ScriptAlias
    <IfModule alias_module>
       . . .
       ### Experimental (20100324°1821)
       ScriptAlias /php/ "G:/work/downtown/app.php/trunk/php-5.3.2-Win32-VC6-x86/"

  2. In the <IfModule mime_module> section we add AddType
    <IfModule mime_module>
       . . .
       ### Experimental (20100324°1821)
       AddType application/x-httpd-php .php

  3. The original LoadModule we shut down
    #### Experimentally shutdown (20100324°1821)
    #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"

  4. We append an Action line and a Directory control section
    ### Experimental (20100324°1821)
    Action application/x-httpd-php "/php/php-cgi.exe"
    <Directory "G:/work/downtown/app.php/trunk/php-5.3.2-Win32-VC6-x86/">
       AllowOverride None
       Options None
       Order allow,deny
       Allow from all


It works! PHP is runing as CGI. But the OXID welcome screen is still the same, it shows two little red sqares stay exactly the same.

Running PHP as CGI does not help with the PHP MySQL module problem.

We restore the original setting in httpd.conf.

Run PHP from local drive instead from USB

Perhaps the PHP MySQL module problem has to do with our specific portable construct. We should try to run PHP (and the other components) not from USB drive but from an official installation.

The steps are:

  1. Restore the original PHP entries in httpd.conf.
  2. Replace the local php.ini with the one from the USB drive to carry the settings already made.

Now PHP runs from C:\Programme\PHP. But the error in OXID's start screen stay the same.

Address OXID via Apache DocumentRoot instead Alias

With Niwa, the start problem was solved, after it was not addressed via an Apache alias, but directly as Apache DocumentRoot (compare chapter Niwa CMS Setup Details). We don't expect such behaviour from OXID, but let's settle the question.

We modify httpd.conf:
DocumentRoot "../../../app.oxid/trunk/OXID_ESHOP_CE_4.2.0_23610"

Browsing to http://localhost, the directory listing is shown. We notice by the way: all files are shown, but not .htaccess.SHUTDOWN. It seems not reliable shutdown.

We rename .htaccess.SHUTDOWN to SHUTDOWN_.htaccess._SHUTDOWN. Aha! Now the file appears in the listing got from http://localhost! It does not help against the two red squares in OXID's start screen.

Result 1: Accessing OXID via DocumentRoot instead via alias does not help, still the two red squares appear.

Result 2: Even more reliable shutting down .htaccess does not help.

How to continue? Our experiments so far were done always on the same machine. We are running out of ideas. Next we will try it on other machines, and eventually not from the USB drive but from official installations of all components.

Downgrading PHP

(Session 20100325°1701)

Contacting the forum. The forums are found in the OXID eSales Community section at http://www.oxid-esales.com/forum .

Asking competent people was overdue. But posting a question at the OXID eSales forum requires some registering buerocracy, thus we delayed it.

The answer to our problem is overly simple, as you see in "Problem mit PHP "MySQL Modul für MySQL 5" [png pdf mht ].

Result: OXID does not run (yet) with PHP 5.3. Fine, we will downgrade our PHP from 5.3.2 to 5.2.13 (Subchapter PHP Setup Details - Downgrade PHP).

BTW. The forum runs on most modern Web 2.0 software. A tiny issue we have with the website: Printing a thread to PDF seems not to work correctly. E.g. PDF 20100325°1702 never shows page two. It prints as many pages as the thread were long, but each page is page one.

Succeed the OXID setup

(Session 20100327°0111)

Fine, we had managed the PHP downgrade. But since we are attempting this session first time with our USB drive on a new Windows station, we have to overcome two other issues, before the OXID work can begin.

(1) Overcome the issues with missing environment path to the USB PHP program folder. (Subchapter "PHP Setup Details - Make PHP run on any station")

(2) Overcome the collission of our usb MySQL instance with an instance already running on this station. (Subchapter "MySQL Setup Details - Collission with other MySQL instance")

State of the OXID start screen: only one red light, the Apache Rewrite Module. Since Apache says, this module is loaded, we choose the crowbar method (see above) to switch this light to green.

Now we successfully run the OXID setup procedure and end up in the Demo Shop. (We made the complete series of screenshots, but do not print it here.)

The OXID eShop Demo Shop
The OXID eShop Demo Shop.

The Demo Shop looks fine, but it has one serious issue: all links it it lead to Nirwana!

Should indeed the Apache Rewrite Engine be missing?! Well, Apache says, the module is loaded. When investigating the rewrite topic, in de.wikipedia.org/wiki/Rewrite-Engine (png pdf mht) we saw an interresting directive, which might be missing in httpd.conf:
RewriteEngine on

And there was a curious accident with the setup. During the setup, OXID is asking, whether it shall delete the setup directory after finishing. Unfortunately, we sayed yes. OXID of course deleted soundly: including the Subversion shadow directory .svn. What of course corrupted our workspace!

The setup folder, now completely empty, was a valid workspace folder before.
The setup folder, now completely empty, was a valid workspace folder before.

Deleting the setup folder corrupts the Subversion workspace.
Deleting the setup folder corrupts the Subversion workspace. Revert does not work in this situation.

Well, we busted the workspace, checked out a new one and repeated the setup, this time not letting delete the setup folder.

The Rewrite Module problem

(Session 20100328°0011)

The OXID Demo Shop shows its frontpage, but all links from there into the shop lead to nowhere. Apache says, mod_rewrite is loaded, but obviously it does not work. Remember, we overcame the OXID start screen only by the crowbar method shutting down the respective test.

First clues about the topic we fetch from the following OXID eSalses forum threads
-   htaccess und apache mod rewrite (png pdf mht)  
-   rewrite modul einstellen (png pdf mht)
-   Installationsmenü - Apache mod_rewrite Modul (png pdf mht) .
Sorrily, the mentioned rewrite-module-faq and a dedicated thread about how to switch it on seem not available anymores.

We reactivate .htaccess, which was shutdown for the very start. This seems to be a prerequisite, but it does not help.

From our first forum contact above, we remember the recommendation to call the page /admin/test.php. The result:

The page /admin/test.php says the rewrite module is switched off.
The page "/admin/test.php" says the rewrite module is switched off.

Again, the OXID eSales forum helps: check the value "RewriteBase /" in .htaccess (thread http://www.oxid-esales.com/forum/showthread.php?p=28199 [png pdf mht] . Then we try to learn what RewriteBase means exactly : http://de.selfhtml.org/servercgi/server/rewrite.htm [png pdf mht] .)

The "RewriteBase /" in .htaccess does not help. We tried it in all flavours. Anyway, the page "/admin/test.php" told us mod_rewrite_off. So it seems not to be about tuning the rewrite engine, but about how to switch it on at all.

We need to learn more about the rewrite enging: http://httpd.apache.org/docs/2.2/misc/rewriteguide.html [png pdf mht] . On the top of this chapter beckons an iteresting box:

ATTENTION: Depending on your server-configuration it can be necessary to slightly change the examples for your situation, e.g. adding the [PT] flag when additionally using mod_alias [png pdf mht] . On the top of this chapter beckons an iteresting box: and mod_userdir [png pdf mht] . On the top of this chapter beckons an iteresting box: , etc. Or rewriting a ruleset to fit in .htaccess context instead of per-server context. Always try to understand what a particular ruleset really does before you use it. It avoid problems.

Aha. We are using mod_alias! So what is the [PT] flag? This chapter explains it: httpd.apache.org/docs/2.4/rewrite/flags.html [png pdf mht] [This is no more online: png pdf mht] . About the [PF] flag, it says:

[PT] = passthrough. The target (or substitution string) in a RewriteRule is assumed to be a file path, by default. The use of the [PT] flag causes it to be treated as a URI instead. That is to say, the use of the [PT] flag causes the result of the RewriteRule to be passed back through URL mapping, so that location-based mappings, such as Alias, for example, might have a chance to take effect.

If, for example, you have an Alias for /icons, and have a RewriteRule pointing there, you should use the [PT] flag to ensure that the Alias is evaluated.

Alias /icons /usr/local/apache/icons
RewriteRule /pics/(.+)\.jpg /icons/$1.gif [PT]

Omission of the [PT] flag in this case will cause the Alias to be ignored, resulting in a 'File not found' error being returned.

(Session 20100405°1400)

We learned Apache rewriting outside of OXID. It worked when done in httpd.conf, but not when done inside .htaccess. Experiments with the Deny all directive showed, that .htaccess was not working at all.

We investigated forums and tutorials, e.g.: http://httpd.apache.org/docs/2.2/misc/rewriteguide.html (png pdf mht) , http://www.modrewrite.de (png pdf mht) , http://www.regexbuddy.com (png pdf mht) , http://www.selfphp.de/forum/showthread.php?t=20749 (png pdf mht) .

We found the solution at the beginning of http://httpd.apache.org/docs/2.2/howto/htaccess.html (png pdf mht) . The following line was missing in httpd.conf:

In the global section
AccessFileName .htaccess
and in the respective Directory section
AllowOverride None


(Session 20100410°2100)

To get a working installation for comparison with the not-working one, we install XAMPP parallel to the Gipsy Drive Apache. Only the problem continued: the XAMPP installation showed the exact same symptoms with Oxid, as so far the Gipsy-Apache.

But XAMPP contains first class and proofen configurations files, we now can compare with our selfmade configuration files. Such help at hand, we reviewed our configuration in depth ... and spotted the culprit:

The .htaccess contained the line <IfModule mod_rewrite>, which is wrong! It must read:
It must read:
either <IfModule rewrite_module>
or <IfModule mod_rewrite.c>,
but NOT <IfModule mod_rewrite>.

How could such nasty typo creep into the .htaccess file? It was by our lazy unobservance during the early debugging phase. We missed to restore an experimental change. The story is told in the Oxid Forum at www.oxid-esales.com/forum/showthread.php?p=29263.

Fine! Rewriting in the OXID .htaccess file works. We can go inside the Demo Shop.


Other interesting pointers

Article about OXID eShop module programming by Andreas Ziethen http://www.phpbuilder.com/columns/Andreas_Ziethen010710.php3 (20100331°1349 png pdf mht)

Thread lighttpd rewrite rules (png pdf mht)

Forum article with a different question (than PHP MySQL Module) but containing keywords worth to be inspected: Installation (png pdf mht)


Datenschutz Imprint

http://downtown.trilo.de/appsoxid.html © 2008 - 2018 Trilo Software e.K.   (20100825°2145)