Reset your CSS

css_logo

I had an issue with CSS today and it was difficult to figure out what exactly what was going wrong. A great way to avoid this is to reset everything before you start.

A good way to do this is to use a preset reset such as the Yahoo UI reset or the Eric Meyer reset.

While these resets are very comprehensive often it feels like you reset everything, only to then redefine a lot of properties on the elements. Eric Meyer recommends that you should not just take his reset stylesheet and drop it in your projects if there is a more effective way of using it. Tweak it. Build upon it. Customise, and make it your own.

Perhaps it could be something as simple as removing padding from the elements:
html, body, div, h1, h2, h3, h4, h5, h6, ul, ol, dl, li, dt, dd, p, blockquote, pre, form, fieldset, table, th, td { margin: 0; padding: 0; }

MySQL PHP & UTF-8

mysql_logo

Its been a while but I was getting characters like £ instead of £ (for example) and it took a quick refresher to realise what was going on. A fantastic background reading is available here.

So what is going on?
UTF-8 uses one or more 8-bit bytes to store a single character, whereas ASCII for example uses only one byte per character. This makes it more space-efficient than UTF-16 or UTF-32 as the majority of characters can be single byte encoded but with the added benefit that you can store any character, – should you need to. It uses the most significant bits of each byte as continuation bits (to signify that the following byte(s) form part of the same character) and it this is the reason that improperly displayed UTF-8 results in weird characters.

OK, enough history, – lets just fix it!
The solution is to make sure you set the character set correctly with a Content-type header.

Content-type: text/html; charset=utf-8
<meta http-equiv="content-type" content="text/html; charset=utf-8">

So now that we are ready to store UTF-8 data we store some rows of data and output to the browser looks fine. However, is it really?

MySQL needs to know the character set of the data sent to it in your queries. The default connection character set is ISO 8859-1 (latin1) — treating all your supplied data as if it was ISO 8859-1, which is then automatically converted to the underlying character set of the column (UTF-8 in our case). Taking our earlier example this means that the two-byte pound sign is perceived as two ISO 8859-1 characters: Â and £. MySQL will then encode these characters separately as UTF-8 requiring 2 bytes each – double encoding as we use 4 bytes to store a single pound character! When selecting data from the table, the reverse occurs when MySQL converts the UTF-8 back into ISO 8859-1 and the browser (correctly) interprets the two bytes as a pound sign. The problem here is that while everything looks correct it is needlessly using extra storage space and CPU cycles in the conversion.

It’s very simple to change the connection character set and avoid these overheads. The query “SET NAMES ‘utf8′” instructs MySQL to treat incoming data as UTF-8, which can be directly inserted into columns with a matching charset. In practice you may issue this query after initialising your connection to the MySQL server so all future communication will be in UTF-8.

One major problem occurs when you have a table full of double-encoded UTF-8 text because it was inserted before you knew about changing the connection character set. If you then add in the extra “SET NAMES” query and output the retrieved text to a browser you will notice all the extra characters have crept in.

You may be tempted to be selective about where you use SET NAMES ‘utf8’ however it is fairly simple to modify all of the data in place and end up with clean tables. Here is some pseudocode that pulls valid UTF-8 from the table and reinserts it after switching the connection charset:

SET NAMES 'latin1';
SELECT id, col1, col2, col3, col4 FROM table;
SET NAMES 'utf8';
for each row
INSERT INTO table (col1, col2, col3, col4) VALUES (, , , ) WHERE id = ;

Backing Up WordPress

wordpress_logo

This plugin for WordPress can be set to automatically email your database or backup to a file according a set schedule. The homepage for the plugin is here

I cannot stress enough the importance of regular backups. In the event that your website becomes comprimised you can always retrieve a known good backup to get up an running again (after the vulnerabilty is made secure obviously) At Boolean we believe is is much better to be safe than sorry.

Using isset() instead of strlen()

php-logo

When you treat strings as an array, each character contained in the string is actually an element in that array. By determining whether an element exists you can determine whether the string is at least that many characters long. (Obviously the first character is element 0, so $username[7] is actually the eighth character in $username.)

This is slightly faster than strlen() however the reason is somewhat more complicated. Essentially whilst strlen() is a function, isset() is actually a language construct. Calling a function is generally more expensive than using a construct.

Replace text with an image using CSS

css_logo

A quick little way to do this (whilst still degrading and being kind to screen readers)

h1 {
text-indent:-9999px;
background:url("heading.jpg") no-repeat;
width:100px;
height:50px;

How it works: text-indent:-9999px; relocates the text title off screen, replacing it by an image declared by background: {…} utilising a fixed width and height.

Determining PHP script execution time

php-logo

Today I needed to quickly determine how long a script was taking to execute. Whilst a dedicated class could offer a lot more (including milestones) I needed something to do a quick ‘sanity check’ on a script. Heres how I did it:

function determinetime_float()
{
list($utime, $time) = explode(” “, microtime());
return ((float)$utime + (float)$time);
}

$script_start = determinetime_float();

Put the above at the top of your page, and put the below at the bottom of your page:

$script_end = determinetime_float();
echo “PHP script executed in “.bcsub($script_end, $script_start, 4).” seconds.”;

So, – whats happening?
PHP’s microtime() function gives the current timestamp in microseconds (we need this level of precision for script execution time). However microtime() returns a value like 796374521.15534500, when what we really want is 0.15534500 796374521 (The 0 is removed from the decimal section and added on to the integer). We use the above function to take care of this.

PHP5 date() Function

php-logo

Whilst migrating a clients website to a new server today I came across an unexpected error:

Strict Standards: date() function.date: It is not safe to rely on the system’s timezone settings. Please use the date.timezone setting, the TZ environment variable or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. (etc)

Well, if you are on shared hosting you most likely do not have access to the php.ini file in order to set the timezone.
Instead head along to your .htaccess file and add the folllowing line:
php_value date.timezone [your_zone] where [your_zone] is found from the link here