Wordpress Leaks

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.

add_theme_support( 'structured-post-formats', array(
	'link', 'video'
) );
add_theme_support( 'post-formats', array(
	'aside', 'audio', 'chat', 'gallery', 'image', 'quote', 'status'
) );

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:

function my_post_format_compat_args( $args ) 
	$args['position'] = 'before';
	return $args;

add_filter( 'my_post_format_compat_args', 'post_format_compat' );

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
Mary: bar
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.

[4/10/13 4:20:30 PM] John: foo
[4/10/13 4:20:58 PM] Mary: bar
[4/10/13 4:22:22 PM] John: foo 2

And then in your theme, where you’re displaying the “Chat” post format, you can simply replace the_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.

function my_chat_display() 
	$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.

add_filter( 'enable_post_format_ui', '__return_false' );

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.

Conclusion

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/

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:

/*
|--------------------------------------------------------------------------
| FILTERS
|--------------------------------------------------------------------------
*/

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' ) 
		return $template;
	

	// Else use custom template
	if ( is_single() ) 
		return rc_tc_get_template_hierarchy( 'single' );
	

}

/**
 * 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;
	
	else 
		$file = RC_TC_BASE_DIR . '/includes/templates/' . $template;
	

	return apply_filters( 'rc_repl_template_' . $template, $file );
}

/*
|--------------------------------------------------------------------------
| FILTERS
|--------------------------------------------------------------------------
*/

add_filter( 'template_include', 'rc_tc_template_chooser' );

we are in the plugin custom file

we are in the theme custom file

3. The Hooks

As mentionned earlier, we’ll deal with two hooks.

We bind our two functions to those hooks in the constructor method.

function __construct( $fields ) 
	$this->media_fields = $fields;

	add_filter( 'attachment_fields_to_edit', array( $this, 'applyFilter' ), 11, 2 );
	add_filter( 'attachment_fields_to_save', array( $this, 'saveFields' ), 11, 2 );

Now let’s see those hooks in detail.

attachment_fields_to_edit

It has two parameters:

1. $form_fields – An array of fields contained in the attachment edit form
2. $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
	return $form_fields;
}

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'] ) 
	default:
	case 'text':
		$values['input'] = 'text';
		break;

	case 'textarea':
		$values['input'] = 'textarea';
		break;

	case 'select':

		// 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 = '';

		// If options array is passed
		if ( isset( $values['options'] ) ) 
			// Browse and add the options
			foreach ( $values['options'] as $k => $v ) 
				// Set the option selected or not
				if ( $meta == $k )
					$selected = ' selected="selected"';
				else
					$selected = '';

				$html .= '' . $v . '';
			
		}

		$html .= '';

		// Set the html content
		$values['html'] = $html;

		break;

	case 'checkbox':

		// Checkbox type doesn't exist either
		$values['input'] = 'html';

		// Set the checkbox checked or not
		if ( $meta == 'on' )
			$checked = ' checked="checked"';
		else
			$checked = '';

		$html = '';

		$values['html'] = $html;

		break;

	case 'radio':

		// 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"';
				else
					$checked = '';

				$html .= ' ' . $v . '
';
				$i++;
			
		}

		$values['html'] = $html;

		break;
}

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.

attachment_fields_to_save

This hook also has two parameters:

1. $post – array which represents the attachment entity
2. $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
				else
					update_post_meta( $post['ID'], '_' . $field, $attachment[$field] );
			
			// Otherwise, we delete it if it already existed
			else 
				delete_post_meta( $post['ID'], $field );
			
		}
	}

	return $post;
}

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.

Error Considerations

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.

/>

Front End

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.

For instance, you could do like so:

echo "
";
echo "	
Copyright: " . get_post_meta( get_the_ID(), '_image_copyright', true ) . "
";
echo "	
Rating: " . get_post_meta( get_the_ID(), '_image_stars', true ) . "
";
echo "	
Author description: " . get_post_meta( get_the_ID(), '_image_author_desc', true ) . "
";
echo "	
Image disposition: " . get_post_meta( get_the_ID(), '_image_disposition', true ) . "
";
echo "	
Watermark? " . ( get_post_meta( get_the_ID(), '_image_watermark', true ) == "on" ? "yes" : "no" ) . "
";
echo "
";

/>

Go Further

There are several points of improvements depending on your needs:

• You could have your settings in the database so it becomes more flexible to add, edit, and remove them
• You could have a default value that is set for all new attachments when a value is not set
• You should set some style for the modal form so it displays the custom fields properly

/>

Conclusion

Don’t hesitate to share with us your ideas on how to improve this plugin and what you would expect from such functionality.

Original from: http://feedproxy.google.com/~r/Wptuts/~3/Qhxux17ppBw/

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:

/* styling to add image overlay and opaque background */
.post-type-archive-animal .entry-content img 
	position: relative;
	overflow: hidden;
	background: transparent;
	float: left;


.post-type-archive-animal .archive-title 
	position: absolute;
	text-align: center;
	left: 0;
	bottom: 0;
	width: 140px;
	height: 70px;
	background: rgba(255, 255, 255, 0.5);
	padding: 50px 5px 30px 5px;
	filter: alpha(opacity=50);

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:

/* styling to add the hover effect */
.post-type-archive-animal .archive-title 
	position: absolute;
	text-align: center;
	left: 0;
	bottom: 0;
	width: 140px;
	height: 70px;
	opacity: 0;
	padding: 50px 5px 30px 5px;


.post-type-archive-animal .archive-title:hover,
.post-type-archive-animal .archive-title a:hover  
	display: block;
	background: rgba(255, 255, 255, 0.5);
	-moz-opacity: 0.7;
	filter: alpha(opacity=50);
	opacity: 1;

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.

/>

Summary

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.

/>

Useful Resources

Codex pages:

• Child themes
• Template hierarchy
• The Loop
• Displaying featured images with the_post_thumbnail

Tutorials:

• Creating child themes
• The complete guide to custom post types
• A beginner’s guide to the loop
• How to add featured images to your theme

CSS Resources:

• CSS positioning 101
• CSS transparency settings for all browsers

Original from: http://feedproxy.google.com/~r/Wptuts/~3/D7rJAzvd5aY/

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: