Not everyone is happy with this new feature. Here is the way to disable it for project:

Open functions.php and add:

// Disable admin-bar from showing on your blog
wp_deregister_script('admin-bar');
wp_deregister_style('admin-bar');
remove_action('wp_footer','wp_admin_bar_render',1000);

Example:

textarea {
	resize: none;
}

I know this can be an usability thing for Chrome and Firefox users, but I think when you make your textarea large enough there should be no problem at all.

Facebook Login (previously Connect)

This method is used by external websites, offering their visitors an easy method of registration and login, using their Facebook account. As shown in the example code provided with the SDK, we first create an instance of the facebook class, which we use to retreive a session.

We will not find a session in two cases:

1. The visitor has not authorised the website in the past
2. The method getSession() cannot find the signed_request or session variable in the $_COOKIE or $_REQUEST variables

To be sure that the visitor has not authorised your application in the past, we transfer the visitor to Facebook using the method getLoginStatusUrl(). This will header the visitor to Facebook, which in turn headers the visitor back to the referring URL including a $_REQUEST['session'] variable, if the visitor has indeed authorised in the past. Be sure to build in a check to only check this once a session, otherwise this will result in a loop if the user is unknown.

Canvas

When using Facebook Canvas (a website iframed within Facebook), the requested page within the iframe is always provided a signed_request which the SDK uses to build a “session”. This means that we always know whether the visitor is an authorised user or not, making the  getLoginStatusUrl() superfluous. If we can’t find a session (getSession()), or we can’t find “/me“, the user has not authorised and we need to present the authorisation button.

The following graphic depicts the flow for both cases:

Of course, the above can also be established with the Javascript SDK, but a little dedudancy won’t do any harm. And the getLoginStatusUrl method is probably a lot quicker than the JS variant.

How can you safely redirect web site traffic from your old pages to the new pages without losing your high search engine rankings?
You can do this by using a “301 redirect“.

But what do you have to do if there is a space in the old URL:

^about nostylesheets.html$

Normally I would use this to make the URL working:

^about%20nostylesheets.html$

But this doesn’t work.
To make an URL working you just have to use quotes to make this URL working:

"^about nostylesheets.html$"

We the developers  already know about the famous jQuery validator and about all the wonderful things it is capable of. But we also know that this validation is only on the client side.

What about server side validation on form input? Isn’t that important too? Of course it is. And that is exactly why we’ve come up with the following solution for this issue: The php validator. This validator consists of  a class which contains a collection of methods similar to the jQuery validator. This way, we have validation on both client- and server sides using exactly the same rules and error messages.

Our PHP validator is based on the bassistance jQuery validator found at: http://bassistance.de/jquery-plugins/jquery-plugin-validation/

How it works

It’s pretty simple really. All you need is the Validator.class.php file which can be found at the google code project page http://code.google.com/p/jquery-validation-php-plugin/, or it can be downloaded directly from: http://jquery-validation-php-plugin.googlecode.com/files/jquery-validation-php-plugin-0.3.zip. Once you obtain this crucial file, then you can get to work.

First, make an instance by doing the following:

$oValidator = new Validator($aasOption);

The two-way road: PHP and jQuery
The $aasOption variable is an array with our validation rules and messages. This array is built the same way the jQuery is built. The main advantage of creating this array is that we can use it in PHP as well as JavaScript. This is mainly due to the fact that they both use the same atributes: ‘rules’ and ‘messages’. This way, we can implement it both ways.

Here is a simple example requiring the $_POST['name'] field to be set:

$aasOption = array(
‘rules’ => array(
‘name’ => ‘required’
),
‘messages’ => array(
‘name’ => array(
‘required’ => ‘This field is required’
)
)
);

The following javascript shows how we implement the array for use in JavaScript:

The catch is that each field to be validated must be specified in the jQuery options object by it’s name, not by id or class, as these are not acuired by the server.

