Advent Calendar- How to disable comments for WordPress pages in any theme

Posted in: WordPress Plugins

Usually you don’t need comments on pages. Unfortunately, WordPress doesn’t offer a separate option to leave comments on posts on and turn them off for pages. If your theme calls comments_template(); in its page.php and you don’t want to break automatic updates, you cannot just remove the function call, because it will be overwritten with the next update.

No problem. There’s an hook for that. It’s a filter called … wait for it … comments_template. We can change the path to the comments template here – if haven’t figured that out already. Let’s build a small plugin.

So, what do we do? We hook into comments_template(); and change the path. Our new path should point to an existing file without any HTML output. In this case, we use just our plugin file, because we know it exists and we control the output.

As you may have noticed our plugin file is included two times: First as a plugin, later as a replacement for comments.php. The function_exists() check prevents any You cannot redeclare … errors.

Putting this all together …

<?php # -*- coding: utf-8 -*-
/**
Plugin Name: Disable Comments On Pages
Version:     1.0
Author:      Thomas Scholz
Author URI:  http://toscho.de
License:     GPL
*/
// This file is not called from WordPress. We don't like that.
! defined( 'ABSPATH' ) and exit;

// If the function exists this file is called as comments template.
// We don't do anything then.
if ( ! function_exists( 't5_disable_comments_on_pages' ) ) {
	/**
	 * Replaces the path of the original comments template with this
	 * file's path on pages.
	 *
	 * @param  string $file Original comments template file path.
	 * @return string
	 */
	function t5_disable_comments_on_pages( $file ) {
		return is_page() ? __FILE__ : $file;
	}

	add_filter( 'comments_template', 't5_disable_comments_on_pages', 11 );
}

Force Reload of Scripts and Stylesheets in your Plugin or Theme

Posted in: WordPress Tutorials

If you’re developing a WordPress theme or plugin you may have had the problem that scripts or stylesheets are not reloaded from the source when you refresh the page because they are cached somewhere on the way from the server to the browser. There are various methods to suppress this behaviour like disabling the browser cache in the options or by using a web development add-on. Sometimes this simply does not work because it’s not always apparent where the content is cached since there are so many possibilities and you may have missed to disable all of them.

WordPress provides a simple method to ensure that all stylesheets and scripts are reloaded from the source when they have changed by providing a version parameter:

wp_enqueue_script( $handle, $src, $deps, $ver, $in_footer );
wp_enqueue_style( $handle, $src, $deps, $ver, $media);

You can increase the $ver parameter every time you’ve changed the files:

wp_enqueue_script( 'my_script', 'my_script.js', '', '0.11' );
wp_enqueue_style( 'my_style', 'my_style.css', '', '0.11' );

The URL of the stylesheet/script will be changed to ‘.../my_script.js?ver=0.11‘ so that every caching system detects the changed file and reloads it from its source and the user always gets the recent version.

But to change the version number manually every time in the development stage would be a bit tedious and you’re a programmer, right? So let’s automate this:

wp_enqueue_script( 'my_script', 'my_script.js', '', time() );
wp_enqueue_style( 'my_style', 'my_style.css', '', time() );

The value of time() changes every second so the version ID of the file changes constantly and it’s reloaded from the source and not from some cache.

It’s a bit disadvantageous that you have to substitute the time based version parameter by a “real” version number every time you deploy your code since the actual user still should have the benefits of cached scripts and stylesheets. Let’s extend the idea:

define ('VERSION', '1.1');

function version_id() {
  if ( WP_DEBUG )
    return time();
  return VERSION;
}

wp_enqueue_script( 'my_script', 'my_script.js', '', version_id() );
wp_enqueue_style( 'my_style', 'my_style.css', '', version_id() );

This way you can make sure that in your development environment everything is reloaded from source all the time but a productive server takes advantage of caches.

WordPress Custom Post Types Get Into The Loop

Posted in: WordPress Tutorials

WordPress started a new era with the Custom Post Types for developers in the WordPress environment. The possibilities are numerous and primarily from the knowledge of the developer dependent. Nevertheless, there are so many tutorials how to use Custom Post Types in WordPress, but that is not enough – at least not in most cases and therefore are various other steps necessary to make the use of CPT more efficient and smooth.

In this article I would like to briefly explain how to get content of Custom Post Types in the loop of WordPress. This is not a complete guide, but please feel free to add tips, critics, hints in our comment area.

Continue reading …