Edward Stafford» WordPress

WordPress: Use Custom Fields To Add Keyword Metadata to Your Posts

Ed Stafford — Thu, 04 Feb 2010 11:00:10 +0000

Keywords for edwardstafford.com

One of the short-comings with using WordPress is that it does not provide an easy, built-in way to include metadata for your web page descriptions and keywords (and rightfully so). Why Not? The reason is simply that WordPress cannot read your mind. I know it’s hard to believe when you consider what you can do with wordpress, but it’s true. The issue with Description and Keyword page metadata is that, to be truely effective, it should be created to describe the content found on each individual page. It’s how search engines like google determine how to categorize and index each page. Now, there are some SEO “experts” who will argue that this information is not very relevant anymore, and I do agree with that for the most part, but there are still SEO benefits to including this metadata vs. not including it at all.

I’ve been giving this some thought lately and developed a couple ideas of how to add these features into a wordpress site without too much difficulty. A bulb went off in a moment clarity when I started to think about using the Custom Fields to store page specific metadata. I was even naive enough to think I was on to something new (should have known better) but as I started researching some ideas, I realized there were others already doing similar things. Oh well, a minor detail. I took my own approach to the idea anyway, if for no other reason than a learning exercise. Ultimately, this could be added as a premium feature to any custom theme using a couple hooks and some custom theme options magic.

Okay smarty-pants! So how do we include description and keyword metadata?

The solution isn’t difficult to implement and can be used to add page specific metadata inside the tag of any wordpress page. In this example, I’m going to show you a simple solution, but with some creativity and a little thought, you can expand this to provide a more robust solution for your own needs.

Part I: Defining a Custom “Keywords” Field

Custom Fields are a little used gem found in the Posts and Pages page of the WordPress dashboard / admin back end and available when you add a new post or page, or edit an existing post or page.

Create a new custom field

To create a new custom field to use for your page or post keywords, scroll down to the Custom Fields section below the main editor and click the “Enter new” link.

That action will activate the input fields for “Name” and “Value”.

In the Name field type the name identifier you’d like to use. This identifier/name will be used to reference the custom field name/value pair later so make it something relevant to avoid confusion. For this example, I am using “keywords“.

In the Value field, type the string of keywords or phrases that you want to use as the keyword metadata string for the page/post. For this example, I am using wordpress, seo, metadata, custom fields

Add New Custom Field Inputs

When you’re done, hit the “Add Custom Field” button.

If you have already created a “keywords” Custom Field for a previous page or post, you will have the option of selecting it in future pages and posts from the Name drop down menu.

Select from Custom Fields Menu

Select the Keywords item from the menu and then add the keywords or phrases for your new page to the Value field. When your done, make sure you hit the “Add Custom Field” button to confirm it.

That completes Part I. You now have a functional Custom Field assigned to your post/page.

Next up! Adding and understanding the code that generates the keyword metadata tag.

Part II: The Magic Code.

function set_keywords(){
global $post;
$keywords = get_post_meta($post->ID, ‘keywords’, true);
$default_keywords = “Your, selection, of, default, keywords”;
$metatag= “”;

if (empty($keywords)){
$keywords = $default_keywords;
}
if (is_home() || is_front_page()){
$keywords = $default_keywords;
}

$metatag=”\t”;
$metatag.= “ $metatag.= $keywords;
$metatag.= “\” />”;
$metatag.= “\n\n”;

echo $metatag;
}
add_action(‘wp_head’, ‘set_keywords’);

Adding this block of code to your Theme’s functions.php file will create and insert page specific Keyword Metadata into inside the tag of your pages and posts assuming you have completed Part I.

How the code works

