1 can cream of mushroom soup
1 can milk (soup can)

Pour over mixture. stir once. Bake 45-60 minutes or until potatoes are done. Sometime during the last 10 minutes of baking spread grated cheese on the top.

1/2 cup butter or margarine, softened
1/2 cup granulated sugar
1/4 cup brown sugar, packed
1 egg
1 teaspoon vanilla
1 cup all purpose flour
1/2 teaspoon salt
1/2 teaspoon baking soda
1 6 ounce package (1 cup) semisweet chocolate pieces
1 cup peanut [butter]

Preheat oven to 375 Degrees F

Cream butter or margarine and sugars; add egg, vanilla and beat until light and fluffy. Sift together flour, salt, and baking soda; stir into creamed mixture; blend well. Add chocolate pieces and peanut [butter] and stir by hand.

Drop from teaspoon about 2 inches apart on a greased (I don't grease because I use peanut butter not peanuts) cookie sheet. Bake in 375 F oven 12-14 minutes. Remove from sheet immediately.

Yield: 3 dozen Cookies.

Running an application in "The Cloud" is a far different experience than running on a traditional shared or dedicated host, and to tap into some of the features of the platform the Microsoft Interoperability Team has worked hard to deliver open source solutions to the community to enable applications to run faster and more smoothly. Let's run down a few of the resources currently available.

Pre-built starter solution

The MS-Interop team has released (on Github!!) a prepackaged solution that will get you a WordPress site fully configured to run on the Windows Azure platform in minutes. From there you can start customizing it with your own plugins and themes, as well as perform any custom development for Windows Azure itself.

The files can be found on Interoperability Bridges Github account under the Windows Azure PHP Scaffolders repository.

Additionally, two very good tutorials can be found on the Azure PHP website for getting WordPress running:

• How to deploy WordPress using the Windows Azure SDK for PHP scaffold
• How to deploy WordPress Mulisite to Windows Azure using the WordPress scaffold

Windows Azure Helper for WordPress

The Windows Azure Helper for WordPress is a very simple plugin that helps site administrators by adding or removing features that users should not have access to changing on a site running in Windows Azure.

The features list on the plugin page list the following (as of publishing this post):

Features

• Hide the Updates menu item under Dashboard
• Hide the Add new plugin menu item under Plugins
• Hide the Permalinks menu item under Settings

WP DB Abstraction

If you want to use SQL Server for any reason, this is the plugin to have. Any WordPress install, whether on Windows Azure or not, can take advantage of existing (maybe corporate) database servers. When hosting in Windows Azure you will be using SQL Azure, which is SQL Server "in the cloud".

The WP DB Abstraction plugin can be found in the WordPress repository.

Windows Azure Storage for WordPress

If you wish to take advantage of the massive cloud storage available in Windows Azure, or easily add content to the Windows Azure CDN, this plugin will help you do just that. With this plugin you can redirect file uploads to Windows Azure storage completely transparently to the user. A must have if you host on Windows Azure due to the non-shared nature of the cloud instances drives.

The Windows Azure Storage for WordPress plugin can be found in the WordPress repository.

Windows Azure Developer Library

The real meat and potatoes of this post is the Windows Azure Developer Library. This plugin adds the library from the Windows Azure SDK for PHP to WordPress. Upon activation, developers will have access to all the features provided by the Windows Azure SDK for PHP in their plugins. The Microsoft Interoperability team maintains a great list of tutorials on the Azure PHP website to help developers, code examples included.

Be sure to check out the Azure PHP tutorials page for updates as this list may be out of date

Automated scaling

I hear that there is a plugin in the works (maybe because I am one of the devs ) that gives site admins the ability to set various trigger points (CPU, Memory, Network, etc) to have WordPress automagically start up more instances to handle extra traffic, or remove instances when traffic is low to save costs. If you are interested in testing this plugin please let me know.

Happy developing!

You now have all the resources you need to start taking advantage of the resources provided by Windows Azure from within WordPress.

If you have any question or would like help developing your Windows Azure WordPress applications feel free to drop myself or the Microsoft Interoperability team a line.

Click to make the photos larger

Photo processed with Camera+

Original iPhone photo

Get the slides and code

If you would like to view the slides used during the presentation they are available as a PDF below:

blobaugh-Feb2012-Extending_WordPress_User_Profiles

The complete code from this presentation can be found on the Seattle WordPress Github account

https://github.com/WordPress-Seattle

Synopsis

There are several built-in user contact methods that are already available on user profiles in WordPress, however the services there are not very widely used today. The built-in contact methods are: AIM, Yahoo IM, and Jabber. Of the three AIM and Yahoo IM are rarely used today, and most general audiences do not know what Jabber is (Jabber is pretty awesome and has wide ranges of uses. Google, for instance, uses Jabber for their chat network). More people today are using services such as Twitter or Facebook, or LinkedIn, so it probably makes sense to update the list of contact methods with whichever are most correct for your site.

What this post will show you is how to tap into the user profile to get rid of unneeded contact methods and add a new one for a user's Twitter handle. Additionally, when we are done each post will show the post author information box below the content. This is to highlight how easy it is to use the new contact methods to display on the frontend.

Filters

Recall that filters are similar to hooks, except that filters are designed to alter output instead of trigger an event. For our purposes we will be tapping into two filters, one which will allow us access to the user's contact methods and the other to post content.

We will be using the following two filters:

• user_contactmethods
  Holds a list of contact methods on a profile
• the_content
  Holds the content of a post

Setup the user_contactmethods filter

Filters are easily created using the add_filter() function. This function takes several arguments, however will are only focusing on the first two, which are the WordPress filter name and the name of our custom function to send the filter to. Setup the filter with the following code:

add_filter( ‘user_contactmethods’, ‘wpsea_setup_user_profile’ );

When calling our custom function, wpsea_setup_user_profile(), a variable containing an array of the available contact methods will be passed.

function wpsea_setup_user_profile ( $user_contactmethods ) {}

By default the following exist: AIM, Yahoo Messenger, Jabber

Remove unused contact methods

Contact methods are stored in the passed in parameter, which is an array, and can be removed using the built-in PHP method to remove array elements, unset(). None of the existing contact methods are needed so let’s get rid of them all:

function func_name ( $user_contactmethods ) {
    unset( $user_contactmethods[‘aim’] );
    unset( $user_contactmethods[‘yim’] );
    unset( $user_contactmethods[‘jabber’] );
}

Add a new contact method

This is the really complex part, adding a new contact method (sarcasm). The WordPress core developers have made this very easy on us by providing the user contact methods as an array. To create a new one just create a new, uniquely named, element in the array and viola, a new user contact field will show when editing the user's profile. Make sure to pick something that makes sense when naming the array element.

function wpsea_setup_user_profile ( $user_contactmethods ) {
    $user_contactmethods[‘twitter’] = ‘Twitter Handle’;
}

Take a peek

If we have done everything correctly you should now be able to activate the plugin and see the changes you made on your profile

Move to the front

Well, we have our backend all spiffed up now with the new contact methods, but unless users only look at profiles from within the backend you will probably be wanting to know how to show your new contact method to visitors on the frontend, this is quite simple. If you are following along with my presentation slides you will notice that I am going to diverge here. The slides explain the various functions used to create our author information box, however I am skipping that here and getting right down to the code.

The get_the_author_meta() function allows frontend developers and designers access to any of the user's profile fields. get_the_author_meta is usually used within The Loop and gets the current post author automagically, however it can be used anywhere and an optional user id supplied. For our purposes we will be using code similar to:

$twitter_handle = get_the_author_meta( 'twitter' );

Now we need to setup a filter for the_content, which is done with the following line of code:

add_filter( 'the_content', 'wpsea_post_user_profile' );

The rest of the code I will give you in a dump because it is regular display code that should make sense to you already, if not check the Codex or leave a comment and I will add more details.

 
function wpsea_post_user_profile( $content ) {
 
    if( !is_singular( 'post' ))
        return $content;
 
    $id = get_the_author_meta( 'ID' );
 
    $s = '
<div id="author-bio" style="border: 1px dotted #000; padding: 5px">';
 
    // Author gravatar
    $s .= '
<div id="author-avatar" style="float:left; margin-right: 10px">' . get_avatar( $id, '150' ) . "</div>
 
";
 
    // Author info
    $s .= '
<div id="the-author-info" style="text-align:left; width: 100%">';
 
        if( $url = get_the_author_meta( 'user_url' )) {
            $s .= '<strong><a href="' . $url . '">' . get_the_author() . '</a></strong>';
        } else {
            $s .= '<strong>' . get_the_author() . '</strong>';
        }
 
        $s .= '
 
' . get_the_author_meta( 'description' ) . '
 
';
 
        $s .= '<a href="' . get_author_posts_url( $id ) . '">All posts by ' . get_the_author() . '</a>';
        $s .= '<br/><a href="http://twitter.com/' . get_the_author_meta( 'twitter' ) . '">
               Follow ' . get_the_author() . ' on Twitter</a>';
 
    $s .= '</div>
 
';
 
    $s .= '</div>
 
';
 
    return $content . $s;
 }
 

Want it all?

The Seattle WordPress group utilizes Github to share code amongst members and for presentations. You can find this entire file on their Github page

https://github.com/WordPress-Seattle

WordPress is a powerful multi-user web content management system. Due to its multi-user nature, WordPress has long instituted a full fledged user system, complete with separated roles and permissions for each user. What happens, however, when WordPress is brought into an environment with an existing user repository? Out of the box WordPress has no support for interacting with other user authentication methods other than built-in, however there exist WordPress filters that allow developers to hook into WordPress core actions, such as user authentication, registration, etc and alter their logic. In this post I will show you how to replace WordPress' built-in authentication with authentication based off a very simple web service (Which we will also create).

Unless otherwise noted, all development will be assumed to exist at http://localhost for the purposes of this tutorial.

Now with video!

Check out the following video of the presentation over this topic I gave at the March of 2012 Orange County WordPress Meetup. While containing lots of good information, it should be used along with the rest of this post, not as a replacement for.

Creating a simple web based authentication service

We are going to create a simple web based authentication service to use as proof of concept when replacing the built-in WordPress authentication mechanism. Though this service will be simple, it will help illustrate how easy it is to authenticate using other databases, applications, even oAuth. Let's begin.

Create a new PHP file at http://localhost/auth_serv.php with the following contents:

if($_GET['user'] == 'bob' && $_GET['pass'] == 'asdf') {
    echo json_encode(array('result' => '1', 'username' => 'bob', 'first_name' => 'Bob', 'last_name' => 'Jacobsen', 'email' => 'aaben@lobaugh.net'));
} else {
    echo json_encode(array('result' => '0'));
}

The code simply returns a JSON encoded array. This array contains a 'result' element, which is a boolean, holding whether the user is valid or not. This service only support one user with the following credentials:

Username: bob
Password: asdf

Let's talk filters

WordPress allows developers to extend and manipulate virtually all of the system through hooks. There are two types of hooks in WordPress, actions and filters. Actions allow developers to tap into the power of WordPress and create new functionality. Filters allow developers to interrupt the flow of WordPress and alter how it runs. For example, there is a filter called 'the_content'. This filter allows plugins to tap into post content before it is displayed and alter it as deemed fit.

For our purposes we will be using the 'authenticate' filter. Whenever a login is triggered the authenticate filter is hit and custom logic can be applied to it. The filter can be setup with the following code.

add_filter( 'authenticate', 'demo_auth', 10, 3 );
 
function demo_auth( $user, $username, $password ){
    return $user;
}

The demo_auth function will replace the built-in authentication method. The authenticate filter sends along three parameters:

• $user - A WP_User object.
• $username - From the username text box. This parameter is optional
• $password - From the password text box. This parameter is optional

Because we will be using the built-in login box to obtain a username and password to send to our pretend service we will be using the $username and $password parameter. It is important to note that the username and password parameters are not required for this filter to function properly. Why would you not need a username and password you ask? If you are using oAuth to authenticate against another provider, such as Meetup, that site will provide it's own login form to protect user information.

 What to keep in mind when replacing the built-in authentication

WordPress relies heavily on it's built-in user system. Because of this there are lots of references to users in the WordPress database that are made. While slightly annoying, it is still fairly simple to work around these limitations.

WordPress requires that a real user (WordPress user) be present in the WordPress database in order to perform operations on that user. Luckily WordPress contains function to create, manipulate, and delete users. So when we build our service we will actually be taking the following steps, which should be fairly authentication type agnostic:

• Authenticate user via alternate method
  • If invalid user display invalid login message
  • If valid user
    • Check to see if the user exists in the WordPress user table
    • If user exists load and return user data in a WP_User object
    • If user does not exist
      • Automagically create a new user from alternate authentication service user information
      • After creating the user load and return user data in a WP_User object

Enough blabbing, show me the code!

Here is a quick dump of the code. Then I will walk through the more important pieces

function demo_auth( $user, $username, $password ){
    // Make sure a username and password are present for us to work with
    if($username == '' || $password == '') return;
 
    $response = wp_remote_get( "http://localhost/auth_serv.php?user=$username&pass=$password" );
    $ext_auth = json_decode( $response['body'], true );
 
     if( $ext_auth['result']  == 0 ) {
        // User does not exist,  send back an error message
        $user = new WP_Error( 'denied', __("<strong>ERROR</strong>: User/pass bad") );
 
     } else if( $ext_auth['result'] == 1 ) {
         // External user exists, try to load the user info from the WordPress user table
         $userobj = new WP_User();
         $user = $userobj-&gt;get_data_by( 'email', $ext_auth['email'] ); // Does not return a WP_User object <img src='http://ben.lobaugh.net/blog/wp-includes/images/smilies/icon_sad.gif' alt=':(' class='wp-smiley' />
         $user = new WP_User($user-&gt;ID); // Attempt to load up the user with that ID
 
         if( $user-&gt;ID == 0 ) {
             // The user does not currently exist in the WordPress user table.
             // You have arrived at a fork in the road, choose your destiny wisely
 
             // If you do not want to add new users to WordPress if they do not
             // already exist uncomment the following line and remove the user creation code
             //$user = new WP_Error( 'denied', __("<strong>ERROR</strong>: Not a valid user for this system") );
 
             // Setup the minimum required user information for this example
             $userdata = array( 'user_email' =&gt; $ext_auth['email'],
                                'user_login' =&gt; $ext_auth['email'],
                                'first_name' =&gt; $ext_auth['first_name'],
                                'last_name' =&gt; $ext_auth['last_name']
                                );
             $new_user_id = wp_insert_user( $userdata ); // A new user has been created
 
             // Load the new user info
             $user = new WP_User ($new_user_id);
         } 
 
     }
 
     // Comment this line if you wish to fall back on WordPress authentication
     // Useful for times when the external service is offline
     remove_action('authenticate', 'wp_authenticate_username_password', 20);
 
     return $user;
}

Now let's go through some of this code:

• wp_remote_get() - WordPress function that will fetch a remote resource with GET.
• WP_Error - WordPress class to handle when errors occur. The authenticate filter automagically checks WP_Error before allowing login to continue
• WP_User - The WordPress User Class allows accessing properties, roles and capabilities of a specific user.
• wp_insert_user - Inserts a new user into the WordPress database based on the passed in user fields

The remove_action line is of particular importance. If that line exists WordPress will only authenticate based on the external service. If that line were to be commented out WordPress would fall back on the local user table for authentication if external authentication fails.

Additional considerations

WordPress contains several additional hooks that may be important to know about in your situation:

• lost_password - This action allows you to alter how WordPress retrieves lost passwords. If passwords may only be retrieved from the external service developers can use this hook to send users to that service to set a new password
• user_register - Provides access to the user's data after registration. If the external authentication service allows new users to be posted to it this hook will enable developers to easily push the information out
• register_form - Allows developers to extend the user registration form
• retrieve_password - Helps with lost passwords
• password_reset - Helps with lost passwords

In this demo we checked to see if a user exists in WordPress based on the email supplied by the authentication provider, but what happens if that user were to change their email address on the provider's side? Suddenly they would lose all their information stored in the WordPress site, which could include access to all posts and settings. Make sure that whatever method you chose makes sense for your audience and usage patterns. Bad things happen when users think their data has been lost...

And more importantly, what will happen if/when the external provider goes offline? Maybe your service relies on other resources from the external provider and it is ok for your site to be down when theirs is. Generally though you will probably want your service to stay up. If this is the case then you will probably not want to have the remove_action line in the code above. Removing that line will allow WordPress to fallback on it's own user system. However, since most external authentication systems purposefully do not send back a user's password you may need to have the user reset their password on your system, or even when their user is first created have them insert an "emergency" pin to access your site when the external provider is down.

Helpful links

I found the following links helpful while researching this topic. If I do not make sense maybe they will

• http://www.johnkolbert.com/wordpress/how-to-add-your-own-authentication-criteria/
• http://www.blackbam.at/blackbams-blog/2011/06/09/wordpress-custom-external-authentication-loginlogout-php-script/
• http://willnorris.com/2009/03/authentication-in-wordpress-28
• http://codex.wordpress.org

 
function trim_numbers($str) {
    $n = array('0', '1', '2', '3', '4', '5', '6', '7', '8', '9');
    return str_replace($n, '', $str);
}