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 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.
I have stashed here for your pleasure:
I ran into the first detour right in the midst of the download. Somehow I picked up oscommerce-2.2ms2.tar.gz which is version 2.2, milestone 2. It turns out this is the milestone 2 release from back in 2003 and was very much the WRONG thing to get. I spent about a day fiddling with this before I got pointed in the right direction by kind people on the forums, and you can read about my experiences with the 2003 release by following the link you just read through. It turns out there are plenty of issues with this newer and better package, so keep reading and pay attention.
Let's start over with the right thing, namely oscommerce-2.2ms2-051113.tgz which is from November of 2005 and is advertised to have PHP 5 fixes, vital bug and security fixes, and who knows what else, but certainly the proper starting point for a new install.
You can get a lot of help and information from oscommerce forums and they are an invaluable resource for anyone working with oscommerce.
The first business at hand (apart from having an apache server with PHP and having a website up and running) 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:
First of all, since I already had been playing with oscommerce and had a database that
I didn't care about in any way shape or form, I did this
(very dangerous and shockingly easy) to start fresh:
mysql
DROP DATABASE local_store;
\q
You can start from here if you didn't have a prior database to throw away:
mysql --user=root --password=bogus mysql CREATE DATABASE local_store; GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP on local_store.* to 'local_store'@'localhost' IDENTIFIED BY 'bogus2'; \q
I unpack the tarball into a handy place, created a directory I call oscommerce under my DocumentRoot and then copy the catalog directory (and all subdirectories) into that subdirectory. I have been warned that the install process will want to modify two files, so I need to change permissions (which I will later change back) to allow it to do so. Therefore I issue the commands:
cd ./oscommerce/catalog su chgrp -R apache . cd ./oscommerce/catalog/includes cp configure.php configure.php.ORIG chmod g+w configure.php cd ./oscommerce/catalog/admin/includes cp configure.php configure.php.ORIG chmod g+w configure.php
Doing this keeps ME as the owner of all the files so I can fiddle with them without hassle, and the group ownership by apache gives the web server access. Adding group write to the configure.php will let the oscommerce install (via apache) do whatever it wants. I don't see any reason to open up any directory write permissions at this point. Since I am curious I keep pristine copies of the unaltered files.
Then I fire up my browser and go to http://localhost/oscommerce/catalog/install
Bummer! Even with this latest version I am told I must enable register_globals in my /etc/php.ini file, but I know now there are patched files available (why they haven't made it into the latest distribution is anyones guess), so I am going to go that route.
You really have 3 choices at this point. The worst option would be to simple edit /etc/php.ini and issue the command service httpd restart I press on. This has security implications and I don't think any responsible web administrator in this day and age should be willing to consider doing this. The second option (and thanks to Vger on the forums for this trick), you put a line in a root level .htaccess file as follows:
php_flag_register_globals on
After this, apache will turn on register globals in PHP for just that part of the directory tree. The best is to patch oscommerce itself so it doesn't use this ancient PHP coding method, so that is what we will do.
First though, let us check into another PHP 5 issue I know about. We will get stuck at step 2 of the install unless we take care of this. I issue the command grep -r HTTP_GET_VAR ./catalog and discover that there is plenty of this (which will not work under PHP 5 without some fiddling with php.ini parameters. And there are also plenty of HTTP_POST_VAR references as well. This is all deprecated under PHP 5, but can be reenabled as a PHP legacy support feature by setting register_long_arrays = On in my /etc/php.ini file and restarting httpd (aka Apache). My book Upgrading to PHP 5 from O'Reilly has come in handy working all this out. This could be handled just for oscommerce via the .htaccess file trick mentioned above, but it doesn't have the security issues that register globals does, so I don't mind just editing php.ini.
OK, now I know I am going to face all the same issues I did with the 2003 package, so I roll up my sleeves and do all the dirty work I know about right now. I turn on register_long_arrays in my php.ini and restart apache. I dig out my own copy of the register globals patch file that kind Vger on the forum has put together and whack it in.
The affected files are:
./oscommerce/catalog/admin/products_attributes.php ./oscommerce/catalog/admin/includes/application_top.php ./oscommerce/catalog/admin/includes/functions/general.php ./oscommerce/catalog/admin/includes/functions/sessions.php ./oscommerce/catalog/includes/application_top.php ./oscommerce/catalog/includes/classes/order.php ./oscommerce/catalog/includes/functions/general.php ./oscommerce/catalog/includes/functions/gzip_compression.php ./oscommerce/catalog/includes/functions/sessions.php ./oscommerce/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;. See my 2003 release notes for more details on all of this. "Whacking it in" (on my system) means to do this:
cd ./oscommerce cp yadayada/oscommerce_rg_patch.tar.gz . tar xzvf oscommerce_rg_patch.tar.gz
Before I did this, I copied each affected file to yadayada.RG so I could do diffs later and see what this patch was fiddling with, but that is just because I am curious.
On to attempt number 2; I fire up my browser and go to http://localhost/oscommerce/catalog/install, voila! I am getting the first oscommerce screen asking me if I would like to install or upgrade; and I do not get stuck at step 2. As with the 2003 install, after I select SSL and verify that I like the website address and all, it cycles me back to the page to enter database name and password, but not to worry ... after that it announces things are complete and is offering to let me go to the store or the admin pages. The admin does not come up blank (this is good), and the store page comes up full size now (something new and good), but with a couple of warnings (and things I know I need to tidy up).
First off, I need to delete or rename the install directory. (just protecting it will still harvest funky warnings) What I will do is to rename and protect it as follows:
cd ./oscommerce/catalog mv install install.ORIG chmod 700 install
Also the two configuration files need to be made immutable:
cd oscommerce/catalog/includes chmod g-w configure.php cd oscommerce/catalog/admin/includes chmod g-w configure.php
While I am at it, I notice some directories that are wide open and clamp down on them:
cd oscommerce/catalog/admin/includes chmod 755 functions cd oscommerce/catalog/includes chmod 755 classes functions cd oscommerce/catalog chmod 755 admin includes
Now I do some recommended final fiddling:
cd oscommerce/catalog chmod g+w images cd oscommerce/catalog/admin mkdir backups chmod g+w backups cd oscommerce/catalog/admin/images chmod g+w graphs
I put an .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. If you are new to htaccess files, you may want to read my .htaccess file tutorial.
Now there are two ways to get at the oscommerce install I have just sweated my way through. There is the public entry point to the store (which looks just fine) at:
http://localhost/oscommerce/catalog
The administrative entry point (which also looks fine) is:
http://localhost/oscommerce/catalog/admin
Looks good, now to figure out how to use it!!
Adventures in Computing / [email protected]