function set_keywords(){

The first line declares our function and sets the name “set_keywords”.

global $post;
$keywords = get_post_meta($post->ID, ‘keywords’, true);
$default_keywords = “Your, selection, of, default, keywords”;
$metatag= “”;

These four lines set up the variables that will be used later in the function.

global $post allows the function to reference values stored in an array containing post information that was previously set by WordPress outside of the current function.

$keywords = get_post_meta($post->ID, ‘keywords’, true) is up next and sets our variable, $keywords to a string value equal to the “keywords” Custom Variable if it was set for the current page in Part I by calling the wordpress function get_post_meta().

get_post_meta() is passed three arguments.

The post ID ($post->ID)
a Custom Field Name reference (keywords)
a boolean value (true)

These three arguments tell get_post_meta() to grab the “keywords” Custom Field value for a specific page ($post_ID = a reference to the current page) and return a string result (true).

Note: If the Boolean argument were set to “false”, get_post_meta() would return an array object instead of a single string.

$default_keywords = “Your, selection, of, default, keywords” sets a set of default keywords to use when the $keywords variable is empty or not set, or when you just want to include a general set of keywords.

$metatag = “” rounds up the variables for the function and is used to build the metadata tag string that will be inserted into the page tag.

if (empty($keywords)){
$keywords = $default_keywords;
}

The next step in the code is a conditional statement. Here I use the common PHP empty() function passing the $keywords variable as an argument to check whether the $keywords variable contains a value. If the empty() function returns true it means that $keywords does not contain a usable value, or that is has not been set. If this condition is true, it will set the value of $keywords to that of $default_keywords.

If the Keywords Custom Field was set for the current page, then the get_post_meta() function should have set the $keywords variable to a usable value equal to the Keyword Custom Field value. The condition will return false and the variable retains it’s Custom Field value.

if (is_home() || is_front_page()){
$keywords = $default_keywords;
}

Next I have another conditional statement that uses WordPress functions to see if the current page is either the home page – is_home(), or the “blog” page – is_front_page() If the current page matches either of these pages, I want to assign the value of $default_keywords to the $keywords variable.

The reason I do this is because the content on these pages is more dynamic and has a tendency to change often, effecting keyword relevancy. So I want to provide a generic set of default keywords instead of page content specific keywords.

Note: It is possible, using more in-depth techniques not covered here, to also include the Keywords Custom Field for these pages and enable a set of more targeted keywords for them.

$metatag=”\t”;
$metatag.= “ $metatag.= $keywords;
$metatag.= “\” />”;
$metatag.= “\n\n”;

These lines are used to build the actual text string creating the metadata tag for our page’s tag. for example, if our page contained a keyword Custom Field with a value of ”keyword1, keyword2, keyword3″, the output for a blog post or single page would be:

echo $metatag;
}

Wrapping up the function we have echo $metatag followed by the closing bracket bringing our function to a close. echo $metatag simply writes the output of the $metatag variable to the source of your web page inserting the keyword meta tag in the page’s tag.

add_action(‘wp_head’, ‘set_keywords’);

And finally bringing this code bit to an end is add_action(‘wp_head’, ‘set_keywords’). The add_action() function is a wordpress function used to hook your custom function to a WordPress action. In this case we are hooking our function set_keywords to the wordpress action wp_head. This is the piece that actually inserts your meta tag into the page tag.

Note: It is up to the individual theme developers to include the wp_head action in their themes, so there is a chance that your theme will not have it. In that case, check the documentation for your theme to see what action hooks are available to you.

That pretty much wraps it up!

Umm, Aren’t you forgetting something?

By now you may be thinking, “Great, but what about the Description meta tag you mentioned?”.

You can use this same technique demonstrated here to create unique page descriptions with just a few minor code changes. Just replace keyword references with description references.

Do you have any suggestions to imporve on this? Find it helpful? Have some else to share? Leave a comment!

How-to: Active Directory Authentication with WordPress

Ed Stafford — Tue, 15 Jul 2008 22:25:45 +0000

Why Use Active Directory with WordPress?

I recently set up a WordPress Blog internally for our company to use over our intranet to help improve communication, collaborate, share and develop ideas, and stay informed about company announcements or current events.. etc.

One of the requirements I had was to allow authentication against our Active Directory. Yes, we operate a Windows network primarily, but you can also authenticate against other LDAP directories as well. This was important from an IT position as well as the participants of the blog. I felt people would be more likely to participate if they didn’t have to manage separate user accounts for each service on the intranet. I also set up a Wiki that is Active Directory enabled. I’ll post about that at a later time. The point is, it makes little sense to create different credentials for each user with each new service. It not only becomes a hassle for IT to track and manage the accounts, it’s also a drag for participants to keep track of and manage their username and password pairs for each service. The result would most likely lead to lack of use and that is not what we want.

