The new format promises to reveal much more information about the search result rankings that was previously available, and this post will show you how to take advantage of that information to tune your SEO efforts using Google Analytics.

Starting this week, you may start seeing a new referring URL format for visitors coming from Google search result pages. Up to now, the usual referrer for clicks on search results for the term "flowers", for example, would be something like this:

http://www.google.com/search?hl=en&q=flowers&btnG=Google+Search

Now you will start seeing some referrer strings that look like this:

http://www.google.com/url?sa=t&source=web&ct=res&cd=7&url=http%3A%2F%2Fwww.example.com%2Fmypage.htm&ei=0SjdSa-1N5O8M_qW8dQN&rct=j&q=flowers&usg=AFQjCNHJXSUh7Vw7oubPaO3tZOzz-F-u_w&sig2=X8uCFh6IoPtnwmvGMULQfw

What does that mean for me?

Common speculation is that the cd parameter in the referral URL indicates the position of your page in the search results, and this has been confirmed by Matt Cutts.

Knowing what position your pages hold in the SERPS for a given keyword can be enormously helpful to your SEO efforts, so it makes sense to start tracking this new data. Prior to the change in referer, it was possible to track your SEO rankings with Google Analytics, but you could only get information about the page on which you were ranking for a keyword search, not your overall position.

Create a New Profile

You are definitely going to want to create a new profile within Google Analytics so that you do not interfere with the data that is already being collected for your site (The profile that we are about to set up will only capture data for organic search results from Google that use the new referer string).

Sign in to your Google Analytics account and "Add a Profile for an Existing domain". You can give it any name you like, I chose to use "Google SERP Ranking".

Create the Filters

The first thing that we need to do is create a couple of filters to make sure that only organic google searches are included in this profile. Order is important, so make sure that you either create your filters in the order that they are described here, or that you go back when you are finished and reorder them appropriately.

1. Include Organic Search Results

Create your first custom include filter using the Campaign Medium filter field and a filter pattern of organic.

2. Include Google Search Results

Create another custom include filter using the Campaign Source filter field and a filter pattern of google.

3. Include New Google Referral URL

Create the final custom include filter using the Referral filter field and a filter pattern of google.com/(search|url).*\bcd=\d*.

4. Extract Keyword and Ranking Data

The last filter we need to create is an advanced filter that will extract data from the referal string and create custom output that will be viewable in our reports. Create an advanced custom filter, and set the pulldowns, text areas and radio buttons as shown in the screenshot. This will extract the keywords and SERP position from the referal string and replace the output with our own custom string in the format <keyword> (Rank: <position>)

\bq=([^&]*)
\bcd=(\d*)
$A1 (Rank: $B1)

Visualizing Results

Once you have created the new profile and filters, and have started receiving traffic, you should be able to see the keyword/ranking data in any of your reports when you change the dimension to User Defined Value.

Please share your experiences with this or any other helpful Google Analytics tricks that you use!

Webgrind is an Xdebug profiling web frontend in PHP5. It implements a subset of the features of kcachegrind and installs in seconds and works on all platforms.--Webgrind

Anyone who has ever needed to profile code is probably familiar with KcacheGrind (a profile data visualization tool). KcacheGrind provides a way to visualize the profile data from a program execution, allowing you to quickly and easily see where the program is spending its time. Knowing where the execution bottlenecks are allows you to focus your optimization efforts in the correct places.

For a long time, the Xdebug extension for PHP has been able to (among other things) dump execution profile information to disk in a format that is usable by KcacheGrind, which is great if you are running Linux with KDE.

The webgrind project provides a web-based replacement for KcacheGrind that can be installed on any operating system, allowing you to visualize a portion of the Xdebug profiling data through a browser.

Installation

Before using webgrind, you must first install Xdebug.

Installing webgrind is pretty simple:

1. Download webgrind
2. Unzip webgrind in your web server's document root
3. Configure Xdebug and webgrind
4. Point your browser to where you installed webgrind

Configuration

Unfortunately, webgrind does not often work "out-of-the-box"... There are a few configuration details that need to be dealt with in order to start profiling your code. The following PHP configuration directives can be used to control the behavior of Xcebug:

xdebug.profiler_enable

This directive actually turns on Xdebug's internal profiler. You must set this to 1 in order to have Xdebug actually produce output for webgrind to analyze.

xdebug.profiler_enable_trigger

If you enable this option, profiles will only be generated if you pass a GET/POST parameter or cookie with the name XDEBUG_PROFILE, e.g., http://localhost/script.php?XDEBUG_PROFILE. You must not enable xdebug.profiler_enable if you use this option.

xdebug.profiler_output_dir

This directive tells Xdebug where to put the profile data. By default, it is set to '/tmp', which is usually fine. If you want, you can probably omit this from your Xdebug configuration.

