Night Blue Fruit Development Blog » PHP

The pain of Drupal

admin — Sat, 05 Dec 2009 11:14:01 +0000

I’ve recently taken on a job that requires modification of a web site built on Drupal, and 3 days in, I feel like I need a 2 week holiday.

Drupal, and its counterpart, Joomla, are Open Source Content Management systems. The idea is that the allow people who don’t know anything about HTML, PHP, Javascript etc etc to build complex, feature rich websites.

Their use on the web has exploded over recent years, as more and more would be ‘web designers’ have started using them as their framework for building websites.

This in turn as led to the development of lots and lots of Drupal plugins and widgets, which add a futher layer of fudge and complexity to something that is already very fudgy and very complex.

Under the hood, its a morass.

Before starting work on the modifications I had to make, I took a look at the MySQL database on which is runs. It had 288 tables (my own CMS has 12 tables, and even poor old Wordpress only has about 40 tables).

If that wasn’t bad enough, when I then tried to run a local copy of the website on my laptop, I started to get errors about PHP not having enough memory to run the Drupal scripts. PHP is normally allocated about 16MB of memory as part of its installation; to run Drupal, I had to up this to 64MB!!

Its gets worse. Looking at the raw HTML generated by Drupal, I saw that it was loading 25 different CSS files, and 14 different Javascript files! And when I examined the DOM via Firebug, I could see that certain elements were taking CSS properties from up to 4 different files!

All this was bad enough, but it was nothing comparred to actually using the management interface to build content. The admin menu in Drupal has 14 different options, and each of these has a plethora of sub options, all of which refer to vague concepts like Blocks, Views, Modules, Panels, Stories etc (they also refer to a Page, but its isn’t really clear what a Page is).

My first thought was that it would be actually easier to learn HTML, PHP and Javascript than try and unravel this crap.

I persevered anyway. I made a view changes to pages where I could figure how to make those changes, but none of them appeared on the actual website. This was most probably to do with caching I thought, but there was nothing in the Drupal interface that said ‘You should clear your cache to see these changes’. I also thought it was quite odd that an app that generates links to 40 odd CSS and Javascript files should be worried about caching.

I looked around for somewhere I could clear the cache, but could find nothing. I eventually googled the subject and found that the clear cache was a sub sub option under the ‘Site Configuration’ menu option.

On another occasion, I had to change some User Permissions. When I clicked on the Save button, my laptop started to grind to the extent that I thought it was going to shut itself down to prevent an explosion.

Perhaps my most stressful experience with Drupal was dealing with this bug. There are 300 posts on the Drupal Forum thread on this bug, and the upshot of it isn’t there isn’t a universal solution. You basically have to figure out what version of a few different modules you are using, and then apply a serious of patches which may or may not break other parts of your installation.

Lets try and use an analogy here.

Building a website with Joomla is like trying to build a house by joining together five or six mobile homes. Its cheap, it doesn’t take long to put together and it seems like a easy solution to a pressing problem.

What you get is something that is about the same size as a house, and that has certain features of house (eg windows and doors), but that also has 5 bathrooms, 5 kitchens, no corridors and no rooms of any useful size. You also need 5 different electricty meters, and in certain cases, if you want to walk from one room to another, you have to leave house and come in through another door.

Also, if you want to make even minor modifications to the look of your house in future, you have to take the whole thing apart and stick it back together again.

Don’t get me wrong. Open source packages like Drupal are essential part of the Internet, but its becoming clear that the more an application tries to be a solution for everything, the more likely it is to become a solution for nothing.

Refreshing an image when filename is the same

admin — Wed, 19 Sep 2007 22:48:04 +0000

Here’s a nifty little trick that might get you out of a bind:

Say you have a web app in which the user can change the images by uploading new image files. Say then that the application requires that the image filename remain the same. See the problem?

The image may have changed but your browser is still looking at the same filename, so it will display its cached image. Of course, you could try an edit your HTML to that caching doesn’t occur, but we like caching, so here’s a better solution.

