Adding dynamic connection details in DreamWeaver and/or CartWeaver using PHP

I have lost count of the times I have worked on a website using my local webserver/mySQL database, uploaded it to a remote host (whether live or testing) and found that nothing worked, before realising that I hadn’t updated the database connection properties meaning that the application is still using my local settings.

To get around this problem I now use a PHP driven conditional set of database connection settings, that will work on both my local set-up and the remote host.

A standard dreamweaver connection file e.g. Connections/conndb.php might look something like this:

$hostname_conndb = "localhost";
$database_conndb = "test_db";
$username_conndb = "test_user";
$password_conndb = "test_password";
$conndb = mysql_pconnect($hostname_conndb, $username_conndb,
$password_conndb) or trigger_error(mysql_error(),E_USER_ERROR);

Knowing that the remote host is called something like example.com I now construct a conditional state to check the name of the server hosting the site and then sets the connection parameters based on this check e.g.

$requesturi = $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
$remote = strpos($requesturi, "example.com");
if ($remote === false)
{
$hostname_conndb = "localhost";
$database_conndb = "test_db";
$username_conndb = "test_user";
$password_conndb = "test_password";
} else
{
$hostname_conndb = "remote-host";
$database_conndb = "remote-db";
$username_conndb = "remote-user";
$password_conndb = "remote-password";
}
$conndb = mysql_pconnect($hostname_conndb, $username_conndb, $password_conndb) or trigger_error(mysql_error(),E_USER_ERROR);

Line 1 uses the PHP array that contains details about the server environment to get the Host name and the Requested URI to populate a variable that holds the URL that was requested by the user.

Line 2 checks for the existence of the remote server name (in this case example.com) within the requested URI and sets $remote to the position that this is found. In reality I am not interested in where it is found, only whether it is found.

Line 3 checks to see if the remote server name was found. it is important to use “===” rather than “==”, as if the remote host name is found in the first position of the URL PHP considers this to be position zero (PHP starts most of its numbering from zero rather than one). Finding example.com in the first position of the string would set $remote to zero, and this would cause it to satisfy $remote == false, which is not what we want. Using “===” checks to see if the values are identical rather than equal. As zero is considered to represent false, zero equals false, but is not identical to it.

If it finds that the remote server name is not found within the server variable, it used the conditional statement to set the variables to reflect the local installation of the database, whereas if it is found it uses the else clause to set the remote parameters .

This enables me to set the connection file once, and not worry about changing it or maintaining two unsynchronised copies on the local and remote hosts.

I also use CartWeaver eCommerce software, which maintains its own connection details in a file called application.php and will set variables similar to this:

$cwGlobalSettings->hostname = "localhost";
$cwGlobalSettings->database = "test_db";
$cwGlobalSettings->databaseUsername = "test_user";
$cwGlobalSettings->databasePassword = "test_password";

The exact same approach can also be used in CartWeaver to avoid having to update this file everytime you wannt to transfer it between your local environment and the remote host e.g.

$requesturi = $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'];
$remote = strpos($requesturi, "example.com");
if ($remote === false)
{
$cwGlobalSettings->hostname = "localhost";
$cwGlobalSettings->database = "test_db";
$cwGlobalSettings->databaseUsername = "test_user";
$cwGlobalSettings->databasePassword = "test_password";
} else
{
$cwGlobalSettings->hostname = "remote-host";
$cwGlobalSettings->database = "remote-db";
$cwGlobalSettings->databaseUsername = "remote-user";
$cwGlobalSettings->databasePassword = "remote-password";
}

Installing and configuring Zenphoto – a personal view

I recently had a requirement for a photo gallery for use on a client’s website, where they could create galleries, upload photos, add titles, and make this available to the users of the site. I originally built it using a php gallery that ticked all the boxes, it had a built in loader, allowed for password restricted access to load and manage the galleries, was easy to use, attractive to look at, made use of light box style viewing. Unfortunately after a couple of weeks of use it started to report some php memory errors, and despite my best attempts to resolve this both individually and with support calls to the authors I was unable to get it to remain stable without rebooting the server – something that is almost impossible in a shared hosting environment. Moving host may have been a solution, but for various reasons it wasn’t a viable option so I needed to find an alternative gallery.
I lost count of the number of php based galleries that I downloaded and played with – most were unsuitable as they didn’t offer user security, have an inbuilt up loader, were difficult to incorporate into the look of the existing site, or were just plain ugly!
During the search I came across Zenphoto and liked what I saw, so I proceeded to downloaded Zen to my local development PC and extracted the contents. The contents were then copied to the gallery folder within my local copy of the client’s site and I used Dreamweaver to effortlessly load these up onto the webserver.
A few minutes later the necessary files were uploaded and I could commence setting up Zenphoto on the existing site. I didn’t need to worry about creating a MySQL database as the site already was using one as the backend for its CMS, so I would just need to pass the relevant details to the Zen setup screens.
Firing up Zenphoto’s setup screen I was initially confronted with a setup screen in which much of the dialog was in Chinese! I suspect that this is in part down the hosting environment the client uses, as I didn’t see this behaviour on my test site which uses a different host.

Scrolling down to the bottom I was able to change the language and but ended up with a php error and warning shown below.

Warning: require_once(/homepages/20/d192925432/htdocs/gallery/zp-core/setup/lib-htmlawed.php) [function.require-once]: failed to open stream: No such file or directory in /homepages/20/d192925432/htdocs/gallery/zp-core/setup/setup-primitive.php on line 70

Fatal error: require_once() [function.require]: Failed opening required ‘/homepages/20/d192925432/htdocs/gallery/zp-core/setup/lib-htmlawed.php’ (include_path=’.:/usr/lib/php5′) in /homepages/20/d192925432/htdocs/gallery/zp-core/setup/setup-primitive.php on line 70

Checking the files in both the webserver and my local copy I could find no trace of lib-htmlawed.php in the setup folder, there was however a copy in zp-core. I duly copied this file into the setup directory and loaded it onto the server. Refreshing the page now brought me up an English version so onwards with the installation.
After setting the database parameters I had a few warnings left, but these didn’t look like they should cause me any major issues. I also received a warning about an extra copy of the lib-htmlawed.php file I copied onto the server. I decided not to delete it for now.

Hitting Go, the installation proceeded with the creation of the MySQL tables which went without any issues and I deleted the setup files including the extra file I had loaded up.

Proceeding to the admin username and password setup screen (shown below) I duly setup the admin user and password

Which then took me to the logon screen, where I entered the new admin details to log into the administration console

Heading to the options tab there were various options to set across a range of sub-tabs.
On the general tab I set the time zone, language settings and the preferred date format. Other than setting the name of the Gallery and website details on the Gallery sub tab, I left all the other options at their default values.


10 minutes later I had uploaded a bunch of images, set the titles and had an operational gallery. All in all, it was a pretty smooth setup with one notable exception although this was pretty easily resolved.
I now have Zenphoto up and running and all seems stable. I have also integratd ZenPhoto to fit with the existing look of the site following the template tutorial I found on the Zenphoto site http://www.zenphoto.org/2010/08/theming-tutorial/. The only challenge I had was replacing the Zen gallery homepage with a page served by the CMS system that provides the site’s content.
So far, so good – my initial views on Zenphoto are positive, the user front end and the admin back end both are clearly designed with ease of use in mind, they are polished and professional looking and are fairly self-explanatory.

Over the coming weeks I intend to dig further into the Zenphoto templates – I am sure that what I could have done what I have done in a neater fashion, but on this occasion the priority was to get a replacement solution in place for the client to avoid the issues they were currently experiencing.