It’s been a good ride. I did a lot of freelancing over the past several years, learned a lot, met a lot of great people, and had a lot of fun. But a new chapter has come. If anyone wants to pick up any of my WordPress plugins and update them, feel free to fork them.

To all my fellow WordPressers: keep on keepin’ on. The future only looks brighter.

-John

With a little bit of magic, we can get our own text there. Previously this required using javascript to change this text, but 3.1 creates a new ‘enter_title_here’ filter that gives us better control.

To change the default text, simply create a new function and hook it to the ‘enter_title_here’ filter, such as below:

function jk_change_default_title( $title ){

     $title = 'My New Title';

     return $title;
}

add_filter( 'enter_title_here', 'jk_change_default_title' );

For better control, we can use this to only change the title of specific post types. This is great for custom post types. In this example, we’ll use the custom post type of ‘invoice’.

function jk_change_default_title( $title ){
     $screen = get_current_screen();

     if  ( 'invoice' == $screen->post_type ) {
          $title = 'Enter Invoice Title';
     }

     return $title;
}

add_filter( 'enter_title_here', 'jk_change_default_title' );

This is the end result:

Here is the Trac discussion about this.

For a full write up, see the official plugin page or just download it from WordPress.org

Update: The official version of the plugin is up to 2.0.4 (in under 24 hours of initial release), which fixed a fatal error that occurred on activation, a bug in which settings weren’t being transfered properly from v1.3, and a few other minor issues.

Well I’ve been sitting on this one for a long time, mostly due to things being crazy around here (like having a baby, school, yadda yadda). I’m releasing an update to my popular WordPress plugin: Absolute Privacy 2.0 beta 1 is ready for public testing. You can read the change notes below, or just download the .zip file.

What’s Changed?

A lot has changed, but here’s a quick rundown:

• 3.0.x+ required
• Complete code rewrite. I rewrote the entire plugin from object oriented to procedural as this made more sense to me for this plugin. It should be much easier for others to modify and read through the code. No need for overkill here.
• Two different privacy methods: complete lockdown and members area. Complete lockdown functions like the plugin did previously, the entire site will be password protected. Members area allows you protect a specific page (and all subpages).

My To Do List

Unfortunately I didn’t get to everything on my to do list that I wanted. The two major things that are still in the works are  multisite support and translations. The plugin now gracefully notifies the user of the lack of multisite support (rather then just flat out not working and leaving the user to wonder why). I’ve got a good start, but multi-site adds a bit of complexity that I haven’t had time to tackle fully.  These are the big two that I’m working on.

Also on my to do list is to add some actions and filters to allow for additional registration fields and make the plugin all around more extendable to developers.

Download

Absolute Privacy 2.0 beta 1 – .zip (20kb)

Download and unzip the .zip file and place the folder in your /wp-content/plugins/ folder.

Note: Since this plugin release is a beta, I recommend using this on development sites only. Use this plugin at your own risk. Although I believe it to be fairly stable, every server is different, so your mileage may vary.

Report Your Bugs

Beta releases are pointless unless I get bug reports back. Either leave your bugs, comments, or praises in the comments below, or email them to me at j[at]johnkolbert[dot]com.

Beginning with WordPress 2.8, an ‘authenticate’ filter was added which allowed for some flexibility when authenticating a user with out having to completely overwrite the wp_authenticate function. Unfortunately, using this filter wasn’t well documented.

Below is the wp_authenticate function as found in WordPress 3.0.1:

function wp_authenticate($username, $password) {

     $username = sanitize_user($username);
     $password = trim($password);

     $user = apply_filters('authenticate', null, $username, $password);

     if ( $user == null ) {
        // TODO what should the error message be? (Or would these even happen?)
        // Only needed if all authentication handlers fail to return anything.

     $user = new WP_Error('authentication_failed', __('<strong>ERROR</strong>: Invalid username or incorrect password.'));

     }

      $ignore_codes = array('empty_username', 'empty_password');
      if (is_wp_error($user) && !in_array($user->get_error_code(), $ignore_codes) ) {
            do_action('wp_login_failed', $username);
      }
      return $user;
}

The authenticate filter is found on line 6. It passes both the username and the password and assigns the result to $user. This is where we will add our custom authentication criteria. In our case, let’s do something simple. Let’s deny access if the $username is ‘bob’. Of course, you could be more functional and deny access by user role (like Absolue Privacy does), or what have you. In addition, let’s give a meaningful error message so Bob knows what’s going on.

First, let’s hook into the authenticate filter:

 add_filter( 'authenticate', 'my_custom_function', 10, 3 ); 

This is adding the ‘my_custom_function’ to the ‘authenticate’ filter, with a priority of 10, and passing 3 arguments (null, $username, and $password).

Now let’s write our function which will check the username:

function my_custom_function( $user, $username, $password ){

     $user = get_userdatabylogin( $username );  //we don't really need this, but you might

     if( $username == 'bob'  ) {  //if the username is bob

        $user = new WP_Error( 'denied', __("<strong>ERROR</strong>: We do not allow people with the name Bob into this site") );

     }

     return $user;

}

This function simply checks if the username is Bob. If it is, it assigns $user to be a new WP_Error with the name of “denied”. If you were to try this function out now, you’ll notice that someone with the username “Bob” is still allowed to login. Why? Because unfortunately the authentication sequence isn’t aborted if $user is assigned as a WP_Error.

To prevent the authentication sequence from continuing we must remove the username/password authentication action:

 remove_action('authenticate', 'wp_authenticate_username_password', 20); 

With this addtion, our custom function now becomes:

function my_custom_function( $user, $username, $password ){

     $user = get_userdatabylogin( $username );  //we don't really need this, but you might

     if( $username == 'bob'  ) {  //if the username is bob

        $user = new WP_Error( 'denied', __("<strong>ERROR</strong>: We do not allow people with the name Bob into this site") );
        remove_action('authenticate', 'wp_authenticate_username_password', 20);

     }

     return $user;

}

You have now successfully prevented Bob from logging into your WordPress powered site! For a little extra flare, let’s get the login box to shake “NO” when the error message appears. Create a new function below:

function my_custom_error_shake( $shake_codes ){

     $shake_codes[] = 'denied';
     return $shake_codes;
}

This function will add the ‘denied’ $WP_Error that we created into the list of error codes that cause the login box to shake. Finally, we’ll add the following filter if Bob tries to login:

add_filter('shake_error_codes', 'my_custom_error_shake');	//make the login box shake

So with the above addition, our final code looks like this:

add_filter( 'authenticate', 'my_custom_function', 10, 3 );

function my_custom_error_shake( $shake_codes ){
    $shake_codes[] = 'denied';
    return $shake_codes;
}

function my_custom_function( $user, $username, $password ){
    $user = get_userdatabylogin( $username );  //we don't really need this, but you might

    if( $username == 'bob'  ) {  //if the username is bob
        $user = new WP_Error( 'denied', __("<strong>ERROR</strong>: We do not allow people with the name Bob into this site") );
        remove_action('authenticate', 'wp_authenticate_username_password', 20);
        add_filter('shake_error_codes', 'my_custom_error_shake');	//make the login box shake
     }

     return $user;
}

Entering Code Into the Comments

People like to share code in comments. But, come on, it NEVER works! So I’ve made it easy to share code. Simply click on the “Entering Code?” link when commenting, and a popup will let you enter your code in, submit it to PasteBin, and automatically put the link into the comments. No more messy code not playing nice any more!

New Page For My Projects

All of my project pages have been redesigned. What do you think? Are they easy enough to use? I’ve done this in preparation of sharing additional info about a special project I’ve been working on for some time.

Finally

So, what do you think? A good change? I’d like to especially thank The Webcrafters, a fantastic duo who came up with this design for me. I’ve used them for other projects and am always pleased with their high quality, reasonably priced work.

In the next few days I’ll be publishing a post detailing how I accomplished a lot of the things with the redesign (PasteBin API, custom post types, and more!). Thanks everyone!

Version 1.3 bring the following additions:

• added ability to control RSS feeds. Feeds can be disabled, enabled, limited to headlines, or limited to a predefined number of characters
• added ability to allow non-logged in users to view specific pages
• added ability to redirect non-logged in users to the login screen OR any page or post
• added ability to customize email notification messages
• minor bug fixes
• full compatibility with WordPress v2.9

Download it at the official WordPress plugin repository, or read more at its homepage here.

Note: This article is about a development version of WordPress (3.0 alpha). Although the techniques presented here are likely to be valid in the publicly released version, please test this on a development site first.

For this project, I needed each new site to automatically have an additional table created that would hold information for the plugin I’m working on. The key is to tap into the wpmu_new_blog action, which fires directly after a new site is created.

The wpmu_new_blog action runs at the end of wpmu_create_blog(), a function located in /wp-includes/ms-functions.php which creates the new site. The action is passed two variables: $blog_id, which is the ID of the newly created site, and $user_id, which is the ID of the administrator of the site.

Here’s my finished code:

function nt_installTables($blog_id){
	global $wpdb;

	$table_name = $wpdb->get_blog_prefix($blog_id) . 'mytable';

		$sql = "CREATE TABLE ". $table_name ."  (
                    ID bigint(20) unsigned NOT NULL AUTO_INCREMENT,
                    table_id varchar(20) NOT NULL,
                    page_id text NOT NULL,
                    html text NOT NULL,
                    snippet bigint(20) NOT NULL,
					UNIQUE KEY ID (ID)) CHARSET=utf8;
                    ";

		require_once ABSPATH . '/wp-admin/includes/upgrade.php';

		dbDelta($sql); //do it

}

add_action('wpmu_new_blog', 'nt_installTables');

Don’t forget you can also pass $user_id to your function.

If you’d like to change how often the trashed information is removed, simply open up wp-config.php and define the following constant:

define('EMPTY_TRASH_DAYS', 15 );  // 15 days

Just change 15 to the frequency in days that you want WordPress to empty the trash. It’s that simple!

What is MammothApps? From the about page:

“MammothApps is a WordPress development studio owned and operated by John Kolbert. Based out of Minneapolis, MN, MammothApps’ typical clients are looking for medium to large scale custom plugins or websites that require advanced functionality (such as e-commerce, or social networking). However, MammothApps offers a wide range of WordPress-related services.”

Why, you may ask?

Put simply: growth. I’ve been blessed to be much busier then I expected with client projects. So much so, in fact, that I haven’t updated this website in four entire months. With MammothApps, I’m branching out. I’m officially declaring: I mean business. I’ve networked with several other talented developers who will be providing support and skills on larger scale projects overseen by MammothApps. We’ll be focusing primarily on larger scale (maybe even, mammoth?), custom plugins and applications, all built on WordPress. All of my WordPress-related developing will occur through the MammothApps studio.

JohnKolbert.com will become entirely my personal blog. All references to my former freelance consulting services have been removed or redirected to the MammothApps homepage.

I’ll hope you join me over at MammothApps. In addition to client work, we’ll be publishing a series of  advanced WordPress tutorials, called MammothTips each month, as well as releasing some pretty awesome WordPress based web applications (details forthcoming).