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.

WordPress blogs subject of another round of hacking attacks

I was contacted yesterday by a friend who wanted some changes made to his website. First thing I happened to notice when I went to take a look at the site in question is that my security software started throwing up some alerts about blocking access to a potentially malicious site.

Confident that my friend’s site doesn’t usually qualify for that description I did some digging and discovered that every time I accessed a page on his site, it was attempting to contact an internet address that is registered to an address in Latvia. Looking at the source for the site, there was some JavaScript that appeared on the end of each page that referred to a site called meqashoppinginfo and called a script called js.php.

As far as I can tell the attackers targeted sites with WordPress Blogs on shared hosting providers (most SME websites are hosted in this way) and using WordPress as the point of entry will have gone on to infect any php pages hosted by that site.

Having cleaned my friends site manually (and deleted his WP blog as he isn’t currently using it anyway) and reported the issue to his hosting company, I have received an update from my hosting company as shown below:

Security warning for websites using WordPress

We’ve been made aware of a security issue facing websites using WordPress. We take security very seriously at 123-reg, so we want to check if this matter has affected your site.

If you use the blogging platform WordPress on your web hosting, you may have been the victim of a security hack (please ignore this email if you haven’t installed WordPress on your hosting).

The problem is due to a security breach caused by hackers, who have targeted sites that use WordPress. WordPress is an open source application, making it vulnerable to such attacks.

As your hosting provider, we want to help you counter this WordPress hack as quickly and as effectively as possible. To do so, please follow these simple steps as soon as you can:

1. Run a simple cleanup script
If your WordPress site has been hacked, you will need to run this
simple cleanup solution script (written to defeat this WordPress hack).
2. Scan your local machine
Run a full anti-virus scan on the local PC from which you administer
your WordPress account.
3. Change all your user passwords
Change any user passwords for WordPress account, your FTP
account and MySQL account.
4. Change your secret keys
If hackers have stolen your password they may remain logged into
your WordPress account until you have changed your secret keys.

Visit the WordPress key generator to obtain a new random set of keys.

Then overwrite your secret keys wp-config.php file with the new ones.
This will disable the hacker’s connection.

5. Take a backup of your WordPress files
Backup all of your WordPress files to your local PC (label them as
‘hacked site backup). You can then investigate these files later.

That should do the trick!

If you have been affected by the WordPress hack, we’re sure that the above steps will completey eradicate the problem – allowing your website to function as before.

We’d like to stress that this WordPress hack bears no relation to the security of your 123-reg web hosting itself. This remains robust and very well protected from any attacks by hackers.

Having used the script on another infected site, I can confirm that it is simple and use and works effectively.

This episode re-iterates the importance of:

  • Make sure your passwords (blog admin, FTP etc) are strong passwords and are changed regularly
  • Keep your software up to date, hackers often make use of known bugs in older versions that are now fixed
  • Install anti-malware software on your PC and check your site regularly – this is what alerted me to the problem