The Form
Now that we can call upon our source, we can build our soon to be validated form.

<label for=”name”>Name:</label>
<input id=”name” type=”text” name=”name” value=”<?php

?>“/>

Now that we have a form, we can validate it with PHP. We must first check if there’s an empty $_POST.
if(!empty($_POST)){}

It is within this if- statement where validation is triggered using the validate(); method from the Validator.class.php.

The if- statement will eventually look like this:

if(!empty($_POST)){
$oValidator->validate($_POST);
}

Now we have validation. Hey! But wait! I don’t see any messages.
That is absolutely true because we haven’t added them yet.

Next to the input field, we must use the exact same label tag for errors that you would use in the jQuery validator.
We do this by using the showError(); method, found in the Validator class. We then echo the message by typing in the following:

<?php echo $oValidator->showError(‘name’); ?>

Pay attention: The showError(); method creates a label tag by default. You don’t have to create a label in wich you echo the method.

For the the jQuery validation you can go to work the same way you usually do. The only difference is that you will use the $aasOption array. More information about the jQuery validation can be found at: http://bassistance.de/jquery-plugins/jquery-plugin-validation/

Here is how you refer to it in JavaScript: validate(<?php echo json_encode($aasOption);?>);

For your viewing pleasure, we have created a demo so that you can see both the php and the JavaSript validation in action:
http://open-source.yes2web.nl/php-validator/demo1/validator-form.php
Further documentation:
http://bassistance.de/jquery-plugins/jquery-plugin-validation/
http://docs.jquery.com/Plugins/Validation
http://code.google.com/p/jquery-validation-php-plugin/

function sprint_r($sIn){
     return print_r($sIn, true);
}

to conform to choices made for (s)printf. While on the subject, why not include a fprint_r as well (useful perhaps for logging):

function fprint_r($oFP, $sIn){
     return fwrite($oFP, sprint_r($sIn));
}

and perhaps a vprint_r to complete the symmetry, though I have no clue as to what it should do .

PHP

In your PHP, always use the following immediately after you set up your connection.

• mysql_set_charset(‘utf8′, $oDB);
• mysql_query(‘SET NAMES \’utf8\”);

The tricky bit lies in your MySQL configuration file:

my.cnf

Add the following lines:

[client]
default-character-set=utf8
[mysqld]
default-character-set=utf8
default-collation = utf8_general_ci

This tells MySQL that the client (which is either PHP or the system) expects UTF-8. If you don’t tell MySQL this, a mysqldump will produce ANSI and an import from the command line will result in double encodings.

And don’t forget to use utf8_general_ci for all databases, tables and fields!

Many people think it’s hard to make their website suitable for mobile devices, but this isn’t the case at all. In this article I’ll introduce a couple of things you should consider before developing a mobile website. In a future article I’ll give some hands-on advice on where to start.

Know your visitors

When you consider to build a mobile website you should first question who you want to target. This is first step and very important for the rest of the process. There are thousands of different mobile devices and how much you probably want to target them all, that is pretty ambitious since almost every mobile browser reacts different. Why is this so important? If you want to target a group of people using low-end devices such as the Nokia 1100, which is very popular amongst low-budget users, this has consequences for example in the choice for the right mark-up language (more about this in a follow-up article). Another good example is when you have a b2b (business to business) model, most visitors use a ‘Blackberry’, so your website will have to be compatible with the Blackberry browser.

Choose your method

There are a couple of methods you can choose from for setting up your mobile environment. One of these methods is ‘doing nothing’. This is the easiest way, but definitely not the best way of dealing with mobile devices. Why is this one of the methods? After reading this article you could decide not to develop a mobile website any longer. I just want to point out that this “method” causes unpredictable results rendering your website on a mobile device.

