If you are reading here, you may want to just go to my experiences with the more recent release from November 2005. This page documents my false start with the 2003 milestone 2 release, but it turns out is not that much different from issues you will face with the 2005 release.
It is March of 2006 and I have decided once again to have a go at setting up OS commerce on my apache server. I am running on a Fedora Core 4 linux machine. I am running Apache 2.0.54, PHP 5.0.4, and MySQL 4.1.16. I have gone to the OScommerce web site and picked up what looks like their latest release, namely oscommerce-2.2ms2.tar.gz which is version 2.2, milestone 2. It turns out this is the WRONG thing, because I go back a day later and get oscommerce-2.2ms2-051113.tgz which is from November of 2005 and is advertised to have PHP 5 fixes, vital bug and security fixes. I do not know and may never know how I got the old 2003 package, but it cost me a fair bit of time.... consider yourself warned.
All of what follows pertains to the 2003 package I mistakenly grabbed.
The only place I find recent action (later than 2003) is the oscommerce forums.
The first business at hand is that you need to have mysql running and have a database and user with password set up for Oscommerce to find and configure for itself. If you are new to MySQL (as I was a year ago when I started this business and gave up on it), this in itself can be a daunting task. One solution is to set up and use phpMyadmin, which affords a GUI front end to MySQL administration. This is a tangle of its own to accomplish, so I am just using the basic MySQL command line tools as described below. If you are doing this on an ISP, you may be offered their own GUI interface, or you may have to have them set up a MySQL database for you, but anyway here is what I did:
mysqladmin create local_store
mysql --user=root --password=bogus mysql
GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP on local_store.* to 'local_store'@'localhost' IDENTIFIED BY 'bogus2';
\q
I unpack the tarball into my DocumentRoot and make a symbolic link of oscommerce --> oscommerce-2.2ms2
Then I fire up my browser and go to http://localhost/oscommerce/catalog/install
Horror of horrors! I am told I must enable register_globals in my /etc/php.ini file. I reluctantly do so and remember getting to this point almost a year ago and being thoroughly disgusted, hoping when I got back to this again the developers would have this patched up (sorry!!). It turns out this is all worked out, but you have to roam around on the forums to find the goodies, see below.
I do some reading on the OScommerce forums, and am told I need to monkey with file permissions to allow the install to work. On my system anyway, the web server runs as user apache and will try to access files as that user, so what I do is this:
chgrp -R apache oscommerce
chmod 755 oscommerce
chmod 755 oscommerce/catalog
chmod 755 oscommerce/extras
And so on for all the directories in the oscommerce structure. Also I have been warned that the install procedure will want to monkey with two files:
cd oscommerce/catalog/includes
chmod 775 configure.php
cd oscommerce/catalog/admin/includes
chmod 775 configure.php
I try again to launch the install and I get stuck forever on the New Installation page. Now I get to dig into the code (which I learn some nice tricks from) and discover that the GET variable 'step' is never making it into the code via HTTP_GET_VARS. This turns out to be a deprecated legacy PHP trick (kinda like register_globals, but without the security issues), that I can reenable via register_long_arrays in my /etc/php.ini file. (My book Upgrading to PHP 5 from O'Reilly comes in handy at this point). I need to figure out how to have a special section in my php.ini for the ugly OScommerce tricks I have to activate. Thanks to Vger for this trick, you just put a line in a root level .htaccess file as follows:
php_flag_register_globals on
However, what I actually do is to edit /etc/php.ini and do:
service httpd restart
OK, now the install goes on to the next section where I insert my server name (localhost), username, password, database name, and enable persistent connections and session storage on the database. The database import goes cleanly (now we are finally moving along). After I type in the server path information and enable SSL connections, we loop back to the New Installation page (looks like trouble again). I go back and monkey with permissions on catalog/includes/configure.php and we get to the step=7 successful install page (whew!).
There is more to do as per the install document. First off they suggest renaming or deleting the install directory, but I do this (oscommerce whines if all I do is make this unreadable):
cd oscommerce/catalog
chmod 700 install
mv install install.ORIG
And they suggest making the configuration directory read only:
cd oscommerce/catalog/includes
chmod 644 configure.php
cd oscommerce/catalog/admin/includes
chmod 644 configure.php
And they suggest some other permission fiddling (I am not quite so permissive as they are with 777 mode, since I expect only the apache user and group to be accessing any of these files).
cd oscommerce/catalog
chmod 775 images
cd oscommerce/catalog/admin
mkdir backups
chmod 775 backups
cd oscommerce/catalog/admin/images
chmod g+w graphs
And I put a .htaccess file in the top level for now (in the oscommerce/catalog directory), but when I go on the air with this, I will need to move it into oscommerce/catalog/admin.
Now there are two ways to get at whatever it is I have. The public entry point to the store (which looks just fine) is:
http://localhost/oscommerce/catalog
The administrative entry point (which now comes up all blank) is:
http://localhost/oscommerce/catalog/admin
I've been poking around in the forums. First of all I am not the only person who gets a blank admin page (but no explanation or fix as yet). Also I find that there are a set of "patch files" supplied by Rhea Anthony (Vger) and last updated August 2005. This is nice. I have them here: oscommerce_rg_patch.tar.gz as a compressed tar file. Vger might have the email address admin@terranetwork.net, and she credits the work originally to a Richard Bentley. Note that these are not patch files in the unix sense, but a subset of files to replace the files by the same name in the milestone 2 distribution.
The affected files are:
./catalog/admin/products_attributes.php ./catalog/admin/includes/application_top.php ./catalog/admin/includes/functions/general.php ./catalog/admin/includes/functions/sessions.php ./catalog/includes/application_top.php ./catalog/includes/classes/order.php ./catalog/includes/functions/general.php ./catalog/includes/functions/gzip_compression.php ./catalog/includes/functions/sessions.php ./catalog/install/includes/application.php
Both sessions.php files in the above list have been hand edited (as described in the note "link_session_variable.txt") to set the variable $nothing=0;.
The forums (and in particular Rhea Anthony aka "Vger") are proving to be lifesavers. My blank screen admin problem is a known PHP 5 issue fixed by editing catalog/admin/includes/classes/upload.php and changing line 31 as follows:
// $this = null; unset($this);
Yep!! This does the trick and I am now running without any register_globals hackery.
Cool, I can go home today feeling good about the world. My hat is off to Vger.
Adventures in Computing / tom@mmto.org