Are you an aspiring WordPress developer? Are you ready to take the next step and start building your own custom plugins for WordPress? Our newest Tuts+ Live Workshop is the perfect way to get started!
Early Bird tickets are half-price at only $49, but places are strictly limited so act fast to make sure you don’t miss out!
Introduction to WordPress Plugin Development
Our newest Tuts+ Live Workshop, Introduction to WordPress Plugin Development, teaches you everything that you need to know to start developing WordPress plugins; from setting up a local development environment, all the way through to building a WordPress plugin that’s ready for release into the WordPress Plugin Repository.
It’s led by Instructor Tom McFarlin, a self-employed WordPress developer who divides his time between running his own WordPress development shop, building plugins for WordPress, blogging every day about software development in the context of WordPress, and working for 8BIT (the team responsible for Standard Theme and WP Daily).
Each weekly workshop will last one hour, running over a five week period. You’ll have the opportunity to follow along with Tom, ask questions live during the workshop, and complete a weekly homework assignment. Not able to make it to the live recording? No problem! All of the workshop recordings will be made available online the day after the live workshop.
We’re offering a special Early Bird price of $49, but these tickets are limited. Once the Early Bird tickets have disappeared, the workshop will be $99.
If you’re interested in future workshops then definitely join the Tuts+ Live Workshops mailing list to stay posted on upcoming workshops and get notified as soon as they’re available, the Early Bird tickets for our previous workshops have all sold out, so it’s worth getting ahead of the game!
This offer ends soon! Act now and don’t miss out on cash back when trying a monthly Tuts+ Premium subscription.
At $19 a month, Tuts+ Premium is fantastic value. But it’s even better when we hand your first $19 right back to you!
For a limited time we’re offering $19 cash back to new Tuts+ Premium monthly subscribers when signing up via PayPal. If you’ve been thinking about checking out our extensive library of courses, tutorials, eBooks and guides there’s never been a better time to join up and dive in.
This offer ends at noon on the 20th of May AEST, so act fast.
/> What can you learn on Tuts+ Premium? Glad you asked! Currently, more than 15,000 members are sharpening their skills in a wide range of areas including web design, web development, Photoshop, vectors, video effects, and many more.
With Tuts+ Premium you learn from expert instructors in every field, such as:
Designer Justin Maller (Nike, Verizon, DC Shoe Co.)
Illustrator Russell Tate (McDonald’s, Coca-Cola)
Developer Burak Guzel (Software Engineer at Facebook)
Join now and get instant access to your very own library of courses, tutorials, and eBooks, available whenever you need them. Become part of a community of over 15,000 members and start getting better at the skills you care about. Our dedicated team adds new content weekly, so there’s always something fresh to sink your teeth into.
WordPress has a sufficient, mostly responsive, back-end and great applications for mobile devices, but there might come a day when you’ll just want to send an email to post an entry to your website.
In this post, we’re going to go through this handy little feature of Jetpack: Post by Email.
WordPress has a Post via Email functionality in its core, but it’s far from being handy or user friendly.
As the Codex says, you have to:
Create a dedicated e-mail account to be used solely for posting to your blog
Configure WordPress to access that account via POP3
Configure WordPress to publish messages from that e-mail account
And even if you do, you’re stuck with plain text posts and you can’t post any email attachments!
Plus, you have to at least set up a function in your theme (or as a separate plugin) for WordPress to recognize your email as a post. Oh, did I mention that you can only select one category to post and you can’t set any tags or any other kind of taxonomy?
Luckily, this problematic approach can be replaced with Jetpack, another creation from Automattic. The Post by Email module solves all the problems above and allows you to do lots more. In short, you can:
Use HTML in your email
Include attachments (and include the attached images as a slideshow or an inline gallery)
Set a title (and a slug) different than your email title
Set categories and tags
Turn on or off comments for the post
Set an excerpt
Change the status of the post
Set a password for the post
Set a time for the post to be published
Add <--more--> and <--nextpage--> tags inside the post
End your post anywhere inside your email
Include a PollDaddy poll
Turn off geotagging
Set Publicize options, another module of Jetpack
You need to do a bunch of things with Jetpack, too:
Connect your website with your WordPress.com account
Check if the “Post by Email” module is enabled
Go to Users » Your Profile and click on “Enable Post by Email”
Get the special email address and add it to your address book
Notice that you don’t even have to use your keyboard while taking these steps – except, maybe, entering your WordPress.com credentials. After doing these in order, you’re ready to send your first post via email!
Now that you’re all set on your WordPress admin panel, you can now log in to your email account – the one you’re registered with WordPress.com. With your first post (and all others, naturally), you can use the following shortcodes anywhere inside your email:
Title: [title Hello World!]
Parameters: The specified title.
If you want to send an email with a different title than the title of the post, you can use this shortcode to set a title for the post. If this shortcode is used, Jetpack will disregard the title of the email.
Slug: [slug oh-hai]
Parameters: The specified slug.
The usual “slug”, the words on the address bar. You can use this shortcode to use shorter URLS like myblog.com/hawaii-trip/ and avoid huge ones like myblog.com/a-trip-to-hawaii-what-i-expected-to-see-and-what-i-saw/.
Categories: [category News, Personal]
Parameters: Comma separated category names or IDs.
You can set any category you want with this shortcode. Just use names or IDs as parameters and you’re good to go! It even gets the right category when you don’t use the full name, like “Anno” instead of “Announcements”.
Tags: [tags lorem, ipsum, dolor]
Parameters: Comma separated tag names.
Like categories, you can use tag names
P.S. As far as I can see, it doesn’t support custom taxonomies, which is a bummer. It would be great if a [tax] shortcode is introduced and used like this: [tax custom-taxonomy]lorem, ipsum, dolor[/tax] (where the default parameter is “tag”). Let’s hope the module will support this in the future .
Comments: [comments off]
Parameters: “on” or “off”.
No need to explain this one: You can turn on or off comments on your post with this shortcode.
Post Status: [status private]
Parameters: “publish” (default), “private”, “pending” or “draft”.
Again, this is self-explanatory: You can set the four parameters to set the status of your post.
Post Password: [password CorrectHorseBatteryStaple]
Parameters: The specified password.
You can protect your post with a password with this shortcode.
Parameters: a date/time description like “+1 week 2 days 3 hours” or “next Saturday” or “25 November 2013″.
Using the strtotime format, you can set the date and time of your post. If you set the parameter to “+2 hours”, your post will be published 2 hours after you send the email.
If you’re using the “excerpts” of WordPress posts on your website, you can set an excerpt between [excerpt] and [/excerpt] tags.
Geotagging: [geotag off]
Parameters: “on” or “off”.
If your phone (or email client) is using your GPS information inside the emails, geotagging will be enabled by default. If you don’t want to share that information on your posts, you should disable it by using this shortcode with the parameter “off”.
Publicize: [publicize facebook twitter]
Parameters: Space separated list of services (like Facebook and Twitter) or “off”.
Jetpack has another useful module called Publicize, letting you share your post automatically on social networks when it’s published. If you want to do the same with email, you can use this shortcode to Publicize your post.
Separating Content: [more] and [nextpage]
These two are also self-explanatory: If you ever need to use the <--more--> or <--nextpage--> tags inside your post, you can use these shortcodes.
Attachments: [slideshow] and [noslider]
By default, Jetpack will include your image attachments in the post. If you attach just one image, it will be displayed inline and if you attach more, all of them will form a gallery.
If you don’t like this behavior, you can use [nogallery] to display all images inline or use [slideshow] to replace the gallery with a slideshow.
PollDaddy Polls: [poll]
Parameters: “type” (single, multi or a number), “style” (manga or medium), “other” (yes or no).
If you have a PollDaddy account, you can use this shortcode to include a poll inside your post. Here’s an example on how to use it:
[poll type="3" style="medium" other="yes"]
What are your favorite Tuts+ blogs? (select three)
The End: [end]
There could be email signatures you can’t remove (company policy, hmpfh) or your smartphone could add lines like “sent from myPhone” (that company‘s policy, hmpfh) and you wouldn’t want these signatures to be included in your post.
Jetpack automatically cuts out the text after a signature block or an tag, but you can use [end] alternatively to end the post right where you use it.
I always thought that the core “post via email” feature of WordPress was too much limiting, kind of redundant and absolutely hard to use. Now that we went through everything Jetpack’s “Post by Email” module can do, I’m glad that there’s an alternative to it, also developed by Automattic.
What do you think about this feature – do you plan to use it? Share your comments below and don’t forget to share the post!
Original from: http://feedproxy.google.com/~r/Wptuts/~3/WURiTYuWW14/
Unless you’re hiding your identity on purpose and your readers know it, they will always be wondering about the author of the content you serve. Not just the name – they will care about who you are and where they can reach you.
In this post, we’re going to learn the importance of the “Author Info” section.
“Author Info” to Introduce the Intelligence
“This a brilliant / terrible post! I wonder who wrote this…”
This is what people think when they read a great article (or an awful one). As long as the content isn’t boring, your audience would very much like to get to know about you or your authors.
It doesn’t matter if you’re blogging solo or together with other authors: You should promote yourself! I can’t tell you how I felt when I realized that I missed the chance to offer my short biography to my audience … for seven years of blogging!
For the sake of minimalism, I always chose not to display a little picture of me with some useful information like my social media accounts or even a simple sentence about who I am, with a link to my “About” page. Don’t make the mistake I did and put an Author Box under your posts today!
Displaying an “Author Info” Vox
I could put together some lines of code or introduce a plugin, but Will Wilson recently wrote a fantastic article about building a custom “Author Info” box.
Check it out:
“On sites like Wptuts+ you get to read articles from a massive team of writers and bloggers, we all have our own writing style and personalities. Like Wptuts+, on most multi-author sites, you will find a nice little author information box somewhere on the page. Today I’m going to show you how you can create one for your very own site.”
The next major release of WordPress is already around the corner. This is a big one for theme authors with a major focus on post formats. There’s a new post formats UI for the WordPress end-user, along with a new system of handling and displaying this data in our themes. In this article, I’ll cover what you need to know as a theme author for post formats in the upcoming WordPress 3.6.
In terms of recent major WordPress releases, 3.3 made some significant improvements to the overall admin interface, 3.4 introduced the theme customizer, and 3.5 incorporated a new way for users to manage media. If you’re an author with themes currently out there, you’ve probably been pretty comfortable with these last few major releases and haven’t had to do much in terms of updates or customer support. However, this might not be the case with WordPress 3.6.
The big focus of 3.6 is on post formats. Post formats were introduced back in 3.1, but until now, have always come with quite a bit of inconstancy. Everyone has a different take on post formats and they seem to be more or less popular in different circles of the WordPress community, and with different types of themes.
Whether you’re a fan or not, WordPress has taken a bold, new stance on post formats. So it’s time to start thinking about them in your theme designs, no matter what kinds of WordPress themes you’re creating, or whether you’re already incorporating them or not. Although you should always be doing this, at a minimum, this is one of those major WordPress releases that you’ll really want to test with your themes before it gets officially released.
As a WordPress theme author, you’ll want to understand the new post formats UI that’ll potentially be presented to the end-user, how this corresponds to the new concept of structured post formats, and all of the new theme functionality 3.6 introduces for post formats.
Hopefully, this article will encourage you to take an early look at WordPress 3.6 beta, start working with post formats, and get things rolling with your themes before it hits the masses.
Post Format UI
The first thing WordPress end-users are going to notice when updating to WordPress 3.6, and what is going to effect you as a theme author, is the all-new post formats UI.
This post formats UI design has already gone through some changes in the beta stage, but here’s where the WordPress team is currently at when the end-user adds a new post, thanks to a little design inspiration from Sara Cannon in Re-thinking WordPress Post Format UI.
Additionally, WordPress has also incorporated a subtle, graphical enhancement when managing all posts by adding an icon representing the current format next to each post title.
Note: At the time of writing this, WordPress 3.6 is still in beta, and currently the post formats UI is on by default whether the author adds theme support for post formats or not. While some of the key people around the release seem to very adamant about keeping it this way, there has been some discussion on whether or not this should be the case. (Trac ticket #23930)
Structured Post Formats
The new concept of structured post formats is essentially that WordPress is now establishing standardized structured data that can be used in displaying certain items associated with posts of different formats.
The new post formats UI is more than just a prettier way of selecting the format of each post. With some of the formats, users are now presented with fields to collect this structured data to be associated with the posts. For example, when selecting the “Video” format, the user is then presented with a field to input a video.
Until now, theme authors choosing to incorporate post formats have had to make tough decisions about how users are going to input data for these formats. This has surely added quite a bit of inconstancy for users working with different themes.
The post formats that now have structured data associated with them include the following:
/>The user has an option to designate an image URL and can put in a website URL if they want that image to link somewhere.
/>The user gets a single field to put in a URL for the link.
/>The user can insert a URL or embed code for a video (self-hosted video now supported in 3.6).
/>The user can insert a URL or embed code for an audio file (self-hosted audio now supported in 3.6).
/>The user has a field for the quote source and a website URL for that source. Note the actual quote is taken from the content of the post; it’ll take the first , or the entire content if that doesn’t exist.
While we’re still in beta, and all of the above isn’t set in stone at the moment, a lot here has been done ultimately for the sake of standardization.
When it’s all set, no matter what the outcome, there will always be room for debate. For example, the “Link” format has a field for the link URL, but should it also have a field for the text associated with that link? The default functionality here is that the title of the post serves as the text for the link. Is this right or wrong? Everyone will have a different opinion on these things and you can surely start debates with all of the structured post format data.
With standardization comes these kinds of bold decisions and we need to accept that for the good of the WordPress community to move forward. We need to work with the new standards and do our best to give users a more unified admin experience.
Post Formats Compatibility
For those that do not specifically add support for structured post formats in their themes, WordPress 3.6 has incorporated the new post_formats_compat() function. This new function is filtered automatically onto the_content(). This works hand-in-hand with the new structured post formats concept to output default fallback behavior for this structured data.
For example, in a theme that doesn’t specifically add “structured-post-formats” support for “Image” posts, when the theme outputs the_content() with a post of this format, WordPress automatically filters in a display of the image the user selected.
What’s interesting about this, and what’s cause for some confusing discussions, is around what it means to actually add theme support for “structured-post-formats” for a certain format. When you do this, you’re not saying your theme supports the data inputted by the user, but instead, you’re effectively saying that you don’t want the data automatically filtered onto the_content() for the given post format.
In other words, when you add “structured-post-formats” support for a specific post format with add_theme_support(), you’re turning off post_formats_compat() when your theme outputs the_content(). This is the case for the formats — image, link, video, audio, and quote — which all prompt the user for structured data.
This idea is a little confusing because until now, using add_theme_support() always meant adding support for some kind of feature that WordPress doesn’t support by default, like post thumbnails, custom backgrounds, etc. However, the structured data of post formats is now a default feature of WordPress. So, the use of add_theme_support() in this case is more about how you approach handling that structured data in your theme files.
Don’t worry if this isn’t quite clicking yet. We’ll discuss this further with specific code examples in the next section, and it’ll make more sense with some of the new theme functionality you can use.
New Theme Functionality
With the new post formats UI and structured data, WordPress 3.6 introduces quite a bit of a new functionality you can start using in your themes.
Adding Support for Structured Post Formats
Whether or not the final release of WordPress 3.6 has post formats UI on by default, you’ll still want to register that your theme supports post formats from your theme functions file, as you did before, for continuity. However, the difference is now that also you want to specify which formats have “structured-post-formats” support.
Notice in the above example, because “link” and “video” formats have “structured-post-formats” support, they didn’t need to be added to the general “post-formats” support, as this happens automatically.
The formats it makes sense to add “structured-post-formats” support to could potentially include the ones that collect data from the user — image, link, video, audio, or quote.
What tangible effect does adding theme support for structured post formats actually have? — Basically it means that any calls to the_content() for the supported formats will not have 3.6′s new post_formats_compat() applied that we discussed in the previous section.
A New Way to Display the Content of the Post
In every WordPress theme you’ve ever created, you’ve used the_content() to display the content of the post, right? Well, WordPress 3.6 has a new function called the_remaining_content() that can be used instead, if you want.
This essentially just outputs the content of the post without the structured post format data in it.
So for example, let’s say you’re setting up how an “Image” format post displays in your theme. Using the_remaining_content() will output the content of the post, allowing you to display the associated image from the structured post format data in your theme’s markup somewhere else. Note that in this case, you would not need to add “structured-post-formats” support for the “Image” format because you’re not using the_content().
Displaying Post Format Structured Data
In terms of displaying the structured data, WordPress 3.6 has given some very easy-to-use functions that encompass it all. Within your theme files, these allow you to display the structured data separately from the content, if that’s what you want to do in your theme design.
A practical example in utilizing one of these might look something like this for the “Image” post format:
And again to reiterate, with this example of displaying an “Image” post and using the_remaining_content(), you would not need to add “structured-post-formats” theme support because you’re not using the_content().
However, if you were to do the following with the_content(), you would need to add “structured-post-formats” support for the “Image” format, or else you’d end up with the image displaying twice.
Displaying Structured Data at the Top of the_content()
If you’re not using the functions we’ve discussed so far, and you’re simply relying on using the_content() to display all of the structured post format data, there’s one thing you’re going to notice that you may, or may not, find strange. With the exception of the “Link” format, WordPress has setup post_formats_compat() to display all structured data after the content of the post.
If you don’t like this, there is a filter you can utilize to change it. Here’s how you’d do it from your theme’s functions file:
Manually Retrieve Meta Data Associated with Structured Formats
If you want to do something custom with this structured data, they’re just saved as meta to the posts that you can easily retrieve with get_post_meta(), as always.
And to retrieve a single array of all of the post format meta data for a given post, you can use the new get_post_format_meta() function to grab it all in one shot.
Displaying a Chat Post
I know that when post formats first came out, the “Chat” format was always one I didn’t really know how to handle. How does the user input the chat into the content of the post? How do we display it? With the new the_post_format_chat() function, there is now more of a clear standard.
It’s expected that the user is going to put a chat into the content of the post formatted something like this:
John: foo 2
The user can also include dates and times, as well. Note that this would be what it looks like if the user copy and pasted directly from a Skype conversation, which is the idea behind the cool, new chat parsers.
And then in your theme, where you’re displaying the “Chat” post format, you can simply replacethe_content() with the_post_format_chat() something like this:
This will automatically convert the user’s chat entry into some standardized, semantic markup we can all begin to style across our themes. The only real catch with this is that it’s assumed the content only contains the chat and nothing else before or after. However, I believe this was pretty common for most theme authors in how they handled the “Chat” post format previously, anyway.
Also, if you want to retrieve the raw parsed data from a post’s chat transcript you can use the function get_the_post_format_chat(). This will return an array of the chat transcript data that you could then manipulate with your own HTML markup.
$stanzas = get_the_post_format_chat();
foreach( $stanzas as $stanza )
foreach( $stanza as $row )
Hiding the Post Formats UI
And finally, what if you just want to hide the new post formats UI? Well, of course, WordPress gives you a filter for this.
Note: This filter is added with 3.6-beta2 (Trac ticket #23929).
But I guess the question is more should you do this? I would tend to say that this probably wouldn’t be the best thing to do in most cases. Since the post formats UI might now end up being a default part of WordPress, you’d essentially just be stripping it away from the end-user.
If you’ve created a whole other custom system for collecting data to use with post formats, and you hide the default UI, this might confuse the end-user a little with standardization in the long run. Is that bad or good? I don’t know; it’s just something to think about. — Ironically, I think those that have incorporated post formats previously in their themes will have the most work to do with updates for the 3.6 release, as opposed to those that haven’t bothered with them yet.
If it turns out the WordPress 3.6 officially has the post formats UI visible by default, and you’re hiding the UI just because you’re not addressing it in your theme, then I could see how possibly some might perceive this as a little lazy.
With a bold decision to incorporate all of this into WordPress, it’s clear that there is a major emphasis on post formats moving forward. It’s probably best that you make sure your themes provide at least basic support, if nothing else, to contribute to a more standardized WordPress experience.
Realistically, this is probably a piece of cake with the new post formats compatibility feature. There’s a good chance your non-post format theme already pretty much works with the new structured data. At a minimum, you may just want to make sure things like chat transcripts and the quote format display nicely in terms of your theme’s CSS.
And for those that want to get creative with displaying posts of various formats within your themes, you now have a ton of awesome new theme functions to play with.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/WfHYTT0vbpM/
When it comes to creating a Custom Post Type within a WordPress plugin, there’s always the same problem: you need to create a custom single-[cpt_slug].php file in your theme folder if you don’t want to use the default single.php file from your theme.
In this post I’d like to cover two aspects of using custom templates. The first step is to show that we can use a custom file contained directly in the plugin itself instead of loading the default single.php, and the second one is how to create your own custom file in your theme folder.
Many plugins like Easy Digital Downloads or Shopp, use this method: the plugin checks if you define a custom template in your theme folder, if it is the case then the file is loaded, otherwise the default plugin template file is loaded. In both cases the theme default single.php file isn’t loaded.
Define the Plugin and Its Structure
The very first step is to create a plugin, let’s call it “Template Chooser“. Create a “template-chooser” folder under /wp-content/plugins/, with the following structure:
Then open the main file template-choose.php and place the following plugin header code:
Plugin Name: CPT template Chooser
Plugin URL: http://wp.tutsplus.com/
Description: Loads a custom template file instead of the default single.php
Author: Remi Corson
Author URI: http://wp.tutsplus.com/
Define the Plugin Constants
Later in the plugin we will need to easily retrieve the plugin URL and its path, that’s why we need to define a few constants:
To go further, we have to setup a new custom post type, let’s create a “Testimonial” CPT, with some very basic supports and features. As the aim of the post is not to teach how to create a custom post type, I’ll use a pretty simple code divided in 3 parts: the custom post type labels, the supports, and the custom post type arguments. All that embed in a single function:
| DEFINE THE CUSTOM POST TYPE
* Setup testimonial Custom Post Type
* @since 1.0
// Custom Post Type Labels
$labels = array(
'name' => esc_html__( 'Testimonials', 'rc_tc' ),
'singular_name' => esc_html__( 'Testimonial', 'rc_tc' ),
'add_new' => esc_html__( 'Add New', 'rc_tc' ),
'add_new_item' => esc_html__( 'Add New Testimonial', 'rc_tc' ),
'edit_item' => esc_html__( 'Edit Testimonial', 'rc_tc' ),
'new_item' => esc_html__( 'New Testimonial', 'rc_tc' ),
'view_item' => esc_html__( 'View Testimonial', 'rc_tc' ),
'search_items' => esc_html__( 'Search Testimonial', 'rc_tc' ),
'not_found' => esc_html__( 'No testimonial found', 'rc_tc' ),
'not_found_in_trash' => esc_html__( 'No testimonial found in trash', 'rc_tc' ),
'parent_item_colon' => ''
$supports = array( 'title', 'editor' );
// Custom Post Type Supports
$args = array(
'labels' => $labels,
'public' => true,
'publicly_queryable' => true,
'show_ui' => true,
'query_var' => true,
'can_export' => true,
'rewrite' => array( 'slug' => 'testimonials', 'with_front' => true ),
'capability_type' => 'post',
'hierarchical' => false,
'menu_position' => 25,
'supports' => $supports,
'menu_icon' => RC_TC_PLUGIN_URL . '/includes/images/testimonials_icon.png', // you can set your own icon here
// Finally register the "testimonial" custom post type
register_post_type( 'testimonial' , $args );
add_action( 'init', 'rc_tc_setup_post_types' );
Do Not Use the Default single.php File
Now that our custom post type is registered, we need to create a function that will tell WordPress not to use the default single.php from the theme.
Because yes by default when displaying a custom post type on the frontend WordPress will check if a file called single-testimonial.php exists and will load it. If not, it will look for the single.php. But we don’t want to use any of them.
We want WordPress to load a custom file from the plugin. To do so, we have to hook a new function to the “template_include” filter. In this function the aim is to check the type of the post and act in consequence:
add_filter( 'template_include', 'rc_tc_template_chooser');
| PLUGIN FUNCTIONS
* Returns template file
* @since 1.0
function rc_tc_template_chooser( $template )
// Post ID
$post_id = get_the_ID();
// For all other CPT
if ( get_post_type( $post_id ) != 'testimonial' )
// Else use custom template
if ( is_single() )
return rc_tc_get_template_hierarchy( 'single' );
Load the Right Template
As you can see, on line 33 we are calling a new function rc_tc_get_template_hierarchy(). This is the function that will check if WordPress has to load the custom file from the plugin or the template from the theme folder.
Please note that when I’m talking about the “template from the theme folder”, I’m talking about a custom file loaded instead of the single.php.
Let’s say you don’t want to load the template included in the plugin but create your own custom template, all you have to do is to create a new folder in the theme folder, name it “plugin_template” and within this folder create a single.php file. This will be your new default single.php loaded only for testimonials displayed on the frontend.
Are you still with me? Okay, so let’s create the function:
* Get the custom template if is set
* @since 1.0
function rc_tc_get_template_hierarchy( $template )
// Get the template slug
$template_slug = rtrim( $template, '.php' );
$template = $template_slug . '.php';
// Check if a custom template exists in the theme folder, if not, load the plugin template file
if ( $theme_file = locate_template( array( 'plugin_template/' . $template ) ) )
$file = $theme_file;
$file = RC_TC_BASE_DIR . '/includes/templates/' . $template;
return apply_filters( 'rc_repl_template_' . $template, $file );
add_filter( 'template_include', 'rc_tc_template_chooser' );
The Plugin Default Template
Now create a new testimonial in the administration. Then open includes/templates/single.php and then copy and paste this simple code:
we are in the plugin custom file
If you visualize the testimonial on the frontend you should see the “we are in the plugin custom file”. That’s what we wanted. But if the plugin template file doesn’t fit your needs or if you simply want to create a more personal design, you can create a file in your theme folder.
The Theme Default Template
To create a custom template that does not use the default one from the plugin, you can create a new folder called “plugin_templates” in your theme folder. Create a new file called single.php and place this code:
we are in the theme custom file
So what did we do exactly? Well, we created a plugin that registers a custom post type “Testimonial“. We achieved functionality to load a custom file stored in the plugin folder instead of the default single.php or single-testimonial.php files from the theme folder. We also managed to load a custom file instead from the theme folder located under “plugin_templates“.
Why is this nice? Because when you create your own plugin you can provide a default template to display the custom post type so you’re giving the choice to the final user whether to use their own template or not.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/fJrspDqkPQU/
You should be familiar with custom fields in WordPress. We use them on a post or a page to add extra data. In WordPress attachments are also saved as posts, so custom fields are available for them too.
Today we’ll see how we can add some custom fields so that attachments can carry more information than just the default data.
What We’ll Do
First of all, we are going to create a plugin to handle the attachments custom fields. It will get a set of options, bake them so they become part of the form when we edit an attachment, and save them into the database.
I will pass quickly on this part as it’s not the main purpose of this tutorial.
Create a new folder in the plugins directory (wp-content/plugins/media-fields/ for example) and put a file (named plugin.php) inside. Let’s also put a file called custom_media_fields.php which will hold our options.
This is what your plugin.php file should look like at first:
Plugin Name: Wptuts+ Custom Media Fields
Description: Create attachments custom fields
Author: Guillaume Voisin
Author URI: http://wp.tutsplus.com/author/guillaumevoisin
require_once( plugin_dir_path( __FILE__ ) . '/custom_media_fields.php' );
private $media_fields = array();
function __construct( $fields )
public function applyFilter( $form_fields, $post = null )
function saveFields( $post, $attachment )
$cmf = new Wptuts_Custom_Media_Fields( $attchments_options );
This is the base we’ll populate in the following sections. For now, let’s define our set of options.
2. Define Our Options
In the other file, let’s add some options to enhance the attachment edit form. We’ll consider, for this tutorial, options to improve images. For instance, we’ll add copyright, author description, watermark, rating, and image disposition fields.
It is basically an associative array which contains these parameters:
label – the field name that will be displayed
input – the input type (e.g text, select, radio, …)
helps – information to help the user filling in the field
application – which attchment mime type to apply
exclusions – which attchment mime type to exclude
required – is the field required? (default false)
error_text – optional field to describe the error (if required is set to true)
options – optional field for radio and select types
show_in_modal – whether to show the field in modal or not (default true)
show_in_edit – whether to show the field in classic edit view or not (default true)
extra_rows – additional rows to display content (within the same “tr” tag)
tr – additional rows (“tr” tag)
The highlitghted options represent options we will manually deal with whereas others are default ones WordPress will process automatically.
As we are dealing with images, we set the application parameter to “image“. It will actually apply to all kinds of images whose mime type starts with “image” such as image/jpeg, image/png and so on. You could exlude the gif mime type by setting it in the exclusions field for example.
Now our options are set, let’s dig into the hooks.
3. The Hooks
As mentionned earlier, we’ll deal with two hooks.
We bind our two functions to those hooks in the constructor method.
$form_fields – An array of fields contained in the attachment edit form
$post – Object which represents the attachment itself
We will use the $form_fields parameter to merge our own fields and check each one of them against attachment requirements (mime type for instance).
public function applyFilter( $form_fields, $post = null )
// If our fields array is not empty
if ( ! empty( $this->media_fields ) )
// We browse our set of options
foreach ( $this->media_fields as $field => $values )
// If the field matches the current attachment mime type
// and is not one of the exclusions
if ( preg_match( "/" . $values['application'] . "/", $post->post_mime_type) && ! in_array( $post->post_mime_type, $values['exclusions'] ) )
// We get the already saved field meta value
$meta = get_post_meta( $post->ID, '_' . $field, true );
// Define the input type to 'text' by default
$values['input'] = 'text';
// And set it to the field before building it
$values['value'] = $meta;
// We add our field into the $form_fields array
$form_fields[$field] = $values;
// We return the completed $form_fields array
At this step, you should have your attachment edit form enhanced with the new fields we’ve added. But they will look like text inputs. We now have to consider different kinds of inputs (radio, checkbox, etc…).
So let’s edit our function to handle this. Replace the $values['input'] = 'text'; with the following code:
switch ( $values['input'] )
$values['input'] = 'text';
$values['input'] = 'textarea';
// Select type doesn't exist, so we will create the html manually
// For this, we have to set the input type to 'html'
$values['input'] = 'html';
// Create the select element with the right name (matches the one that wordpress creates for custom fields)
$html = '';
// Set the html content
$values['html'] = $html;
// Checkbox type doesn't exist either
$values['input'] = 'html';
// Set the checkbox checked or not
if ( $meta == 'on' )
$checked = ' checked="checked"';
$checked = '';
$html = '';
$values['html'] = $html;
// radio type doesn't exist either
$values['input'] = 'html';
$html = '';
if ( ! empty( $values['options'] ) )
$i = 0;
foreach ( $values['options'] as $k => $v )
if ( $meta == $k )
$checked = ' checked="checked"';
$checked = '';
$html .= ' ';
$values['html'] = $html;
Now, we can build common HTML elements. Let’s check out our attachment edit form. It should look just like this:
The custom fields, depending on whether you set their modal options to true or not, will also appear in the media modal form when you edit a post.
Now our fields are displayed in our attachment edit form, we have to save them in the database. For this, we are going to use the second hook.
This hook also has two parameters:
$post – array which represents the attachment entity
$attachment – contains all fields attached to the attachment post
Now, let’s fill the function saveFields we left in the previous section.
function saveFields( $post, $attachment )
// If our fields array is not empty
if ( ! empty( $this->media_fields ) )
// Browser those fields
foreach ( $this->media_fields as $field => $values )
// If this field has been submitted (is present in the $attachment variable)
if ( isset( $attachment[$field] ) )
// If submitted field is empty
// We add errors to the post object with the "error_text" parameter we set in the options
if ( strlen( trim( $attachment[$field] ) ) == 0 )
$post['errors'][$field]['errors'] = __( $values['error_text'] );
// Otherwise we update the custom field
update_post_meta( $post['ID'], '_' . $field, $attachment[$field] );
// Otherwise, we delete it if it already existed
delete_post_meta( $post['ID'], $field );
Ok, now our custom fields are saved into the database and will be available for the front-end.
Please be careful when manipulating the post parameter in both hooks. It is an object in the first one and an array in the second one.
Tip: the update_post_meta will create the meta if it doesn’t exist.
Tip: We prefix the custom field key with an underscore “_” so that they won’t be listed in the custom fields metaboxes on post edit pages.
As of version 3.5, it seems that errors still don’t appear on attachment edit forms. I tried to investigate the core code, and despite the fact it should have been fixed (http://core.trac.wordpress.org/ticket/13810), it seems not.
For the ajax save process, it is certain it’s not done yet as mentionned in the ajax-actions.php file:
$errors = $post['errors']; // @todo return me and display me!
So right now, errors are not going to work properly, but the code is done so that when those bugs are fixed, it’ll work.
To use those custom fields in your templates, you just have to retrieve post metas the same way you would for regular posts. Don’t forget to add the “_” prefix to the custom fields’ keys.
Human or crawler, a visitor needs to find where your post belongs. Even if you have category or tag archives, it’s almost always a necessity to include a section to display a little bit information for the content.
In this post, we’re moving on with our series with the “post meta”, the identity card of the post.
“Post Meta” to Help People (And Crawlers) Find Their Way
While a “related posts” section is the most effective way to offer people relevant content, it’s also good practice to serve the information of the post’s categories, tags, publishing date and so forth – both for humans and search engine spiders.
Why Use a “Post Meta” Section?
I don’t know if you have ever done this, or have seen someone else do it, but sometimes people like to consume the content of a website as a whole.
You might have come across some weird data in your website’s statistics, which showed that one visitor (or a couple of visitors) spent over 3 hours on the website. If you have good content, the chances are higher to see weird data like this in your website’s stats.
This kind of content consumer is the kind who will constantly share your posts and talk about your website. You must care about these people the most and in order to help them spend hours in your website, you must provide them with a well structured post meta section.
The same goes for “normal” visitors: They might be interested in other posts from the same category or author, or they might want to know when the post was published. Also, of course, search engines always need information to categorize and structure your website’s page listings.
Creating a Strong “Post Meta” Section
In order to serve a “post meta” section with good quality, we must think of what it should consist of. Off the top of my head, I can list a couple of items:
The author of the post (with a link)
The categories that the post is in
The tags the post has
The publish date of the post
A link to edit the post (for admins and authors, of course)
In Part 1 of this tutorial you learned how to create a template file for a custom post type in order to display featured images and titles for each post. You registered a custom post type of ‘animal’ and created a file called archive-animal.php to display an archive of animals.
In this tutorial you’ll learn the CSS required to add a grid layout to the images and overlay post titles over the images. You’ll then learn how to add a hover effect, so the name of the animal only appears when the user hovers their mouse over each image.
Resources You’ll Need for This Tutorial
This tutorial uses a child theme with the Twenty Twelve theme as its parent. You’ll need a WordPress installation set up with this theme installed (it should be installed as the default). If you’re unsure of how to set up a child theme, see the instructions on the WordPress Codex.
You’ll also need a code editor with FTP access to your site, unless you’re developing locally in which case you won’t need FTP.
You’ll need the child theme created in Part 1 of this tutorial, with the archive-animal.php template file.
You can download the code bundle, including the child theme files, using the Download link above.
The Archive Page
The archive page you’re starting with displays the image and title of each post as shown in the screenshot. In this part of the tutorial you don’t need to edit the archive page at all, just the stylesheet for the theme.
Adding the Grid Layout
To lay the images out in a grid you’ll need to use floats. Open your theme’s stylesheet and add the following:
This CSS targets the animals archive by using .post-type-archive-animal, a class which WordPress applies to the body element because the Twenty Twelve theme uses the body_class() function to assign classes to this element.
It removes any clear settings for the article element and adds a float and a margin for layout.
You will now have your post listings in a grid:
Overlaying the Text and Adding Opacity
The next step is to position the title of each post so that it’s overlaid over the image, and add a semi-opaque background to improve legibility.
Below the CSS you’ve already added, add the following:
This does a few things. Firstly, on the .entry-content img element it adds position: relative so that absolute positioning will work for the .archive-title element contained within it, as well as adding a float which ensures the layout works correctly.
Next, for the .archive-title element it adds absolute positioning and sets that up using the left and right values. It adds width, height and padding which add up to 150px by 150px, the size of the thumbnail images in this theme. Finally it adds a semi-opaque background using rgba, with a fallback for IE using filter: alpha(opacity=50).
The images now have the text overlaid with a semi-opaque background:
Adding the Hover Effect
You may decide that you’re happy with the archive page as it is. In some cases it’s preferable for the titles to be constantly visible. But if you want the images to have greater priority and be visible without text or a background obscuring them when the page first loads, you can add a hover effect, hiding the text until the user hovers the mouse over an image.
To do this, you’ll need to edit the styling for the .archive-title class and add some extra styling for the :hover state as follows:
This provides a slightly different version of the styling for the .archive-title element, with opacity set to 0. The positioning, padding and width are exactly the same as you added earlier for the overlay effect.
It then targets the title and links within it in the hover state, and adds a background and opacity to these. These settings are similar to those you added earlier when adding a semi-opaque background to the titles, but now that background (and the title itself) only appears when the user hovers the mouse over an image.
When the archive page is first loaded, the images appear without any text overlaid:
When the user hovers their mouse over one of those images, the title will appear:
You now have a nice archive page using a grid of images with a hover effect for text.
In these two tutorials, you’ve learned how to do the following:
Register a custom post type and create a custom archive page to display posts form that post type
Create a custom loop to display a featured image and title for each post on the archive page
Use CSS to lay the images out in a grid
Add an overlay effect for the title of each post so it’s overlaid on top of the featured image
Finally, add a hover effect so that the text is invisible until the user hovers over an image
The code required to do this is relatively straightforward and compatible with major browsers, including older versions of IE.
WordPress is the most popular blogging platform, but it still has a multitude of features which may represent somewhat of a mystery to its users.
This article will focus on the WordPress favicon, which is an icon associated with a website, used when that website is bookmarked. This small icon, 16 pixels by 16 pixels, is shown next to a website’s URL in the address bar of an Internet browser or as an icon for Internet shortcuts on your desktop or other folders.
The favicon, short for favorites icon, is a visual identifier for a certain web page.
Following you will find useful information on the favicon, its benefits, the designing and installation process, and all the advantages it provides to WordPress users.
Benefits of Using the Favicon
There are several benefits WordPress users can achieve from using a favicon. Firstly, this little icon makes a website stand out amongst the multitude of websites thus making people remember your website easily.
Most WordPress websites have a standard favicon, which makes it difficult to differentiate amongst the websites this platform supports.
A favicon gives your website the personality it needs in order to shine.
Secondly, a favicon is a powerful branding tool that can help your website rank better in search engines. This benefit can end up directing more traffic to your web page. Just like a logo and a name, a favicon adds to the professional image you portray in front of your customers.
If you are serious about your business and the professionalism of your WordPress website, then a favicon is definitely a feature you should take into consideration.
Thirdly, on browsers that support “tabbed browsing”, such as Firefox, Google Chrome, and the majority of other commonly used browsers, the favicon helps the user identify which tab has which website, making surfing the Internet a lot easier.
This visual reminder is another thing that can help visitors remember your website and which will prompt them to come back time and time again.
How to Create a Favicon
There are various ways of creating a favicon. One option is to use a graphics program that allows you to save files with a .ico extension, such as The GIMP, Corel Draw or Photoshop. Even MS Paint can be used in order to create a favicon!
The perfect program for you simply depends on which of them you are more familiar with.
In general, regardless of the graphics program you ultimately choose, you will need to download a plugin that can help you save a file in the .ico format.
After downloading and installing the plugin, you can begin creating your favicon. If you already have a logo for your website, you could try resizing it to the favicon dimensions of 16×16 pixels to see how it looks.
If the look is not what you had in mind, you will have to start fresh and create a new image. Try using the colors already present on your website, in order to make it match. Do not over do it; consider the small size of the icon and try to keep the design as simple as possible. Nonetheless, you still have to make sure that the image is somewhat representative of your web page. This will help visitors better connect the favicon to your brand.
If you are not too confident on your designing skills, you can definitely hire someone to create the favicon for you. However, this is usually not worth the investment as with a few trials and errors, you can certainly come up with an icon you will be satisfied with. It might take a few tries, but in the end, you will surely create the perfect favicon for your web page.
16×16 pixels is quite a small canvas to work on, so you could consider starting with a larger one that will allow you to use your creativity and resizing it to the right dimensions once you have completed the image.
When reducing an image to the favicon dimensions of 16 pixels by 16 pixels, you have to make sure that the image does not come up blurry because this tends to happen quite often when resizing a photo.
To help you with this, graphics programs usually have tools that allow you to adjust the sharpness of a picture. Make sure you use them in order to obtain an image as clear as possible. After you have created an icon you like save it as “favicon.ico” on your computer.
Another option you have of creating a favicon is by using an online service, such as ConvertICO.org, that allows you to come up with a 24bit icon with a transparent background, completely free of charge. Every such online service comes along with instructions you need to follow to create your favicon. Read them thoroughly before starting working on the icon. After you have finished with the process, you can simply download the image to your computer, from where you can upload it to your WordPress web page.
The two options presented above described creating favicons with the .ico format. However, you can also use images that have a .gif or .png extension, as long as they adhere to the 16 pixels by 16 pixels standard.
Nonetheless, the .ico format offers several advantages in comparison to these two formats. .ico images are supported by all browsers, are less prone to generating errors, and an .ico file can hold more than one icon.
How to Install a Favicon
Once again, you have more than one way of installing a favicon on your WordPress website. There are various plugins you can install that can do it for you, or you can choose to set up the favicon yourself. The manual process of installing a favicon is not too difficult once you get the hang of it, so a plugin is not really a must in this situation.
First, you have to upload the favicon image you have created from your computer to your website. In order to upload the favicon, you have to use a FTP client, such as FileZilla, which will load the icon into your theme’s main folder. Additionally, you should also upload a copy of the favicon into the main directory of your website, which will display the icon in your subscribers’ feedreaders.
If you already have another favicon in place, you should make sure you delete it before you upload the new one or otherwise it will not work. In order to delete the old favicon, you should locate it in your current theme’s main folder and remove it using an FTP client. Make sure that the old or the default favicon is deleted from both the theme and the root directory.
Working With Older Browsers
For the favicon to appear on old browsers, there is an editing process you will have to undergo.
Firstly, log onto your account and go to the WordPress Dashboard. Next, click on Appearance. Following that, click on the link that says “Editor”. There, you have to select a file that is called “Header (header.php)” in order to edit it.
While in the header file, look for a line of the code that begins with
and ends with /favicon.ico" />. In case it already exists, overwrite it with the new code. Otherwise, under the HTML tag, insert the following code:
To make the changes active and to ensure that your favicon will pop up in the address bar, make sure you click save.
In order to make sure everything is okay, visit your web page’s front end to see if the favicon displays properly on the address bar next to your website’s URL. In some cases, it might take a while before the new favicon pops up, so be patient.
If the favicon still does not appear, redo the steps to check if you have missed something. Anytime you want to install a new favicon, you should follow the steps presented above.
Of course, if this seems like too much of a hassle, you always have the other option of using a plugin to do it for you, as there are several available out there.
A favicon is just one of many marketing techniques websites use to brand themselves and, until now, its importance has somewhat been overlooked.
Using a favicon can make your web page stand out amongst millions of other WordPress users who simply use the basic icon. Favicons are easy to create and install, they are completely free to use, and, most importantly, they can help make your WordPress website a lot more successful.
Because of this, the favicon is one marketing strategy that no WordPress user should overlook.
Original from: http://feedproxy.google.com/~r/Wptuts/~3/wXoJ6_7OfiM/