New cool WordPress setup tool is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

And here we go again another debacle, at least I think so. Some people in the WordPress world get away with stuff that others don’t.

Introducing JetPack

JetPack requires the users to create an account on WordPress.com and register their sites with WordPress.com before the plugin becomes active.

The plugin even gives the impression that all its features require WordPress.com to be able to work.

JetPack is nagging, with a HUGE box

The problem with all this is that not all the plugin features requires access to the WordPress.com API.

The following features are standalone i.e does not require WordPress.com integration:

• Sharedaddy
• Twitter Widgets
• Gravatar Hovercards
• After The Deadline
• Shortcode embeds
• LaTeX

The only features that actually make use of WordPress.com are Stats and WP.me shortlinks. So we have six features that do not require WordPress.com and just two that do.

In my opinion WordPress.org should require the plugin authors, ie Automattic et al, to remove the requirement for WordPress.com registration for features that don’t actually require it.  You might ask why, well not doing so is in my opinion hypocritical. Others have not been allowed to have plugins that uses “optin for no reason” in the WordPress plugin directory, why should this plugin be allowed too?

Is the JetPack way a good user experience? Is this a practice that should be allowed in the WordPress.org plugin/theme directory?

Voice your opinion in the comments.

JetPack: WordPress.org hypocrisy or how power gets you perks? is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

Also the way link click goal tracking works has been changed a little since Google recommends a different way to track now.

Download version 11.1.1

Testversion of new GWO 4 WordPress is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

DHH on “Why Ruby?” Wheres a “Why PHP?” speach? is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

• Default
• Aside
• Chat
• Gallery
• Link
• Image
• Quote
• Status
• Video
• Audio

Wonder what Aside is. Is it posts that will be put a side (kind of pointless) or be used in a sidebar or what? Stupid name none the less.

The Final WordPress 3.1 Post Formats is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

To see the end result directly view the video below. (Sorry about the lack of sound it didn’t record.) Most is self explanatory except for the last 30 sec or so. In the end of the video I show how you can extend a default post format with your own by selecting a default one first updating and then selecting a custom one.

Getting the right hooks

So what is it we want to do?

1. Select a custom post format
2. Store it
3. Make it visible in admin under posts (So we see which of our posts have a post format)
4. Style posts using it

But first things first

We begin by defining our custom post states.

// Define our custom post formats.
global $custom_post_formats;
$custom_post_formats=array('image', 'article', 'audio', 'media', 'code');

1) Select a custom post format and 2) store it

This is the most complicated one. We want to add our post formats to WordPress default ones and store the selected one when we save our post.

We want our hooks to be added when we are admin mode.

 add_action('admin_init','custom_post_format_admin');

To be able store store our selected post format we make use of a meta box and we need to save its values so we hook into the save_post action.  We also require some custom JavaScript so we hook into admin_footer-post.php and post-new.php.

function custom_post_format_admin(){
  add_meta_box('custom-post-formats', 'Custom Post Formats', 'custom_post_formats_field', 'post');
  // want to save our custom post stuff. Standard meta box code
  add_action('save_post', 'custom_post_formats_save');
  // add our jquery code to modify the default postformat listing.
  add_action('admin_footer-post.php','print_custom_format_script');
  add_action('admin_footer-post-new.php','print_custom_format_script');
[...]
}

The magic custom post format (Point 1)

This is the biggest and most complex function of them all. This is the function that is run when the admin_footer action is run. We begin by defining our function print_custom_format_script() and get the current post format. We define this in next section (Point 2a) we are just thinking ahead.