An image file, like a script file, can accept an argument when requested with HTTP. For instance, the image below is requested so:

The cool thing about this is that you attach random arguments to your image calls, either in HTML or in Javascript, which will cause the browser to reload that image every time it is called. Hence, when your user loads a new image, and this image has the same file name as the old image, this method will allow the user to view the new image without having to do a manual refresh.

In Javascript, you can create a random argument using time and date functions. e.g.

my_image.src=”images/pottery.jpg?” + (new Date()).getTime();

image_td.innerHTML = “”;

Managing images with GD

admin — Wed, 12 Sep 2007 22:18:34 +0000

One of the biggest problems I find with Content Management Systems is that while users are capable of managing web site text, the results are a little less predictable when it comes to managing images.

There are 2 primary problems:

Firstly, a lot of users aren’t comfortable with scaling images to fit into the spaces designed for them, and secondly, if you allow for this and use the IMG tag to scale the height and width of the image, you get fuzzy distorted images and large files that take an age to load in the browser.

This is why programatically manipulating uploaded images is such a good idea.

There are 2 tools you can use to manipulate images in PHP: GD or ImageMagick

GD is more commonly found in PHP compiles, and ImageMagick can be difficult to install correctly, so lets stick with GD for this discussion.

The problem I faced was this:

I wanted users to be able to upload long images, tall images and square images, but I wanted these to fit into a space 214px x 214px on a website page without having to use the IMG height and width tags.

This meant a 2 step process for the long and tall images: first, resize them so that they were with 214px tall or wide, and then crop them so that they were both 214px tall and 214px wide. I also wanted to make sure I was cropping down to the middle portion of the image, so that I was getting what the user wanted to appear and not the top, bottom or side of the image. The task for square images was a little simpler, in that I only had to resize the image (no cropping).

The PHP function I created is produced here. I’ve added inline comments to explain.

#Arguments = source image file, altered image file, required dimesions of altered image

function resize_image($src_image,$dst_image,$xsize,$ysize)
{

list($w,$h) = getimagesize($src_image);

#Deals with images that are wider than they are tall

if ($w > $h) {

#First, resize the image so that 1 side is the required length
$new_height = $ysize;
$new_width = ($ysize / $h) * $w;

$x=$w;
$y=$h;

#Resized temp image

$temp_image = “images/” . date(”U”) . “.jpg”;

$image = imagecreatefromjpeg($src_image);
$crop = imagecreatetruecolor($new_width,$new_height);
imagecopyresized ($crop, $image, 0, 0, 0, 0, $new_width, $new_height, $w, $h);
imagejpeg($crop,$temp_image,100);

# Now use temp image to create final image

list($w,$h) = getimagesize($temp_image);

if ($h >= $ysize) $new_height = $ysize;
if ($h <= $ysize) $new_height = $h;
$new_width = $ysize;

#This bit sets the dimensions for the middle of the image
$x = ($w – $ysize) / 2;
$y = 0;

$image = imagecreatefromjpeg($temp_image);
$crop = imagecreatetruecolor($new_width,$new_height);
imagecopy ($crop, $image, 0, 0, $x, $y, $new_width, $new_height);

#As above but for images that are taller than they are wide

} elseif ($h > $w) {

$new_width = $xsize;
$new_height = ($xsize / $w) * $h;

$x=$w;
$y=$h;

$temp_image = “images/shops/” . date(”U”) . “.jpg”;

list($w,$h) = getimagesize($temp_image);

if ($w >= $xsize) $new_width = $xsize;
if ($w <= $xsize) $new_width = $w;
$new_height = $xsize;
$y = ($h – $xsize) / 2;
$x = 0;

$image = imagecreatefromjpeg($temp_image);
$crop = imagecreatetruecolor($new_width,$new_height);
imagecopy ($crop, $image, 0, 0, $x, $y, $new_width, $new_height);

#Square image; no need for cropping
} elseif ($h == $w) {

$new_width = $xsize;
$new_height = $ysize;

$x=$w;
$y=$h;

$image = imagecreatefromjpeg($src_image);
$crop = imagecreatetruecolor($new_width,$new_height);
imagecopyresized ($crop, $image, 0, 0, 0, 0, $new_width, $new_height, $w, $h);

}

#Save the new images and discard any temporary images
imagejpeg($crop,$dst_image,100);
imagedestroy($image);
}

