grappler

<?php
// add ie conditional html5 shim to header
function _s_add_ie_html5_shim () {
    echo '<!--[if lt IE 9]>';
    echo '<script src="' . get_template_directory_uri() . '/js/html5.js"></script>';
    echo '<![endif]-->';
}
add_action('wp_head', '_s_add_ie_html5_shim');

chriscoyier

How WordPress Plugins Should Handle Front End Resources

This is a WORK IN PROGRESS intended for fleshing out and feedback

It's very common for people to be unhappy with how a WordPress plugin adds front end resources to their site. If a plugin needs CSS, the plugin will add a <link> element to that CSS. If the plugin needs JavaScript, it will add a <script> to that JavaScript.

Plugins do this because it works. It's damn important for a WordPress plugin to work, even in adverse conditions. They rightfully want good ratings and little customer support.

But this comes at the cost of additional HTTP requests. In optimizing front end performance of a site, reducing the number of HTTP requests is a huge thing. Front end developers want to decide and control how front end resources are being handled, and WordPress plugins don't typically make this easy on them.

GaryJones

<?php

add_theme_support( 'html5', array( 'search-form', 'comment-form', 'comment-list', 'gallery', 'caption' ) );

justintadlock

<?php

# Register custom post types on the 'init' hook.
add_action( 'init', 'my_register_post_types' );

/**
 * Registers post types needed by the plugin.
 *
 * @since  1.0.0
 * @access public

paulruescher

/**
 * Extend Recent Posts Widget 
 *
 * Adds different formatting to the default WordPress Recent Posts Widget
 */

Class My_Recent_Posts_Widget extends WP_Widget_Recent_Posts {

	function widget($args, $instance) {