Integrating the existing Active Directory accounts means that each participant can access these services using the same credentials they use to access or log into their network accounts and desktops. When time comes to change passwords, you need only to update the Active Directory account and your done. Simple! What could be better?

Starting Point

The first thing we needed to do was find out how to include AD Authentication with WordPress 2.5. There are a small number of plugins that claim to allow AD Authentication, but from what I came across, most of them were older and no longer actively maintained. But…there were two in particular that still showed signs of being actively maintained and had promise.

The first was was aptly called “Active Directory Authentication”

The other plugin and the ultimately the one I managed to successfully include is wpDirAuth.

The Trials

Although I was able to get wpDirAuth to work with WordPress 2.5, there was a catch. The current “Official” release of wpDirAuth as of this writing is version 1.2 which is not compatible with WordPress 2.5 so there was some work involved to make this happen. I visited the wpDirAuth plugin page to look at the install directions. They seemed easy enough. It wasn’t until I actually installed and activated the plugin that I realized it wouldn’t work. My next stop was the support channel that the author set up to help troubleshoot install and authentication issues. It was here that I learned there was a patch already available and provided by a generous wpDirAuth user – Adam Yearout. I applied the patch and then tried to login with my network credentials again, and … No luck! By now I was scratching my head. Searching and reading all the information I could find, I finally found myself on the wpDirAuth Developer Support Channel. This was another channel set up specifically for developers. It was here that I uncovered some clues as to what was happening and a small code tweak that was necessary to overcome the problem. Apparently, the author of the plugin assumed that the login name was also the name associated with the Active Directory Account Email, which in most cases is true, but not always. For example username: johndoe would by default have an email johndoe@domain.com. In my case, my email and name and login name were not the same, so the logic that the plugin author used would not work. The good news is that the fix is a fairly simple one if you know where to look and the dev channel contained all the clues needed to find the info.

Setting up wpDirAuth with WordPress 2.5

For this how-to, I am using wordpress 2.5 installed on an Ubuntu 8.04 LTS server With Apache2 and PHP5. There is no GUI and I am not running an ftp server on this server so all settings and changes are completed using putty over SSL.

So lets get to it. Setting up AD Authentication was not as straight forward as I had hoped and required a few extra steps along the way.

The first step is to download the wpDirAuth plugin from the WordPress plugins section.

From a terminal or if logged into the server via Putty, change to your home directory and get the latest version of the wpDirAuth plugin.

cd /home/your_account_name
wget http://downloads.wordpress.org/plugin/wpdirauth.1.2.zip

Note: the file is compressed as a .zip so you may need to run:

sudo apt-get install unzip

before you can extract the files.

Next extract the files by executing:

unzip wpdirauth.1.2.zip

Now you have a new directory called wpdirauth.1.2 in your home directory.
Move into the new directory and list the contents using

cd wpdirauth.1.2
ls

Now you will see the wpdirauth directory. You need to move this entire directory to your WordPress plugins directory.

Note:The following instructions and paths are specific to my server. You may need alter these instructions to meet your needs.

To move the extracted wpdirauth directory, make sure you are in the wpdirauth.1.2 directory and execute the command:

cp -r wpdirauth /var/www/wpblog/wp-content/plugins

Now we need to move into the actual WordPress Blog directory where our files are hosted by executing the command:

cd /var/www/wpblog/wp-content/plugins

Now if you execute

you should see the wpdirauth plugin folder. Once again, we will change directories and move into the hosted wpdirauth directory using:

cd wpdirauth

This is where the editing (and the fun) begins.
Remember, we need to make some changes before we activate this plugin in WordPress 2.5 or it will not work.

Patching the wpdirauth plugin

Before making any changes to our files, it’s alway a good idea to make some backups.

From the wpdirauth execute the command:

cp wpdirauth.php wpdirauth.php.orig

Next apply the patch that was just downloaded. This patch will make changes to the wpdirauth.php file, and update the Plug-in version for 1.2 to 1.3

Apply the patch by executing the command:

patch -p1 < ../wpDirAuth-1.2-to-1.3.patch