xdebug.profiler_output_name

This value tells Xdebug how to create filenames for the data it writes to disk. By default, the value is set to cachegrind.out.%p, where %p will be replaced with the process ID. This is bad, and you will definitely need to change it. The problem is that Apache processes serve multiple requests, so each request in a given process will overwrite the profiling data from previous requests. Other possible format specifiers can be used.

xdebug.profiler_append

Enabling this option will cause xdebug to append data to the output file if it already exists (the default behavior is to overwrite the output file). This is a handy option if you need to average out the profiling data over multiple script executions. In that case, be sure to set xdebug.profiler_output_name using a format that will ensure that each successive page load uses the same profiler output name, e.g., cachegrind.out.%s.

Assuming you have already loaded the Xdebug extension, the following additional PHP configuration directives should be a good starting point for you:

xdebug.profiler_enable = 1
xdebug.profiler_output_name = cachegrind.out.%t.%p

That's it, you should be ready to profile your PHP code with Xdebug and Cachegrind!

PageRank is a link analysis algorithm used by the Google Internet search engine that assigns a numerical weighting to each element of a hyperlinked set of documents, such as the World Wide Web, with the purpose of "measuring" its relative importance within the set.

What is my PageRank?

There are a number of ways to check your PageRank, but some of the easiest and most useful come in the form of Firefox plugins. These are a few of the most popular:

• SEO For Firefox
• SearchStatus
• Live PageRank

My Member Access and UserVoice WordPress plugin pages received an increase in PageRank, but for the most part pages here retained the same ranking. How did your site fare after this Google PageRank update?

Here's a sample of what people are saying on Twitter about the latest Google PageRank update:

• @KennethMoody: The Google Pagerank God has been been good. - 8:24
• @jredd77: Celebrating my website's PageRank increase from 0/10 to 3/10 overnight. - 9:21
• @highonbeingdave: Finally got my web site from 0 to 1 on PageRank! Yippie! (cheap thrills come easily) - 10:26

Join the conversation!

A common problem is that WordPress is unable to access the filesystem directly, which results in a page indicating that "To perform the requested action, connection information is required."

If you feel that your WordPress installation should not be asking you for this information, or you simply do not want WordPress to use this method of plugin management, you may be able to work around it.

What is Causing This?

Whenever you use the WordPress control panel to automatically install, upgrade, or delete plugins, WordPress must make changes to files on the filesystem.

Before making any changes, WordPress first checks to see whether or not it has access to directly manipulate the file system.

If WordPress does not have the necessary permissions to modify the filesystem directly, you will be asked for FTP credentials so that WordPress can try to do what it needs to via FTP.

Why Can't WordPress Write To The Filesystem?

In order to understand why WordPress can't write to the filesystem, we need to take a look at some WordPress internals.

The following code is from the get_filesystem_method() method in the wp-admin/includes/file.php file:

if( function_exists('getmyuid') && function_exists('fileowner') ){
    $temp_file = wp_tempnam();
    if ( getmyuid() == fileowner($temp_file) )
        $method = 'direct';
    unlink($temp_file);
}

This code creates a temporary file and confirms that the file just created is owned by the same user that owns the script currently being run. In the case of installing plugins, the script being run is wp-admin/plugin-install.php.

This may seem a little counter-intuitive, since the only thing WordPress really needs to be able to do is write to the wp-content/plugins directory.

What Can I Do About It?

In order to fix this issue, you will need to make sure that the scripts which need to write to the filesystem are owned by the same user that apache is running as.

Many hosting companies will run your apache instance using your user account, and all of your files will be owned by the same account. In those cases, you will probably not have the issue described here.

If your hosting company is running apache as a system user, and your files are owned by your own account, your only option may be to enter your FTP credentials here and allow WordPress to use FTP.

If you are running on a hosting company that gives you root access, or you have installed WordPress on your own development machine at home or at work, you should be able to modify the filesystem permissions to allow WordPress to directly access the filesystem.

The easiest way to do this is to find out what user apache is running as and change ownership of the entire WordPress directory to that user. For example, if apache is running as 'httpd', you could use the following commands on your WordPress installation directory:

# chown -R httpd: wordpress

Note that not all versions of chown are equal. If that command does not work, see your local chown man page for usage information.

Tip: In order to find out what user your instance of apache is running as, create a test script with the following content:
<?php echo(exec("whoami")); ?>
Thanks Suzanne!

Do you have any Firefox add-ons that you can't live without? Leave a comment and tell us about them!

I've already started making customizations with a new Twitter badge that features an icon from the free icon set Practika featured over at Smashing Magazine (If you don't read Smashing Magazine, you're really missing out!).