function print_custom_format_script(){
  global $post;
  $current_postformat=get_post_meta($post->ID, '_custom_post_format', true);

Next we retrieve our custom post formats and make an array of them formated in HTML, radiobutton and label element. This is how post formats are written in the HTML on the post new and edit post pages. We also check if the $current_post_format matches any of our custom post formats and if it is we check our radio button (Line 5).

  global $custom_post_formats;
  //generate a list with the custom postformats in HTML tag format.
  foreach($custom_post_formats as $postformat)
  $postformats[]='\'<br /><input type="radio" name="post_format" class="post-format" id="post-format-'.$postformat.'" value="'.$postformat.'"'.
($postformat==$current_postformat?'checked="checked"':''). '>\'+
\' <label for="post-format-'.$postformat.'">'. ucfirst($postformat) .'</label>\'';
?>

Next up is the JavaScript. Explanation is found in the comments. If the $current_postformat matches one of our $custom_post_formats. Set so it is shown in the post format menu on post.php/post-new.php.

<script type="text/javascript">
  (function ($){
<?php if(in_array($current_postformat,$custom_post_formats)):?>
    $('#post-format-display').text('<?php echo ucfirst($current_postformat); ?>');
<?php endif

Below we find all label elements that has a “for” attribute that begins with post-format and select the “:last” one. We then add our postformats after that element.

  // Add our custom postformats to the postformat radio button list
  ?>
  $('label[for^=post-format]:last').after(<?php echo implode('+',$postformats) ?>);

Well adding our custom post formats to the radiobutton list is all fine and dandy by pretty pointless if we don’t save the value.
When we click the Ok button(save-post-format) in the Post Format box store the selected radio button value in our hidden custom field (See Point 2a). Return true so the default WordPress script is not interrupted.

  $('.save-post-format').click(function(){
    postformat=$('input[name=post_format]:checked').val();
    $('#custom_post_format').val(postformat);
    return true;
    });
  })(jQuery);
</script>
<?php
}

The result looks like this.

Our simple meta box (Point 2a)

Our metabox consist of a hidden input field (custom_post_format that we used in the JavaScript) and a security nonce. Can’t skip on the security. I prefix the post meta key with “_” so it does not show in the “Custom Fields” section on posts. Doing that is ugly and some themers should STOP doing it.

// Our meta box.
function custom_post_formats_field(){
  global $post;
  wp_nonce_field('save_custom_post_format',  'custom_post_format_nonce');
  $postformat=get_post_meta($post->ID,  '_custom_post_format', true);
  // We don't want the custom post format to be visible since thats ugly.
  echo '
';
}

Storing the meta value (Point 2b)

Here we first verify our nonce so nothing fishy is going on (Line 4). Next we make our custom post formats available (Line 6). Then we retrieve our input field we defined in our meta box function (Line 7) and check if the post format is in our predefined array(Line 9) and if is we store it and if its not we store a blank value.

//Save the custom post format
function custom_post_formats_save($post_id){
  // Security stuff
  if (!wp_verify_nonce( $_POST['custom_post_format_nonce'], 'save_custom_post_format'))
    return $post_id;
  global $custom_post_formats;
  $postformat=$_POST['custom_post_format'];
  /* if the post formats has been defined by us.*/
  if(in_array($postformat,$custom_post_formats))
    //Store it
    update_post_meta($post_id, '_custom_post_format', $postformat);
  // if its a default postformat or someone else is interferring with our stuff
  else
    // save a blank postformat
    update_post_meta($post_id, '_custom_post_format', '');
}

3) Make it visible in admin under posts.

To do this we need a filter called display_post_states. Add this code to the custom_post_format_admin() function.

  // The filter for post states on the posts admin page, shows on the right of the post title.
  add_filter('display_post_states', 'custom_format_display_post_states');

We also need the custom_format_display_post_states function (puh long name). Here you can also remove the default WordPress post formats, I decided to keep them as you see in the video.

function custom_format_display_post_states($poststates){
  global $custom_post_formats;
  global $post;
  // Get the custom post format for the current post listing (in posts.php)
  $postformat=get_post_meta($post->ID, '_custom_post_format', true);
  //if the postformat is set
  if($postformat)
  // add it to the poststates listing.
    $poststates[]='<span>[</span>'.ucfirst($postformat).'<span>]</span>';
  return $poststates;
}

The result is this if you have selected the image post format:

4) Style posts using it

  add_action('init','custom_post_format_testing_init');