Note: You need patch installed to execute the following command. If Patch is not installed, you can install it by executing:

sudo apt-get install patch

Editing the plugin

Once the patch is installed, your Active Directory authentication should for most people. But we are not done yet.

There is an issue related to Active Directory users names and their email addresses. Active Directory user accounts that are also created with an email address, are by default given an address equal to the login name.
For example an Active Directory user created with a login name of johndoe would have an email address of johndoe@domain.com. The problem arises in the way that wpDirAuth authenticates against Active Directory using the email address. If at some point, the users default email address is changed, the login name does not match the email address and authentication fails. The fix is a simple one if you know where to look.

To prevent authentication failure due to the login name and email mismatch, you need to make a small edit to the wpdirauth.php file. Start by executing the following command:

sudo nano wpdirauth.php

Note: I am using nano to edit files on the system. You can use any text editor you have available on your system.

Next, scroll through the file till you find the wpDirAuth_auth() function at line 246. It should be about 1/4 of the way down the page. Edit this function as follows:

At about line 273 find the line

if ($accountSuffix) $username .= $accountSuffix;

and delete or comment it out.

Next move down to about line 284 and look for the line that reads:

$filterQuery = “($filter=$username)”;

Add a new line after this and enter the following:

if ($accountSuffix) $username .= $accountSuffix;

Basicly, we are just moving the line “if ($accountSuffix) $username .= $accountSuffix;” down a few lines and adding it after the line ” $filterQuery = “($filter=$username)”; ”

This is the snippet of the the wpDirAuth_auth() function after I made the changes look like this.

function wpDirAuth_auth($username, $password)
{
….….

/**
* This section commented out to enable AD email/username mismatch.
* if ($accountSuffix) $username .= $accountSuffix;
*/

/**
* Only setup protocol value if ldaps is required to help with older AD
* @see http://groups.google.com/group/wpdirauth-support/…
*/

$protocol = ($enableSsl) ? ‘ldaps://’ : ”;

if (!$filter) $filter = WPDIRAUTH_DEFAULT_FILTER;

$filterQuery = “($filter=$username)”;

/**
* Next Line added to enable AD email/username mismatch
*/

if ($accountSuffix) $username .= $accountSuffix;

// Connection pool loop – Haha, PooL LooP
foreach ($controllers as $dc) {

….….

Activating the Plugin

One requirement that may still be missing is php’s LDAP support. If you do not already have support for LDAP enabled in php, you will need to enable it before you can authenticate against the Active Directory.
To enable LDAP in PHP, execute the following command

sudo apt-get install php5-ldap

At this point, and assuming everything went well, it’s time to log into your WordPress Blog as the WordPress Admin and navigate to the “settings” page. From here, you will see a “Directory Auth” link at the top of your settings page. click this link to access the Directory Auth setup page and fill in the required fields as they apply to your Active Directory set up.

Enable Directory Authentication = yes
Require SSL Login = Yes if you use SSL Auth, No if you do not.
Enable SSL Connectivity = yes if you are using SSL or LDAPS connections, No if you are not.
Directory Servers (Domain Controllers) = DNS Name or IP Address of your Active Directory Domain Controller
Account Filter = samAccountName or field to search the username to locate the directory profile. For AD, samAccountName should work.
Account Suffix = @yourdomain.com – This is the suffix for you local domain usen in email addressing in the AD for you local network.
Base DN = DC=domainname,DC=com – Note this will vary depending on you local network and complexity of your AD
Bind DN = Blank if you allow Anonymous Binding to your Directory or a username use to pre-bind if you do not.
Bind Password = Blank if you allow Anonymous Binding to your Directory or the password of the user used to pre-bind if you do not.

The remainder of the fields are self explanatory and are not critical to successful authentication.

Note: One of the easiest ways to get the correct Base DN for Active Directory is to use the ADSI Edit utility

Now save the changes and log out of the WordPress Admin account.
Next attempt to login to WordPress using an Active Directory User Account.

You should now have Active Directory Authentication enabled and working with WordPress.

Remember, your mileage may vary depending on your specific needs and existing network and Active Directory structure.

Have any other tips, or want to share your experience with AD authentication in WordPress? Leave a comment.