Look for more customizations over the next few days!

If you navigate the the Settings tab, and click on the Reading sub-menu option, you will see the Front page displays WordPress configuration option. This option allows you to specify whether your front page, i.e., the page displayed when a user visits your main site URL, will contain a listing of your latest posts, or a different, static page.

Your latest posts

Selecting this radio option will make your latest posts show up on the front page of your site

A static page

Selecting this radio option allows you to choose a static page as your front page

Front page

The page that you select in this pull-down will now be displayed when a user visits the front page of your site.

Posts page

The page that you select in this pull-down will now display your latest posts instead of any content that it might currently contain (you don't have to use this option).

What's the Point?

This functionality makes it easy for WordPress administrators to handle sites with formats that make it more appropriate to show a static page as the front page, but that also want to be able to show the default listing of recent posts without making any template modifications.

I hope you found this article helpful, please feel free to contact me with any of your WordPress questions!

10. Don't be Case Sensitive
Since URLs can accept both uppercase and lowercase characters, don't ever, ever allow any uppercase letters in your structure. If you have them now, 301 them to all-lowercase versions to help avoid confusion. If you have a lot of type-in traffic, you might even consider a 301 rule that sends any incorrect capitalization permutation to its rightful home.
http://www.seomoz.org/blog/11-best-practices-for-urls

It doesn't require much to rewrite URLs to lower-case, and the necessary configuration directives can be placed in either a virtualhost or .htaccess file. First, the RewriteEngine is enabled, and a custom RewriteMap called 'lc' is defined using the internal 'tolower' map. Next, a RewriteCond rule is used so that only URLs containing upper-case characters are rewritten. Finally, the actual RewriteRule is defined using the 'lc' RewriteMap that we just created to transform the captured URL to lower-case before 301-redirecting the user.

RewriteEngine On
RewriteMap  lc int:tolower
RewriteCond %{REQUEST_URI} [A-Z]
RewriteRule (.*) ${lc:$1} [R=301,L]

The following is the output from the RewriteLog that shows the processing for a request to /INDEX.PHP. Note that only a single upper-case letter needs to be present for the rewrite rule to be triggered. The log output clearly shows the rewrite rule being applied, the RewriteMap being referenced, and the 301 redirect taking place. The subsequent request for /index.php is also shown, where the rewrite condition does not match and the request is passed through.

init rewrite engine with requested uri /INDEX.PHP
applying pattern '(.*)' to uri '/INDEX.PHP'
RewriteCond: input='/INDEX.PHP' pattern='[A-Z]' => matched
map lookup OK: map=lc key=/index.php -> val=/index.php
rewrite '/INDEX.PHP' -> '/index.php'
explicitly forcing redirect with http://test/index.php
escaping http://test/index.php for redirect
redirect to http://test/index.php [REDIRECT/301]
init rewrite engine with requested uri /index.php
applying pattern '(.*)' to uri '/index.php'
RewriteCond: input='/index.php' pattern='[A-Z]' => not-matched
pass through /index.php

ReflectionClass to the Rescue

The following is the script that I came up with, which pulls translatable error messages along with available message variables and generates a data structure based on the class name of the validators. Here is the script in its entirety, with some short comments describing how it works:

$zend_library = "/my/php/library";
set_include_path($zend_library);

// Create a new RecursiveDirectoryIterator for the Zend_Validate
// directory and recursively iterate over the files.

$messages = array();
$rdi = new RecursiveDirectoryIterator($zend_library . '/Zend/Validate');
foreach (new RecursiveIteratorIterator($rdi) as $path) {

    // Read in the file and generate the expected class name by
    // converting the portion of the path starting with Zend/Validate
    // and replacing '/' with '_'. For example, this converts the path
    // Zend/Validate/Regex.php to Zend_Validate_Regex.

    require_once($path);
    $class = strtr(preg_replace('#.*(Zend/Validate/.*)\.php$#', '\1', $path), '/', '_');

    if (class_exists($class)) {

        // If the expected class exists, create a ReflectionClass
        // instance and fetch the properties of the class. Make
        // sure that the property '_messageTemplates' exists, as
        // this indicates that we are dealing with an actual concrete
        // Zend_Validate class.

        $reflection = new ReflectionClass($class);
        if ($reflection->hasProperty('_messageTemplates')) {

            // Get the default properties as an associative array and
            // add the 'value' key to the _messageVariables property
            // since by default, 'value' is always available for substitution
            // into a message template.

            $props = $reflection->getDefaultProperties();
            $props['_messageVariables']['value'] = true;

            // Add an element to the $messages array, keyed on
            // the name of the current class. The element contains
            // an array of translatable templates, and an array of
            // valid message variables that can be substituted into
            // those templates.

            $messages[$class] = array(
                'templates' => $props['_messageTemplates']
              , 'variables' => array_keys($props['_messageVariables'])
            );
        }
    }
}

Printing out an element of the $messages array shows the structure that is now available to work with, which brings us to the next step... what can we do with this data?

print_r($messages['Zend_Validate_Regex']);

Array
(
    [templates] => Array
        (
            [regexNotMatch] => '%value%' does not match against pattern '%pattern%'
        )
    [variables] => Array
        (
            [0] => pattern
            [1] => value
        )
)

Processing the Output

Now we have the data that we need to start providing translations, what can be done with it? I am using the Zend_Translate_Tmx translation adapter, so I iterate over the data and write out a single TMX 1.4 format file for all of my validation error translations (including some notes regarding the source of the translatable string as well as the possible variables that can be used). The following code illustrates how this is done:

$format = '
        <tu tuid="%s">
            <note>Validation message template for class %s.</note>
            <note>Possible variables include %s</note>
            <tuv xml:lang="en">
                <seg>%s</seg>
            </tuv>
        </tu>
';

echo <<<XML
<?xml version="1.0" ?>
<!DOCTYPE tmx SYSTEM "http://www.lisa.org/fileadmin/standards/tmx1.4/tmx14.dtd.txt">
<tmx version="1.4">
    <header creationtool="Reflection" creationtoolversion="1.0" datatype="winres" segtype="sentence" adminlang="en-us" srclang="en-us" o-tmf="txt">
    </header>
    <body>
XML;

foreach ($messages as $class_name => $data) {
    $variables = join(', ', $data['variables']);
    foreach ($data['templates'] as $key => $template) {
        printf($format, $key, $class_name, $variables, $template);
    }
}

echo "    </body>\n"
  .  "</tmx>\n";

The collected data can of course also be formatted in whatever way is required by the type of Zend_Validate_Adapter that you are using.

Hopefully this will save you some time in your translation efforts. One thing to watch out for is that several validators re-use messageTemplate identifiers and so cannot be translated (see bug ZF-3164 for more info).

How can I create a route with an optional parameter; e.g /search/:foo/:bar, where :bar is optional? Do I need to create two different routes?

Several users correctly suggested specifying a default value for :bar when constructing the route, and it was also mentioned that both standard routes and regular expression routes could be used to solve the problem. Naturally, this lead to a discussion of which type of route would be fastest, with no real numbers to fall back on.

The purpose of this article is to present benchmark numbers for both route types (for the specific application described above) and to describe the methods used to run the benchmark tests. This won't be a full tutorial on how to use xdebug or kcachegrind, so I won't go into great details about how to use them, but the full source code for the benchmarks will be available at the end of the article.

Method

In order to profile the different routing options, xdebug was used in profiling mode and the resulting profile data was viewed in kcachegrind. The profiling test uses two URLs, one with the optional parameter and one without. Each router's match() method is called 10000 with each of the two URLs.

The Standard Route

The first route tested was the standard route, which is instantiated with a string describing the route, and an array of default options. The route accepts two parameters, indicated by :foo and :bar. Since a default value is specified for :bar in the initialization array, the route will match both of our test URLs, using the value 'mybar' if no parameter is given for :bar.

$route = new Zend_Controller_Router_Route(
    'search/:foo/:bar'
  , array(
        'controller' => 'search'
      , 'action'     => 'index'
      , 'bar'        => 'mybar'
    )
);

The Regex Route

The next route tested was the regex route, which is instantiated in the same way as the standard route, with the addition of an array that maps parameter positions to value names; this allows the route map the results from an internal preg_match call to the numerically keyed captured parameters.

$route = new Zend_Controller_Router_Route_Regex(
    'search/(\w+)(?:/(\w+))'
  , array(
        'controller' => 'search'
      , 'action'     => 'index'
      , 'bar'        => 'mybar'
    )
  , array(
        'foo' => 1
      , 'bar' => 2
    )
);

The Results

The initial test with 10,000 iterations using the test URL that contained both the foo and bar parameters shows that the standard route is faster than the regex route by about 12%. The image at right is a kcachegrind visualization of the call tree rooted in the function that executes the two tests with a distance limit of 1.

The second test of 10,000 iterations used the test URL with did not contain the bar parameter. It shows that the regex route is significantly faster than the standard route by about 48%.

Based on these tests, it seems like the best choice depends on how often the optional parameter is expected to be provided. If the answer is less than about 60% of the time, the regex route would seem like the best choice; otherwise the regex route will be faster. Keep in mind that this is all based on a specific route, and your situation may vary so if performance is an issue some custom tests may be in order.

If you are interested in reproducing these benchmarks, you can download the benchmarking scripts and customize them as needed.