The WordPress.com stats helper monkeys prepared a 2012 annual report for this blog.
Here’s an excerpt:
4,329 films were submitted to the 2012 Cannes Film Festival. This blog had 22,000 views in 2012. If each view were a film, this blog would power 5 Film Festivals
Here’s a short code snippet you can use if you want your date to be displayed as “Today”, “Yesterday” or “X days ago”. To accomplish this, simply add a filter to the_date.
In my example it shows “X days ago” if it less than 7 days old. Short and sweet!
function mytheme_the_date( $date ) {
$time = strtotime( $date );
$difference = time() - $time;
$days_ago = (int)( $difference / 60 / 60 / 24 );
if ( date( 'Y-m-d' ) === date( 'Y-m-d', $time ) )
return __( 'Today' );
elseif ( date( 'Y-m-d', strtotime('-1 day') ) === date( 'Y-m-d', $time ) )
return __( 'Yesterday' );
elseif ( $days_ago < 7 )
return sprintf( __( '%d days ago' ), $days_ago );
return $date;
}
add_filter( 'the_date', 'mytheme_the_date' );
Happy coding!
There is many ways to pass dynamic variables to JavaScript. An easy way would be just to define the JavaScript variables in the <head> echoing the PHP variables.
This will of course work, but there is a WordPress-way to do it as well.
The function wp_localize_script gives you the ability to write a JavaScript object with multiple variables defined. The function must be called after your script has been enqueued. Simply pass in the name of your script handle, the object name and your data.
function mytheme_wp_enqueue_scripts() {
wp_enqueue_script( 'mytheme_script', get_template_directory_uri() . '/js/main.js', array('jquery'), false, true );
wp_localize_script( 'mytheme_script', 'myObj', array(
'homeUrl' => home_url(),
'translatableString' => __( 'A String' )
) );
}
add_action( 'wp_enqueue_scripts', 'mytheme_wp_enqueue_scripts' );
This will print the following code before your script is included
<script type='text/javascript'>
/* <!--[<span class="hiddenSpellError" pre=""-->CDATA[ */
var myObj = {"homeUrl":"http:\/\/forsakringskassan.dev","translatableString":"A String"};
/* ]]> */
</script>
Then you are free to use the variable in your JavaScript in which ever way you want!
alert(myObj.translatableString)
That’s all — Happy coding!
If you would want to write a phrase in single or plural form depending on a number, there is a very handy function for it written in WordPress called _n. The function also takes a $domain argument which can be handy when localizing plugins or themes.
In your search template you might want to print “Found X results matching your query”. When X is above 1 you want to write “results” but if there only was a single result found you would want to write “result”.
This can be accomplished with the following code:
<?php printf( __( 'Found %d %s matching your query: %s' ), $wp_query->found_posts, _n( 'result', 'results', $wp_query->found_posts), get_search_query() ); ?>
I recently discovered Jigoshop. A very nice, lightweight and well coded e-Commerce plugin for WordPress.
After some experimenting I found that the checkout and it’s fields for billing and shipping information where defined in the code and could not be modified in the settings.
It was a problem since they had set State as a required field, which most countries outside of US don’t have. In their forums there were many threads regarding this subject, and the answer the support staff gave was to modify the plugin files (!!) which you never should do.
So here’s an update safe to do it.
Create a plugin or add this to your theme’s functions.php
function jigo_mod_wp() {
if ( class_exists( 'jigoshop_checkout' ) ) {
$billing_fields = array(
array( 'name'=>'billing-first_name', 'label' => __('First Name', 'jigoshop'), 'placeholder' => __('First Name', 'jigoshop'), 'required' => true, 'class' => array('form-row-first') ),
array( 'name'=>'billing-last_name', 'label' => __('Last Name', 'jigoshop'), 'placeholder' => __('Last Name', 'jigoshop'), 'required' => true, 'class' => array('form-row-last') ),
array( 'name'=>'billing-address', 'label' => __('Address', 'jigoshop'), 'placeholder' => __('Address', 'jigoshop'), 'required' => true ),
array( 'name'=>'billing-city', 'label' => __('City', 'jigoshop'), 'placeholder' => __('City', 'jigoshop'), 'required' => true ),
array( 'validate' => 'postcode', 'format' => 'postcode', 'name'=>'billing-postcode', 'label' => __('Postcode', 'jigoshop'), 'placeholder' => __('Postcode', 'jigoshop'), 'required' => true, 'class' => array('form-row-first') ),
array( 'type'=> 'country', 'name'=>'billing-country', 'label' => __('Country', 'jigoshop'), 'required' => true, 'class' => array('form-row-last') ),
array( 'name'=>'billing-email', 'validate' => 'email', 'label' => __('Email Address', 'jigoshop'), 'placeholder' => __('***@yourdomain.com', 'jigoshop'), 'required' => true )
);
jigoshop_checkout::instance()->billing_fields = $billing_fields;
$shipping_fields = array(
array( 'name'=>'shipping-first_name', 'label' => __('First Name', 'jigoshop'), 'placeholder' => __('First Name', 'jigoshop'), 'required' => true, 'class' => array('form-row-first') ),
array( 'name'=>'shipping-last_name', 'label' => __('Last Name', 'jigoshop'), 'placeholder' => __('Last Name', 'jigoshop'), 'required' => true, 'class' => array('form-row-last') ),
array( 'name'=>'shipping-address', 'label' => __('Address', 'jigoshop'), 'placeholder' => __('Address', 'jigoshop'), 'required' => true ),
array( 'name'=>'shipping-city', 'label' => __('City', 'jigoshop'), 'placeholder' => __('City', 'jigoshop'), 'required' => true ),
array( 'validate' => 'postcode', 'format' => 'postcode', 'name'=>'billing-postcode', 'label' => __('Postcode', 'jigoshop'), 'placeholder' => __('Postcode', 'jigoshop'), 'required' => true, 'class' => array('form-row-first') ),
array( 'type'=> 'country', 'name'=>'shipping-country', 'label' => __('Country', 'jigoshop'), 'required' => true, 'class' => array('form-row-last') ),
array( 'name'=>'shipping-email', 'validate' => 'email', 'label' => __('Email Address', 'jigoshop'), 'placeholder' => __('***@yourdomain.com', 'jigoshop'), 'required' => true )
);
jigoshop_checkout::instance()->shipping_fields = $shipping_fields;
}
} add_action ( 'wp', 'jigo_mod_wp' );
Modify the array and add/remove the fields you want. Some of the items have an array item called required which controls whether a field is required or not.
Always fun to see great plugins that also are pluggable which is a MUST for it to be useful for developers.
In a collaborative programming environment it is always good to have a set of coding standards that you follow.
Thankfully, WordPress have coding standards which all developers should try to follow.
If you peek at the WordPress source you will notice that (almost) all code follow this standard, which makes it very easy for other developers to read the code.
Take a look at the section discussing shorthand PHP tags, an issue I have written about previously. Space usage is also a very common mistake among developers. The correct space usage can really improve your code’s readability.
Further reading:
Codex: WordPress Coding Standards
I have used Custom Post Types in almost every WordPress project I have worked on since the feature was introduced in WordPress 3.0.
When collaborating with other developers you also come across some common mistakes, mistakes that I’ve also made in the past. So I would like to share some things to keep in mind when using Custom Post Types.
The $post_type should always be singular
The codex does not explicitly say it anywhere, but all the Codex examples use singular names for $post_type. This is probably the most common mistake I see developers make. If you want the new post type’s URL to have a plural word in it, you can specify it in the slug argument.
Use a namespace for your post types
This is something that even I haven’t done. But the codex makes a good point in their own best practices section. A conflict can occur between theme and plugin post types if you use a common word as the post type name and it is not prefixed with a namespace. So for instance if your post type is a product, do not simply name is product but rather yournamespace_product.
Remember the template hierarchy when creating specific post type templates
WordPress template hierarchy is great, so please use it! I have seen cases where developers have created a new page with an associated template where they query for the posts instead of simply using the default template file to create an archive page for example.
From the codex:
In the same way that posts are shown on their own page with single.php, custom post types will use single-{posttype}.php if it’s available.
Same thing applies to archive-{posttype}.php. This visual overview of the template hierarchy is something I keep referring to.
Adding custom columns to the admin can be easy!
Joost De Valk provides these code snippets that can come in handy when working with custom post types. Often you also have custom taxonomies or other meta data linked to your post types which you might want to present in the admin. Great post!
This will surely be the event of the year (as far as WordCamp events go).
WordPress Quick Tips 