Working with paginate_links

It is no secret that I try to advocate the use of core functions when possible. The idea of maintaining less code is a great one for any developer. It’s the old set it and forget mentality.

What I do see a lot of is the use of my_theme_pagination that uses get_pagenum_link in order to get all the page links. Yes it does use a core function but it uses it several times. Why not just use a core function that has been available since 2.1? Talk about way back, right? The best part is that you are given a few options when you use paginate_links.

The core code

Let us take a look at the core code. The function is found in the general-template.php file of the wp-includes folder. There are approximately 142 lines that make up this function. As you can see there is quite a bit of logic behind it to work. We will look at the key things. The first one being the array we can pass as an argument, and the second being the type key in that array.

You can use the function without passing anything to it and it will work. There is a reason for that. The $args parameter that can be passed gets merged with a few defaults. What are those, you ask? Here they are:

$defaults = array(
	'base' => $pagenum_link, // http://example.com/all_posts.php%_% : %_% is replaced by format (below)
	'format' => $format, // ?page=%#% : %#% is replaced by the page number
	'total' => $total,
	'current' => $current,
	'show_all' => false,
	'prev_next' => true,
	'prev_text' => __('« Previous'),
	'next_text' => __('Next »'),
	'end_size' => 1,
	'mid_size' => 2,
	'type' => 'plain',
	'add_args' => array(), // array of query args to add
	'add_fragment' => '',
	'before_page_number' => '',
	'after_page_number' => ''
);

$args = wp_parse_args( $args, $defaults );

Quite a few options available to use. For the sake of this post we will focus on mostly on the type. There are three possible return types. They are array,list, and an empty value. We can see those towards the end of the function:

switch ( $args['type'] ) {
	case 'array' :
		return $page_links;

	case 'list' :
		$r .= "<ul class='page-numbers'>\n\t<li>";
		$r .= join("</li>\n\t<li>", $page_links);
		$r .= "</li>\n</ul>\n";
		break;

	default :
		$r = join("\n", $page_links);
		break;
}

It uses a switch statement to set the $r value that is ultimately returned. Yes, paginate_links returns and does not output any content. This is where we can actually take advantage of that.

Usage

Now with that in mind let us create some example usage, yeah? This is the part that gets fun! So we will take a look at using all three options and how they can be expanded or altered to suit your theme’s needs.

Array

Returning the array is one of the neater ways of using the function. The reason is that it returns an array of links. The amount of links is the amount of keys available for us to manipulate. Yes, we can style to our choosing. Let’s look at a sample return:

Array
(
    [0] => <span class='page-numbers current'>1</span>
    [1] => <a class='page-numbers' href='http://localhost/page/2/'>2</a>
    [2] => <a class='page-numbers' href='http://localhost/page/3/'>3</a>
    [3] => <span class="page-numbers dots">&hellip;</span>
    [4] => <a class='page-numbers' href='http://localhost/page/10/'>10</a>
    [5] => <a class="next page-numbers" href="http://localhost/page/2/">Next &raquo;</a>
)

What’s cool about that is you can see that by default you have the CSS classes page-number, current, and dots that you can use for some styling. Pretty awesome if you ask me. You can now expand upon that markup. A good way is by using the foreach to loop over and create your HTML markup. A quick example is:

$links = paginate_links( array( 'type' => 'array' ) );

echo '<div class="pagination col-6">';
foreach( $links as $link ){
	echo $link;
}
echo '</div>';

Yes, that is a super quick way of doing things but you get the idea. You can expand upon that to your heart’s content and add your needed classes or markup.

List

Another way is returning the list. An already HTML markup of our links in an unordered list. The returning text looks a little like:

<ul class='page-numbers'>
	<li><span class='page-numbers current'>1</span></li>
	<li><a class='page-numbers' href='http://locahost/page/2/'>2</a></li>
	<li><a class='page-numbers' href='http://localhost/page/3/'>3</a></li>
	<li><span class="page-numbers dots">&hellip;</span></li>
	<li><a class='page-numbers' href='http://localhost/page/10/'>10</a></li>
	<li><a class="next page-numbers" href="http://localhost/page/2/">Next &raquo;</a></li>
</ul>

What is super awesome about it is you can use just one line of code:

echo paginate_links( array( 'type' => 'list' ) );

Super awesome, right? The reason I love that is you can just leave that code and style it all. No special markup to worry about as it is already taken care of. You can use something like:

ul.page-numbers {
  clear: both;
  font-size: 1.4em;
  color: #deaf01;
}

ul.page-numbers li {
  display: inline-block;
}

It doesn’t have to be super crazy but you get the idea.

Empty value

Now for the simplest way of using the function.

echo paginate_links();

A lot of work, right? Super, super simple and you don’t have to worry about creating any extra markup. That is if you don’t want to. It returns a string of all the links and you can go about your business. If you really like super simple HTML markup then please use that.

User changes

Yes, we can have a user change a few of the things too if we want. Let’s take a quick look at how we can change the amount of links to show around the current page.

function jc_pagination(){
	echo paginate_links( 
		array(
		'show_all' => get_theme_mod( 'all-links', false ),
		'type' => 'list',
		'mid_size' => get_theme_mod( 'mid-links', 3 )
		)
	)
}

Pretty cool, right? With that get_theme_mod you can now have the user decide how many links will show before and after the current page. Yes, it is a minor touch but it can go a long way with some users.

Widgets and when to use them

Widgets are a great way of showing information in specified areas. Themes handle this in different locations and different ways. Some have page template with up to thirty widget areas. Yes, thirty! Sorry, felt like a salesman when I typed it out but it is true. And then you get the occasional theme that wants you to type out content. Yes. Dealing with themes and content.

The reason I’m not a fan of this is because once the theme is switched you lose that content. I know some will ask how much content is too much content? Any content that isn’t theme specific is too much.

What drives me up a wall more is when some themes bundle a widget that core is more than capable of handling. A very common one is the infamous call to action button widget. Yes. I dislike that button widget. You can use core’s text widget! Let’s see an example shall we?

$text = sprintf( __( "You can use <small>%s</small> as well as basic HTML.\n\n You just <strong>cannot</strong> use JavaScript.\n\nThis is a <em>sample</em> with auto paragraphs being used.\n\nWhat next?", 'text-domain' ), allowed_tags() );
the_widget( 'WP_Widget_Text', 
	array( 
		'title' => __( 'Using a text widget', 'text-domain' ), 
		'text' => $text,
		'filter' => true
		),
	array(
	  	'before_widget' => '<aside id="%1$s" class="widget %2$s">',
		'after_widget'  => '</aside>',
		'before_title'  => '<h1 class="widget-title">',
		'after_title'   => '</h1>',
	  ) );

Yes, it does look like quite a bit of code but there is a reason for it. The function that does the magic for us is the_widget. What’s super cool is that this means you can create an instance of a widget to create a great looking theme preview. Not only that it can serve as a bit of documentation for your theme.

Let’s take a look at another example, shall we?

The plugin I used is Feature a Page. All I did was a simple search in the plugin repository and picked one at random.

if ( class_exists( 'FPW_Widget' ) ):
the_widget( 'FPW_Widget',
        array(
            'title' => 'About our Clients',
            'featured_page_id' => '1141', // ID of page
            'layout' => 'banner',
            'show_title' => false,
            'show_image' => true,
            'show_excerpt' => true
        ),
        array(
            'before_widget' => '<aside id="%1$s" class="widget %2$s">',
            'after_widget'  => '</aside>',
            'before_title'  => '<h3 class="widget-title">',
            'after_title'   => '</h3>',
          ) );
endif;

Let’s run through the code a little. The first line checks to see if the class FPW_Widget exists. If it does, then we can run our code. As you can see the second argument we’re passing is an associative array with some settings we want our widget to display.

In this particular case the widget has some settings that we can change. They are:

$defaults = array(
	'title' => '',
	'featured_page_id' => '',
	'layout' => 'wrapped',
	'show_title' => true,
	'show_image' => true,
	'show_excerpt' => true,
	'show_read_more' => false
);

They will vary from widget to widget so be mindful of that. The codex page has the default widgets and their respective settings that you can change.

Now, what’s neat is that you can use the third argument in order to style the output of the widget. To a degree. Let’s look at the first example:

array(
	'before_widget' => '<aside id="%1$s" class="widget %2$s">',
	'after_widget'  => '</aside>',
	'before_title'  => '<h3 class="widget-title">',
	'after_title'   => '</h3>',
) );

Notice that I’m using a simple copy paste of what a register_sidebar call would do. In particular the before|after_widget, before|after_title parts. Reason being, odds are, you’ve styled the widget areas with certain CSS classes and using those instead of the default ones the_widget uses. Core markup is:

$before_widget = sprintf('<div class="widget %s">', $widget_obj->widget_options['classname'] );
$default_args = array( 'before_widget' => $before_widget, 'after_widget' => "</div>", 'before_title' => '<h2 class="widgettitle">', 'after_title' => '</h2>' );

So if you don’t define the third argument, what will be used on output is the above.

Additional notes

I used the plugin because it is a great example of how you can pull user generated content to create a widget. What’s really nice is there are several plugins that create widgets and deal with widgets. Don’t forget that you can even use a simple setting in order to create a featured content area as well. There are several themes that do this already so explore their code and learn from them.

Fun with template tags: comment_form

This time I’ll focus on the comment_form(). Neat, fun and with plenty of hooks and filters.

The code

Like usual we will look at the core code of the comment_form. There are approximately 230 lines of code that make up this template tag. Does sound like a lot, right? Yes, but when you look a little closer it is the inline documentation that makes up the brunt of it all.

Yes, documentation. I love it and is what I am doing to an extent with these posts. I am documenting their use with examples in hopes that somebody finds it useful. I know at least one person will.

Anyway, back to the point. The hooks and filters.

The filters

One of the first filters is comment_form_default_fields. Pretty neat one because you can add, remove, and even edit form fields. Let’s make a quick edit and remove the website field from the default, shall we?

add_filter( 'comment_form_default_fields', 'my_new_fields' );
function my_new_fields( $fields ){
	$fields['author'] = '<p class="author input"><label for="name"><span class="required">Your name:</span></label><input name="name" type="text" /></p>';
	
	unset( $fields['url'] );
	return $fields;
}

Pretty neat, right? The next one that we come across is the comment_form_defaults. This one is a little more fun in that it has the previous one included with it. I know you may be thinking what do I mean by that, so let’s look at the code:

