|Dependencies||:||Apache, PHP, MySQL|
This shall become a sample webshop running from an USB drive, serving as a template to branch off customer projects. . . .
. . .
. . .
. . .
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.
Download OXID_ESHOP_CE_4.2.0_23610.zip from www.oxid-esales.com/en/download/open-source-ecommerce-solution-oxid-eshop-community-edition 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.
The little red squares tell, we have a problem with PHP's MySQL module and with the Apache rewrite module.
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/... . It is the -M option which can tell us what modules are loaded at runtime. Using it, we find the rewrite_module being loaded!
Apache says, it's rewrite module is loaded!. So why does OXID complain?
In php.ini, we find this sequence:
; Directory in which the loadable extensions (modules) reside.
; 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 , Datenbank neu anlegen , Dateien auf den Server kopieren , Setup aufrufen . 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 . 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 . But the solution was to use XAMPP. This is no solution for us.
This one OXID eSales forum thread seems more informative: MySQL Module . 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 " . => 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?
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.
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" containing interresting keywords:
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.
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!
At several places in the internet, a list of system requirements can be found. Let's put it here to explicitly work it off.
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 . For us an even better document seems Configuring Apache to Use PHP as CGI on Windows Systems .
To run PHP as CGI we make the following changes in httpd.conf:
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.
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:
Now PHP runs from C:\Programme\PHP. But the error in OXID's start screen stay the same.
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 "../htdocs" # ORIGINAL LINE, TEMPORARILY REPLACED
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.
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" .
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.
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 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,
we saw an interresting directive, which might be missing in httpd.conf:
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!
Well, we busted the workspace, checked out a new one and repeated the setup, this time not letting delete the setup folder.
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
- rewrite modul einstellen
- Installationsmenü - Apache mod_rewrite Modul .
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:
Again, the OXID eSales forum helps: check the value "RewriteBase /" in .htaccess (thread http://www.oxid-esales.com/forum/showthread.php?p=28199 . Then we try to learn what RewriteBase means exactly : http://de.selfhtml.org/servercgi/server/rewrite.htm .)
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 . 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 . On the top of this chapter beckons an iteresting box: and mod_userdir . 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 . 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
Omission of the [PT] flag in this case will cause the Alias to be ignored, resulting in a 'File not found' error being returned.
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 , http://www.modrewrite.de , http://www.regexbuddy.com , http://www.selfphp.de/forum/showthread.php?t=20749 .
We found the solution at the beginning of http://httpd.apache.org/docs/2.2/howto/htaccess.html . The following line was missing in httpd.conf:
In the global section
and in the respective Directory section
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.
Article about OXID eShop module programming by Andreas Ziethen http://www.phpbuilder.com/columns/Andreas_Ziethen010710.php3
Thread lighttpd rewrite rules
Forum article with a different question (than PHP MySQL Module) but containing keywords worth to be inspected: Installation
Imprint : www.trilo.de