function custom_post_format_testing_init(){
  // We want to be able to filter post classes so we can add our custom post formats
  add_filter('post_class','custom_post_format_class');
}
//Add our custom post format class to the posts classes
function custom_post_format_class($classes){
  global $post;
  $postformat=get_post_meta($post->ID, '_custom_post_format', true);
  // If postformat has a value
  if($postformat)
    // Check so the postformat is not already added to classes.
    if(!in_array($postformat,$classes)){
    //Remove the default postformats if in postformat extend mode. Can keep if you want to.
    $classes=array_diff($classes,array('format-gallery','format-aside'));
    // Add our custom post format class.
    $classes[]="format-$postformat";
  }
  return $classes;
}

Here you find the complete plugin code.
Demoplugin: https://gist.github.com/708931

Have fun with your new knowledge.

Extending WordPress 3.1 Post Formats is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

Well luckily giving the impression of Post Formats is really simple. All you need is the right filter. In this case display_post_states. In my example I’m using tags to check for a post format but you can use category, metakey, custom taxonomy etc.

add_action('init','post_format_testing_init');
function post_format_testing_init(){
    add_filter('display_post_states',
               'custom_format_display_post_states');
}
global $custom_post_formats;
$custom_post_formats=array('image','article','audio','media');
function custom_format_display_post_states($poststates){
    global $custom_post_formats;
    global $post;
    $tags=get_the_tags($post->ID);
    if($tags)
        foreach($tags as $tag)
            if(in_array($tag->slug,$custom_post_formats)){
                $poststates[]="[$tag->slug]";
                break;
            }
    return $poststates;
}

The above code yields the following result:

Go ahead and add this to your themes for a better user experience. I know at least one premium theme provider could use it.

PS
With a little jQuery (input[@name=post_format]:change + some other stuff) and a hidden custom field you can most likely extend the upcoming default post formats with your own and have it nicely integrated with the default Post Format list. So no need for the user to add tags, categories etc to select a Post Format. But more on that in another post.

Really Simple Custom Post Formats is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

So what exactly did they do?

They, as Joost De Valk wrote on his blog, took advantage of WordPress automatic updates and created an empty plugin on WordPress.org with a higher version number than BlogPress SEO. WordPress then displays that there is an plugin update available and when people download it BlogPress SEO gets its essence removed. This only works since BlogPress SEO didn’t disable automatic updates. In other words WordPress.org has been used to try and kill of a plugin that people did not like.

So what does the worms represent?

Well they represent as I see it 3 questions that the WordPress Community needs to deal with.

1. Should WordPress.org be used to try and disable plugins/themes?

This is really the big question. And I think a lot of people will say yes but to me this goes beyound the nature of the project and into ideology. The very essence of open source projects is to give end users power over their software, a killswitch would essentially take away power from the enduser and give more power to the project leadership.

One of the arguments for GPL is that it empowers the end user to take control over the software they use, killswitch removes power from the ordinary enduser. Would a killswitch be inline with the ”spirit of the GPL” that GPL advocates love to throwaround?

2. What criterias needs to be met for doing so?

So assuming we answered Yes on the previous question what criterias should plugins and themes have to meet inorder to be killed off by remote control?

If you’re a WordPress GPL conformist you would say one criteria is: Plugins and themes that does not conform to the GPL. But I won’t say that since I hope no one is so stupid that they would actually do something like that. Not that this criterias hasn’t crossed my mind given the attitude in certain parts of the community with regards to the GPL.

On a more serious note the criteria would be: The plugin/theme purposely creates a backdoor. That is gives access to people that is not suppose to have access to the WordPress site. Why purposely? Well security holes is to be dealt with by contacting the author of a theme/plugin regardless of the plugin/theme license.

3. And who decides which plugins/themes that should be killed?

Yes the management question. Who is in charge of what? Would it be up to the core devs? Matt? Plugin/Theme reviewers etc? I have no answer to give on this question. All choices will be wrong for some people.

So what do you think? Should WordPress.org take the step and introduce a plugin/theme killswitch?

** Update **
Andrew Nacin was not made aware of the purpose of Joosts plugin, so the removal of BlogPressSEO was not sanctioned from above.
You should keep an eye on Joosts De Valks blog for more interesting news regarding wp.org.

WordPress.org introduces a killswitch? is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

Weekly Digest for November 9th is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop

Weekly Digest for November 2nd is a post from: Andreas Nurbo Check out my awesome plugin for affiliate marketers:WP Affiliate Shop