$defaults = array(
	'fields' => $fields,
	'comment_field' => '<p class="comment-form-comment"><label for="comment">' . _x( 'Comment', 'noun' ) . '</label> <textarea id="comment" name="comment" cols="45" rows="8" aria-describedby="form-allowed-tags" aria-required="true" required="required"></textarea></p>'

That $fields variable is from the previous filter. It is the line before the $defaults array is set. So much like the previous filter we can edit and remove from the default comment_form.

add_filter( 'comment_form_defaults', 'my_custom_form' );
function my_custom_form( $array ){
	$array['class_submit'] ='submit blue input';
	$array['title_reply'] = __( 'Drop us a line', 'text-domain' );
	$array['title_reply_to'] = __( 'Argue with %s', 'text-domain' );
	$array['cancel_reply_link'] = __( 'nevermind!', 'text-domain' );
	
	return $array;
}

From the above example you can see we change the submit class to include blue and input. A few other things were changed and the best part is that you can use a child theme to remove that or even add your own. That’s cool if you wanted to make a lot of additions or deletions but what if you wanted to do it to just one? That’s where

echo apply_filters( "comment_form_field_{$name}", $field ) . "\n";

comes into play. Where $name is the input you wanted to edit. For example:

add_filter( 'comment_form_field_author', 'my_new_author_field' );
function my_new_author_field(){
	return '<label for="author">' . __( 'What is your name, yo?', 'text-domain' ) . '<span class="required">*</span></label><input id="author" name="author" type="text" size="30" />';
}

Pretty cool if you have to change a few thing in order to properly style your form elements.

The hooks

Cool! Those were some of the filters but we cannot just leave without a few action hooks, right? I mean why wouldn’t you like action hooks? Those are so cool because you can add things conditionally.

Let’s look at some of them shall we? There are nine in total. Yes, 9. Not nine thousand. Just nine. That’s quite a few that we can hook to. Good! Plenty of things to mess and tweak with. Some of the neater ones I like are:

do_action( 'comment_form_before' );
do_action( 'comment_form_top' );
do_action( 'comment_form_before_fields' );
do_action( 'comment_form_after_fields' );
do_action( 'comment_form', $post_id );
do_action( 'comment_form_after' );

The reason I like the fifth one is because it is a dynamic one. You can add to the form depending on the post’s ID. Let’s say you wanted to add a note to all posts published before a certain date. You could potentially go through every single one but that could be time consuming. What’s nice is that WordPress uses an incremental ID meaning that when a new post is added it uses the next highest number for the ID. You could use something like:

add_action( 'comment_form', 'my_form_notice' );
function my_form_notice( $id ){
	if ( $id < 1155 ){
		printf( '<span class="notice">%s</span>', __( 'This post may be outdated', 'text-domain' ) );
	}
}

Do keep in mind that some of the above mentioned methods could be used for both plugins as well as themes so use them wisely.

Fun with template tags: comments_template

On my last post I talked about dynamic_sidebar and some uses. It was a fun little experiment I wanted to do and share. Yes, I said experiment. That is how I learn. I read, do and then share. I know I’m not the only one that does that.

This time I dabbled with comments_template(). Yes, another one of the more common template tags. I wanted to dissect the function and see what really makes it unique. Okay, not really, I more or less wanted to look at the code and see how it gets the template file.

Core code

The code itself is about 90 lines. That is including the inline documentation. Without the inline documentation it is about 60 lines. Good to know. It means we don’t have to guess what is going on a lot. So let’s dive in shall we?

Okay, let’s break the function down, shall we?

The arguments

The first argument that is passed is the $file location. The second is whether or not to separate the comments. Simple. But what does that mean and how can we change this?

One way, of course is by passing some arguments ourselves. Let’s say we wanted to separate the comments, we would use:

<?php comments_template( '', true ); ?>

Or if we had our comment template in another location we would use:

<?php comments_tempate( '/inc/comments.php' );

That’s great if your comment template resided in the inc folder and was named comments.php. But what happens if you don’t have a comments.php file anywhere in your theme’s folder? Well, the nice part is that WordPress does account for that. The downside is that it creates a deprecated_file call. Yes, an error. If you read the following doc-block you can see why.

/**
 * @package WordPress
 * @subpackage Theme_Compat
 * @deprecated 3.0
 *
 * This file is here for Backwards compatibility with old themes and will be removed in a future version
 *
 */

I’m going to emphasize the part that really matters most:

and will be removed in a future version

Backwards compatibility is one thing that WordPress does really well; though this is one time I wish it would do it faster. At least for these files. There are a few other files but I’ll focus on this for now.

But why does it load that file if there is no comments.php file? Let’s look a little closer at what the function actually does. At least the parts that really make it load the needed file.

if ( empty($file) )
	$file = '/comments.php';

$theme_template = STYLESHEETPATH . $file;

$include = apply_filters( 'comments_template', $theme_template );
if ( file_exists( $include ) )
	require( $include );
elseif ( file_exists( TEMPLATEPATH . $file ) )
	require( TEMPLATEPATH . $file );
else // Backward compat code will be removed in a future release
	require( ABSPATH . WPINC . '/theme-compat/comments.php');

Not really much code, right? First it checks if the passed argument $file is empty and if it is it creates a simple string of '/comments.php'. Then, it creates a variable $theme_template with the constant TEMPLATEPATH and $file appended to it. Next we see a fairly familiar function apply_filters(). The filter name is comments_template.

We can then use a filter hook to change the location of our comments template. Granted we can do the same without even using the filter by simply passing it the location string to the function itself as we saw above, right?

It matters

Why am I bringing this up? I am bringing this up because the comments template file should be the place to be using wp_list_comments() as well as comment_form(). It doesn’t have to be comments.php that houses those template tags. It could be named anything you want, you just have to make sure you are loading the file properly.

Using a filter

One way is using a filter hook. As you noticed above the line:

$include = apply_filters( 'comments_template', $theme_template );

This what we can use. The code would look a little something like:

add_filter( 'comments_template', 'demo_path_to_comments_template' );
function demo_path_to_comments_template( ){
	if ( is_child_theme() && file_exists( get_stylesheet_directory() . '/inc/coms.php' ) ){
		return get_stylesheet_directory() . '/inc/coms.php';
	} else {
		return get_template_directory() . '/inc/coms.php';
	}	
}

Yes, quite a bit just for comments, right?

Using an argument

What’s super cool about using the core template tag and passing it the argument is that it will first look in the child theme ( if active ) and then the parent theme for the file you designate.

<?php comments_template( '/comments/pings.php', true ); ?>

In the above example it will first look for the pings.php file of the child theme ( if it is active ) and if that file does not exist it will load the parent file. Sort of what get_template_part() does. That is another neat little function for another post.

Seriously, it matters

I’m going to repeat this part because it bears repeating. The backwards compatibility file will one day be removed. Your users will thank you for not using the fallback file. It shouldn’t be a safety net for the theme. Besides, if you want the theme to be hosted in the repository it can’t have any errors.

Fun with template tags: dynamic_sidebar

The last couple of weeks I’ve been reading the core code more and more. I like it. Came to the conclusion I really don’t know every hook or filter. I don’t claim to though. I like knowing enough to make a functional theme or even a plugin. Yes, I’ve been recently dabbling with one but that’s for another post.

The reason for this post is to share some knowledge. Hopefully somebody finds this useful or helpful.

The function

For this post I will be using dynamic_sidebar(). It’s a fairly common template tag in themes. It gets a widgetized area and outputs them in a designated area. In order for that to happen you must first have a registered area. We do that by using register_sidebar(). For demonstrational purposes we will use:

register_sidebar( array(
	'name'          => __( 'Footer Area', 'dademo' ),
	'id'            => 'footer-area',
	'description'   => __( 'Add widgets here to appear in your sidebar.', 'dademo' ),
	'before_widget' => '<aside id="%1$s" class="widget %2$s">',
	'after_widget'  => '</aside>',
	'before_title'  => '<h2 class="widget-title">',
	'after_title'   => '</h2>',
) );

Great! So we created a widgetized area with an ID of footer-area. It can be anything we want but we will currently stick to simple naming conventions. Now, let us look at the core code, shall we?

The core code

The function itself is quite a few lines of code. Approximately 160 lines. I’m not going to post all of that code. The developer reference page has it and you can even view on trac. The ones that matter most for this post are two lines.

The first line:

do_action( 'dynamic_sidebar_before', $index, true );

The second line:

do_action( 'dynamic_sidebar_after', $index, true );

Notice something a little strange about it? I’m referring to the $index part of course. This is the neat part of it all. What does that little part mean?

Our hook

The cool part is that you can hook to specific widgetized areas if you want. I know you may be asking what I mean by this so I’ll demonstrate a little bit. Take our previous example of footer-area above and we will wrap it within a <section> element tag with a class of row.

add_action( 'dynamic_sidebar_before', 'demo_sidebar_before' );
function demo_sidebar_before( $index ){
	if ( $index == 'footer-area' ){
		echo '<section class="row">';
	}
}
add_action( 'dynamic_sidebar_after', 'demo_sidebar_after' );
function demo_sidebar_after( $index ){
	if ( $index == 'footer-area' ){
		echo '</section><!-- Widgetized footer area -->';
	}
}

From there it would render:

<section class="row">
	<aside id="recent-posts-4" class="widget widget_recent_entries">
	<h2 class="widget-title">Recent Posts</h2>
	<ul>
		<li>
		<a href="/2015/04/13/aesop-testing/">Aesop testing</a>
		/li>
		<li>
		<a href="/2015/04/13/sampling-some-code/">Sampling some code</a>
		</li>
		<li>
		<a href="/2015/04/08/another-gallery/">another gallery</a>
		</li>
		<li>
		<a href="/2015/04/08/gallery-7/">gallery 7</a>
		</li>
		<li>
		<a href="/2015/04/08/gallery-6/">gallery 6</a>
		</li>
	</ul>
	</aside>
</section><!-- Widgetized footer area -->

As you can see it created the section element and inside of it is a simple recent posts widget. Now, as I mentioned that is for specific widgetized areas. The thing to remember is to use the ID of the widgetized area to conditionally add or remove. It is that $index that is used to test. You can add things to every single dynamic_sidebar call by not even checking. Let’s say we have two widgetized areas. One in the footer and the other just above the content. We will call that section, “content-above.”

I know, very creative. I said it would be simplistic, didn’t I?

Okay, we wanted to add few things. Let’s say we wanted to add an image to both of those sections. We could edit two different files depending on how your theme is structured. Sounds a little painful, right? So, we will use our handy-dandy little hook:

add_action( 'dynamic_sidebar_before', 'demo_sidebar_before' );
function demo_sidebar_before( $index ){
	echo '<section class="row">';
	echo '<img src="' . get_template_directory_uri() . '/img/divider.png" />';
}
add_action( 'dynamic_sidebar_after', 'demo_sidebar_after' );
function demo_sidebar_after( $index ){
	echo '</section><!-- Widgetized area with image -->';
}

Pretty cool, right? What’s super cool is it will render like:

<section class="row">
<img src="path/to/img" />
<!-- widgets -->

</section><!-- Widgetized area with image -->
<section class="content row">
<!-- the_content -->
</section>

<section class="row">
<img src="path/to/img" />
<!-- widgets -->
</section><!-- Widgetized area with image -->

Yes, all that markup where ever you are using dynamic_sidebar().

Advanced fun

This part I’m writing as my left eye is twitching only because it deals with widgets in themes. Yes, I’ve never liked including them. This part deals with hooking to particular widgets in your theme.

Yes, you could simply edit the file that has the widget but where is the fun in that? This time we will use an action hook.

add_action( 'dynamic_sidebar', 'demo_sidebar' );
function demo_sidebar( $obj ){
	
	if ( $obj['callback'][0]->id_base == 'meta' ){
		printf( '<span>%s</span>', __( 'So much meta', 'dademo' ) );
	}
	// Alternatively
	// if ( preg_match( '/meta-/', $obj['id'] ) ){
	//	printf( '<span>%s</span>', __( 'So much meta', 'dademo' ) );
	// }
}

Does look a little complex, right? Let’s break it down a little.

First, we create the hook in line 1. Then we create our callback function in line 2. Doing good so far. Line 3 is where it does get a little odd. What does it mean? What does it mean?!

Okay, it may look a little complex to some but I’ll explain a little bit more.

When using dynamic_sidbar() it uses an array for the widgets. If there are no widgets then the function returns a false value. If there are it creates an associative array of the widget instance. That array is what we pass our callback function. In the example it is called $obj. In that array we have a key called callback. It, too, is an array.

We are looking for the first item on there because it holds the important part. The information about the widget object. The example is looking for the id_base of the widget. You know that little part you named when you registered the widget.

The alternative uses preg_match to match the ID of the widget’s instance. Yes, you can do specific instances as well.

Displaying multiple pages on one

Every so often I come across a theme or an implementation I like and wonder how it is being done. I like to dig behind the scenes on themes and see how they do things. Taking things apart to see how they work is a great way to learn.

One neat little tidbit I learned was how to create a page template that can use content from other pages and append it.

The steps

  1. Write code
  2. ???
  3. Have a celebratory drink

Step 1: Write Code

Yes, we will be writing quite a bit of it. Okay just enough to get the ball rolling and demonstrate the concept. One of the first things we need to do is figure out how many pages we want to show on our page template. I’ll use a smaller number like one to get started. You can add more if you want but because this is for demonstrational purposes we’ll keep it nice and simple.

So first, we will create our setting in the customizer:

$wp_customize->add_section( 'my_theme_page_sections', array(
	'title'    => __( 'The first page', 'text-domain' ),
	'priority' => 130,
) );
$wp_customize->add_setting( 'my_theme_page_1', array(
	'default'           => '',
	'sanitize_callback' => 'my_theme_sanitize_dropdown_pages',
) );
$wp_customize->add_control( 'my_theme_page_1', array(
	'label'             => __( 'Page 1 content', 'text-domain' ),
	'section'           => 'my_theme_page_sections',
	'priority'          => 30,
	'type'              => 'dropdown-pages',
) );
// the sanitize callback
function my_theme_sanitize_dropdown_pages( $input ) {
	if ( is_numeric( $input ) ) {
		return intval( $input );
	}
}

Next, we can create our actual page template.

/**
 * Template Name: Multiple pages
 *
 */
get_header(); 
	while( have_posts() ) : the_post(); // beginning of the loop
		// The page content of the selected page.
		// something basic can work like 
		the_content();
		wp_link_pages();
	endwhile; // end of the loop
	// Here is where the fun part is!
	rewind_posts();
	my_theme_selected_pages();
get_footer();

Yes, I’ve left out a lot of the markup but that’s only because the styling will be different for everyone. As you can see the part that creates the extra content is the function my_theme_selected_pages. That means we have to create this function somewhere. It can look something like:

$page_1 = intval( get_theme_mod( 'my_theme_page_1', '0' ) );

if ( 0 == $page_1 ){
	return;
}

for ( $number = 1; $number <= 2; $number++ ):
	if ( 0 != ${'page_' . $number} ) :
		$selected = new WP_Query( array( 'page_id' => ${'page_' . $number ) );
		// Our newly created loop with our selected page(s)
		while( $selected->have_posts() ): $selected->the_post();
			the_content();
			wp_link_pages();
		endwhile;
		wp_reset_postdata();
	endif;
endfor;

As you can see I have made it super simplistic. You can add more pages if you want. The key is making sure that $number<=2 matches the right amount of pages you want to add. So if you wanted to add five you would change the 2 to a 5. Yes, I left it at two because I forgot to change it.

Step 3: Celebrate!

Okay, maybe style it up if you want but I’m going to celebrate with some coke zero.

Learning with practice

The progress of my theme is decent. I have been learning how to work with Git and SVN more and more. I did recently have a little conversation with @ipstenu on Twitter about learning version control. Yes, I am still learning how to harness the power of simple commits and getting the hang of how to use branches and tags.

Which brought me to my main point: tutorials.

People on the web have dozens and dozens of them. Some are better than others and some are just beyond outdated. I was looking for a tutorial on how version control works using SVN. You would think I would find at least five. No. I found links talking about how SVN works but no real tutorial.

@ipstenu asked me if I could find one noob friendly tutorial. Of course I couldn’t. True, there wasn’t one. Yet. I have been contemplating creating a simple tutorial on how to use TortoiseSVN in a local setup. Sounds simple, right? Yes and no. The writing is a simple thing but taking all those screenshots to go with that will be a task in itself. I know I’m capable of it I just now have to find the time. Keeping in mind that even my current knowledge is not that great but it should suffice for the time being.

One of the first things that I learned was ‘commit’ so of course that will be the first topic. Next in line is ‘branches’ and ‘tags. and how they work. That is one thing I still haven’t yet mastered through a GUI. Just takes me back to when I was in Junior High and learning about computers but that is another story.

Yes, tutorials have helped me understand certain things but often times I don’t really learn unless I put forth the effort. Learning by practice is a great method and a great way for me and others to learn as well. I just hope that I can get my tutorial written out so that people understand. Although this has given me an idea for a future post: translation.

Code – Theme status: structure

So far I have been experimenting with adding theme options to my theme for when I get ready to actually share the theme with the WordPress community. I have the basic file structure that I want to be using for themes down the road. It is of course HTML5 and I’ll try and mess around with CSS3 and transitions eventually.

The basic markup is:

< !doctype html>


  


This should be a rough guideline for the future themes and pages I create. The next stage will be using PHP to display all the dynamic content.

The reason I think this is a good structure is because it almost replicates a book. The <header> tags act like the index for the site while the <footer>  acts as information and the <div> with the class of content is, of course, the content of the site.

Next step: files to be used and the folder structure.

Code – some random javascript conditionals

Warning: what you are about to read deals with code.

Working with PHP is fun for me. At times it can be a pain but I still love it. One thing that I have been trying to find is an AJAX media query for loading certain stylesheets when the viewport is at certain widths. I know that it can be achieved but what I’m wondering is how I would pull this off with WordPress.

jQuery makes it easier to achieve since it is a library to help the development process. I know I will begin with that and PHP but the next step will be creating the necessary files.

Of course I want to think mobile first but my dilemma is that would require http requests – to the best of my knowledge. The good side about that is that yes it would load the needed stylesheet and won’t do any browser sniffing so it relies on the viewport and resolution of the device.

On the plus side I can pretty much start it fairly quickly with a simple jQuery call.

$( window ).resize( function(){
  var width = $( window ).width();

    if ( width < 640 ){
      // Load this stylesheet
      } else if ( 641 < width < 800 ) {
      // Load this stylesheet
      } else {
      // Load this one
      };
});

Now what this really does is check when the screen is resized and not really for the initial width which is what I need to check for. So, what I really need is to first check the width and load the stylesheet accordingly and if the window gets resized run that same check. So I can create a new self invoking function and see how that would work.

var w_check = (function(){
  if ( width < 640 ){
      // Load this stylesheet
      } else if ( 641 < width < 800 ) {
      // Load this stylesheet
      } else {
      // Load this one
      };
})();
$( window ).resize( w_check() );

But then I run into the issue of having more than one stylesheet opened at once and risking the theme getting all warbled. 😐 Yes, they would still have media queries but can I safely use all at once without hurting the layout? I think I may just have to test this out before I deploy. Notepad++, here we come!!