Here’s an example:

This is the original image resized with IMG tags:

And here is the programatically manipulated image without any IMG tags:

phpBB Robotic Registrations

admin — Tue, 21 Aug 2007 21:10:21 +0000

Preventing robots from posting on a phpBB forum is easy enough if your prospective users are content to wait for an administrator to moderate the registration, but that isn’t going to suit everybody.

Requiring moderation on the part of the administrator is also a pain for the administrator, who has to deal with the registration emails and decide who is real person and who is not.

I came across this problem for http://www.planningmatters.ie/pmbb

When you first become aware of the problem, your impulse reaction is to head off to Google for a tried and tested solution, but the problem is that once a solution gains any currency, the robot authors figure it out and you’re back to square one again.

My first solution was to edit the email that is sent to users awaiting activation, asking them to forward that email back to me to confirm they were a real person. I also set up a cron job to run an SQL script to delete non-activated users from the database, deeming that any user who had not been activated 7 days after initial registration to be a robotic user.

This isn’t ideal in that it requires an extra step for users, but it does mean that real users get through, and that your database is kept in shape.

However, I was still getting floods of email from attempted robotic registrations, so I set about editing the registration script (includes/usercp_register.php).

This script processes registrations based on whether or not the user has agreed to the disclaimer on the primary registration page. I set an extra PHP $_GET variable as part of the disclaimer agreement, and amended the later part of the script to check for that variable before processing the registration. I also set the extra variable equal to date(”DG”) which means that the variable changes every hour. You can see this by examining the discliamer links here:

http://www.planningmatters.ie/pmbb/profile.php?mode=register

The fact that the extra variable is not part of the standard phpBB install will ward off a lot of dumber robots, and the fact that it changes will ward off some smarter ones too. However, there are still a lot of robots out there that are clever enough to detect the verification method, so I was still getting some SPAM registrations.

To clear off the final few robots I knew I was going to have to involve the intellect of real users, in that this is probably the only thing that robots can’t replicate. Hence, I decided to add a really simple, but real, question to the registration page. To do this I edited the following file under the default template:

templates/subSilver/profile_add_body.tpl

I inserted the following extra lines of HTML underneath the Visual Confirmation section:

What is the day today?
We ask this question to prevent SPAM registrations. SPAM robots won’t know the answer.

This adds the following question to the registration form:

“What is the day today?”

The answer to which 99.999% of real users on the forum will know.

To check the answer, I then added an extra line to the top of the main registration script:

includes/usercp_register.php

The line I added is:

//ANTI-SPAM DEVICE
if (isset($HTTP_POST_VARS['day_today']) and strtolower($HTTP_POST_VARS['day_today']) != strtolower(date(”l”))) die();

This basically ensures that the answer to the question is the same as the day produced by the date() function (case insensitive) and if its not, the script dies.

Previous to adding this, and even with the other changes, I was getting about 20 robot registrations per day. After adding this, it dropped to about 10 per day, so there was still some work to do.

Finally, Occams Razor came to the rescue. I found out that the robots trawl for the “profile.php” script and the “mode=register” URI, so I set about trying to change these.

They need to be changed in:

includes/page_header.php

includes/usercp_register.php

(remembering of course to rename the file profile.php too)

I changed mine to:

profile.php -> pmatters.php

mode=register -> mode=signupuser

Now, FINALLY, I have stopped getting robotic registrations!!