The second method is to make a mobile version of your CSS stylesheet using ‘media=”handheld”‘. In many cases this works just fine, but you’ll run into problems very easily when you test your site in different devices. Although the mediatype ‘handheld’ is W3C compliant, it’s not a general standard. Many mobile browsers have their own way of interpretation of ‘media=”handheld”‘ and therefore  this method is not very reliable. Here you can see the differences in interpretation (source from ‘a list apart‘):

A third method you could use is to let your server determine which user agent your visitor is using and showing him the right version of your website. This method gives you the opportunity to build multiple versions, for multiple platforms, without using an alternative url. Your visitor can easily find you on your normal url (www.mybrand.com) instead of an alternative (www.mybrand-mobile.com). The problem with this method is that you can never let your visitor decide which version of your website he wants to see. He can’t switch between your versions if he thinks your pc version is better on his device.

The last method is related to the third method. It is possible to use build your own mobile version of your website with another url without losing your brand name. Examples: www.mybrand.com/mobile or mobile.mybrand.com or even shorter: m.mybrand.com.  In this case you can give your visitor the opportunity to switch from you mobile version to your standard version, so for flexibility reasons this method could be the best way. It is also possible to registrate an .mobi TLD (Top Level Domain), for example your url looks like: www.mybrand.mobi.

In my opinion the last method is the best way to achieve your goals. With a mobile version next to your normal site you can also optimize your mobile content. My preferences is to take the .mobi domain name, which could quickly evolve into the standard, when everyone uses a different way it will be still difficult to find the mobile version.

You can always choose or combine methods to suit your preferences. Keep your focus on your target group of visitors and be aware of the restrictions on many mobile devices.

The importance of testing

Although this is a step you take after realising your mobile website, testing is an important component of the process.  You have to  think about validating/ testing before you can put your site online! Mobile browsers, in contrast to the browser on your pc, are very strict in reading your code. Make sure you validate your xHTML (validate / mobilevalidate) or WML (validate). Another way to check the mobile browser compatibility can be found here or here.

Last but not least you have to test your websites. This can be difficult if you are not in possession of the right equipment. Let me point out a few possibilities to test your mobile website.

Test your mobile website on an emulator. This is the most common way to test your website in the first place. It is also not the easiest one. Finding a good emulator isn’t easy since the most look more like a simulator. Well known emulators are from dotMobi, Openwave and Apple. Problem with the most emulators is that they interpret the user agent like a normal browser (browser on the machine where the emulator is installed). This makes it hard to test and you can’t rely 100% on what you see.

The most expensive way of testing is to buy a small subset or representative phones. This is more an option if you’re considering to develop more mobile websites in the near future. Make sure you select a combination of different browsers on different devices (Windows Mobile Explorer, Safari Mobile, Opera Mini and Nokia’s built in browser).

Another way is to ask your friends or colleagues to test your website on their mobile phones. There is always someone to help you out. Make sure your code is valid first and that you have tested it in an emulator, so that you can do your testing on you friends phone quickly and effective.

session_start();
class SomeClass { ... }
$_SESSION['some_instance']; // which is a SomeClass assigned in some previous request

Depending on the implementation of the class, e.g. use of SPL, this will result in a __PHP_Incomplete_Class Object. To fix this, tell php what the class is/can do before unserializing, i.e. move session_start below the class declaration.

I found the following nifty solution floating around several forums:

SELECT
    (LENGTH(`_field_`) - LENGTH(REPLACE(`_field_`,"_substr_", ""))) / LENGTH("_substr_")
    AS "iCount"
FROM ...

The trick is straightforward: just remove your separator from the field-contents and see how much smaller the resulting value is compared to the original. Divide this by the length of your separator if it is composed of more than one character. I recommend replacing LENGTH("_substr_") by a number, as you generally know the length of the separator. Leave the division out when using a single length separator:

    (LENGTH(`_field_`)-LENGTH(REPLACE(`_field_`,"_substr_", "")))

This method may seem a little brute, but it reportedly not as slow as you might think (though I have not benchmarked it).