A chat group I was in the other day lead me to looking for a set of these helper functions in the code we were discussing … I didn’t find them. Well, I did find them in use but I did not find where they were defined. Next stop, the WordPress core … and there they were.

Now, as the title may suggest I am referring to the following WordPress core functions:

• __return_true() – returns the Boolean state of true
• __return_false() – returns the Boolean state of false
• __return_zero() – returns a value of zero (0)
• __return_empty_array() – returns an empty array, as in array()
• __return_null() – returns null (or void)

All of these functions have a very similar structure and were implemented at WordPress version 3.0.0, with the exception of `__return_null` which will be introduced at WordPress version 3.4 per their definitions in ‘../wp-includes/functions.php‘. For example, here is the code for `__return_true`:

function __return_true() {
	return true;
}

Why are these great helper functions? Simple really … they provide easy to remember, and very useful, callback functions for filters. You should not need to write your own return functions now, just __return_* it instead.

I call it Tri-Account Security ™. The idea is actually very simple and quite easy to implement. All it really requires is forming the habit of using three (3) separate accounts, each with their own specific purposes.

Let me break them down for you:

1. The Primary Administrator
2. The Primary Editor
3. The Primary Contributor

The first account, The Primary Administrator, is the installation account. This account is just for the purpose of doing the installation. This account is also the one to use for upgrading; adding new themes; or, adding new plugins. Make the name relatively obscure; and, make the password very, very strong (not too strong to forget, but very difficult to guess … by human or machine). Also, never post with this account … ever!

The second account, The Primary Editor, is your publishing account. I would suggest a more common user name with a strong password; this account will be used to actually post content to your site. Although you shouldn’t normally need to actually post with the account it’s generally fine to do so.

The third account, The Primary Contributor, is your public facing account. Use a simple username, one that makes sense to see in the post meta details, such as the commonly used “posted by …” text. Also note this username, like all usernames in a default installation will appear as part of the author URL in a browser’s address bar. The password for this account can be simple, but should still be “strong” … but if someone breaks into it they really will not have that much access to anything so you can feel secure in making it very easy to remember.

Aside from the “strength” of the passwords recommended for each account above, I will not be going any further into their creation in this post (but maybe I’ll write one down the road) except to make one final suggestion for creating a strong password: use an appropriate amount of common words, or phrase, (without spaces) perhaps five (5) for the Administrator, four (4) for the Editor, and three (3) for the Contributor.

Now that we have the three accounts with a basic premise for each set out, let’s have a look at actually putting them to use in a couple of examples.

Example 1

Log in with your Contributor account and write the greatest post ever written … no really, go for it! I’ll wait …

OK, now that we have the post written, and you have clicked the “Submit for Review” button (notice how it does not say “Publish”); log out and log back in with your Editor account. Once logged in with your editor account, navigate to the Posts > All Posts Administration Panel and locate your greatest post ever (it should be at or near the top of the list, remember it’s great; you would expect it to be lost at the bottom of the page?!)

Now either using “Edit” or “Quick Edit” you can change the post from “pending review” to “published”… and now the greatest post ever written is available for the world of the Internet to read. Congratulations!

You may also notice the only author information readily available will be your Contributor ID; or in other words, your pen name … and therefore protecting the identity of both your Administrator account and your Editor account.

Example 2

You are about to write the second greatest post ever written (you did follow Example 1, right?) but notice there is an update that needs to be addressed. As a Contributor you really have no control whatsoever over the WordPress installation, its management, or its administration.

Oh, administration … we have an account for that. Simply log out of your Contributor (or Editor) account, and log back in with your Administrator account. Perform any updates and/or maintenance. Log out. Done!

Now, log back into your Contributor account and get back to writing the second greatest post ever written …

1. Find the font you like
2. Make sure the font license allows you to use it!
3. Upload the font to your site / include with your theme package.
4. Write the CSS.

OK … that seems simple enough, four relatively easy steps to follow. Let’s give it a run.

Step 1, I went to Google Web Fonts and browsed for something I liked; I chose “Glass Antiqua” by Denis Masharov¹.

Step 2, the font is licensed under the SIL Open Font License, Version 1.1, which is compatible with the GNU GPLv2 License (something I strive to release all projects under).

Step 3, I uploaded the font and license text to my current theme’s font folder.

Step 4, I made the necessary CSS modifications to, in this case, change the site’s title font.

@font-face {
  font-family: 'Glass Antiqua';
  src: url('fonts/GlassAntiqua-Regular.ttf') format('truetype');
}

#blog-title {
  /* font-family: "Copperplate Gothic Bold", Arial, sans-serif; */
  /* font-size: 30px; */
  font-family: "Glass Antiqua", cursive;
  font-size: 70px;
  ...

… and with a tweak to the `font-size` value, we’re done!

Very easy, and points for not having to worry about being behind a firewall, intranet or local test environment as this method will work in those cases as well.

… how to remove the website section when leaving a reply/comment …

The solution may be obvious to some and can be readily derived from the information found on the WordPress codex page for the `comment_form` function, but if you are new to WordPress and/or not familiar with writing a function to use with `add_filter`, here is a very simple and working snippet to use in your theme:

function wpfa_remove_comment_website_section(){
    $commenter = wp_get_current_commenter();
    $req = get_option( 'require_name_email' );
    $aria_req = ( $req ? " aria-required='true'" : '' );
    $fields =  array(
        'author' => '<p class="comment-form-author">' . '<label for="author">' . __( 'Name' ) . '</label> ' . ( $req ? '<span class="required">*</span>' : '' ) .
                    '<input id="author" name="author" type="text" value="' . esc_attr( $commenter['comment_author'] ) . '" size="30"' . $aria_req . ' /></p>',
        'email'  => '<p class="comment-form-email"><label for="email">' . __( 'Email' ) . '</label> ' . ( $req ? '<span class="required">*</span>' : '' ) .
                    '<input id="email" name="email" type="text" value="' . esc_attr(  $commenter['comment_author_email'] ) . '" size="30"' . $aria_req . ' /></p>',
        'url'    => '' /** removes website section */,
    );
    return $fields;
}
add_filter( 'comment_form_default_fields', 'wpfa_remove_comment_website_section' );

Ideally, this will be placed in the ‘functions.php’ file of your theme, but better yet this should be included in the Child-Theme you created of the theme you want to modify.

Yes, seriously. Although this sort of thing is not too likely to exist in the wild here are a few tips and idea to keep in mind when developing a theme.

Let’s start from the end with ‘post-format’ posts and work our way back to the beginning. It wasn’t all that long ago WordPress introduced default post-formats that could be easily added to themes. Here’s a one-liner to put in your functions.php file that does it all, well it’s a good example from the codex showing two post-formats:

add_theme_support( 'post-formats', array( 'aside', 'gallery' ) )

Post-formats have been around since WordPress Version 3.1, if you are not familiar with them yet you should go back and read more about them.

Our next step back is to Sticky Posts introduced back in version 2.7. If you are not familiar with sticky posts then definitely take a few moments to read the articles linked to … I can wait.

So far, so good … right? Good!

Now let’s get to the beginning of the post title: No-Title; and, yes, this is something that should be addressed when developing a theme. The Shadow knows … otherwise one may never know the imagination of the end-user, or if their personal taste demands one (or many) posts are published without a title. Generally speaking, each of these items are handled well enough on their own but what happens when you combine them? If you have thoroughly tested your theme then most any combination of these elements should have been easily and clearly addressed; most of which can be done with simple CSS, too.

The key CSS elements to address for these items are the following:

• .format-aside
• .format-gallery
• .format-< post-format > – substitute < post-format > with the appropriate term
• .sticky

There may, or may not, be a theme CSS element used for a post without a title but that is well beyond the scope of this post; just remember to test each ‘post-format’ with and without a title.

Now last, but not least, the simple CSS element to remember for the final testing: ‘.format-< post-format >.sticky’ … again substituting the < post-format > for *all* of the ‘post-formats’ used in the theme. Note there is no space between, for example, .format-aside and .sticky the element would be: .format-aside.sticky … these elements are automatically generated by WordPress if the theme uses the `post_class` function correctly.

Granted this was a bit long written but hopefully helpful. It’s just something I found that required a lot more to properly address than what I first suspected as I was updating my theme Desk Mess Mirrored to version 2.0.

Themes are REQUIRED to use wp_title filter to filter wp_title() (RECOMMENDED), or pass argument to wp_title() (OPTIONALLY), in order to modify document title content

This has been discussed, worked through, and for the most part sorted out … but there doesn’t appear to be any sort of example code to work from. This presented an opportunity to have a look around the WordPress codex and the source code for some ideas how to filter the `wp_title` function.

Essentially, the idea behind the code (below) is to take a basic function call of `wp_title` add some relevant text (a la default themes: Twenty Ten / Twenty Eleven) then filter it back into the function; and finally to echo this to the HTML <title> tag.

<?php
if ( ! function_exists( 'wpfa_wp_title' ) ) {
    /**
* WPFA WP Title
*
* Utilizes the `wp_title` filter to add text to the default output
*
* @package WPFA_WP_Title
* @version 0.2 - last revised April 26, 2012
*
* @link http://codex.wordpress.org/Plugin_API/Filter_Reference/wp_title
* @link https://gist.github.com/1410493
*
* @param string $old_title - default title text
* @param string $sep - separator character
* @param string $sep_location - left|right - separator placement in relationship to title
*
* @return string - new title text
*/
    function wpfa_wp_title( $old_title, $sep, $sep_location ) {
        global $page, $paged;
        /** Set initial title text */
        $wpfa_title_text = $old_title . get_bloginfo( 'name' );
        /** Add wrapping spaces to separator character */
        $sep = ' ' . $sep . ' ';

        /** Add the blog description (tagline) for the home/front page */
        $site_tagline = get_bloginfo( 'description', 'display' );
        if ( $site_tagline && ( is_home() || is_front_page() ) )
            $wpfa_title_text .= "$sep$site_tagline";

        /** Add a page number if necessary */
        if ( $paged >= 2 || $page >= 2 )
            $wpfa_title_text .= $sep . sprintf( __( 'Page %s', 'wpfa-wp-title-textdomain' ), max( $paged, $page ) );

        return $wpfa_title_text;
    }
}
add_filter( 'wp_title', 'wpfa_wp_title', 10, 3 ); ?>

Hopefully this will be useful, or maybe it will not … but it will be found in the next release of Desk Mess Mirrored as that is the theme where I first wrote and tested it with.

Enjoy!

As I was recently updating some of my plugins in preparation for WordPress 3.3 I decided to better implement the style elements being used in these plugins. The current best-practice methods point to using the `wp_enqueue_scripts` hook with the `wp_enqueue_styles` function. Let’s get our eyes on a snippet for this:

function WPFA_Styles() {
        wp_enqueue_style( 'WPFA-Plugin-Style', plugin_dir_url( __FILE__ ) . 'wpfa-plugin-style.css', array(), '0.1', 'screen' );
}
add_action( 'wp_enqueue_scripts', 'WPFA_Styles' );

We create a function to enqueue our stylesheet; then we use `add_action` to hook into `wp_enqueue_scripts` and we’re done … or are we?

What if we wanted to let the end-user add their own styles to the plugin CSS elements but not have them over-written with the next plugin update? Easy, just add another `wp_enqueue_style` into the `WP_Styles` function like this:

function WPFA_Styles() {
        wp_enqueue_style( 'WPFA-Plugin-Style', plugin_dir_url( __FILE__ ) . 'wpfa-plugin-style.css', array(), '0.1', 'screen' );
        wp_enqueue_style( 'WPFA-Plugin-Custom-Style', plugin_dir_url( __FILE__ ) . 'wpfa-plugin-custom-style.css', array(), '0.1', 'screen' );
}
add_action( 'wp_enqueue_scripts', 'WPFA_Styles' );

This is fine, but what if the custom stylesheet does not exist? Although it will not cause any significant issues there is no reason to actually enqueue a file that does not exist. The solution to this is straight forward as well, just check if the file is available to be used … but how?

Let’s look at the complete example to see where I add the `is_readable` conditional check:

/**
 * Enqueue Plugin Styles
 *
 * Adds plugin stylesheet and allows for additional custom stylesheet to be added by end-user. Custom stylesheet is only enqueued if it is available to be used.
 * 
 * @package     WPFA_Styles
 * @link        http://wpfirstaid.com/2011/11/enqueue-plugin-custom-stylesheet/
 * @version     0.1
 * @author      Edward Caissie <thedoctor@wpfirstaid.com> 
 * @copyright   Copyright (c) 2010-2011, Edward Caissie
 * 
 * @internal    Note: all stylesheets enqueued in this manner are expected to be in the root folder of the plugin.  
 */
function WPFA_Styles() {
        /** Enqueue Style Sheets */
        wp_enqueue_style( 'WPFA-Plugin-Style', plugin_dir_url( __FILE__ ) . 'wpfa-plugin-style.css', array(), '0.1', 'screen' );
        // Only enqueue if available
        if ( is_readable( plugin_dir_path( __FILE__ ) . 'wpfa-plugin-custom-style.css' ) ) {
            wp_enqueue_style( 'WPFA-Plugin-Custom-Style', plugin_dir_url( __FILE__ ) . 'wpfa-plugin-custom-style.css', array(), '0.1', 'screen' );
        }
}
add_action( 'wp_enqueue_scripts', 'WPFA_Styles' );

Note the use of `plugin_dir_path` in the conditional check, this is key as the `is_readable` function requires the path and will not work using the URL.

This may appear as a Mallory-Everest idea, but there have been use-cases where an additional custom stylesheet solved the issues at hand. Hopefully this will be of use to you.

Although I have complete confidence in the stability of the beta versions I would still only suggest / recommend this practice to those with a reasonable knowledge of PHP and the ability to recover from any potential catastrophic disaster (read: BACK-UP everything first!!!).

Here are the basics, as each version changes these may not be exactly the same but should still serve as a general guideline:

1. Back up your WordPress installation (all of it).
2. Using your preferred text editor, open the /wp-includes/version.php file in core to edit.
3. Find and change $wp_version to a ‘point value’ greater than the current version, for example: 3.4-alpha.
4. Go to your the Administration Panels (“Dashboard”) of your WordPress installation.
5. Scroll to the bottom of the page and click on the “stay updated” link in the bottom-right corner. (Refresh the page if the link is not there.)
6. Follow any additional prompts, such as updating the database, etc.

You should now be running the latest version of ‘trunk’.

Of course there is a widely used plugin (WordPress Beta Tester) by Westi that does most if not all of the above for you … I just like to do this manually.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

If you do not want to display this text it is actually very easy to do. It can be done with a line of CSS or a minor edit to the theme in question. The following is based on using the comment_form function in its default state:

<?php comment_form(); ?>

To hide the message above with CSS, add one of the following to the end of your style.css file:

p.form-allowed-tags { display: none; }

p.form-allowed-tags { visibility: hidden; }

Using the display property “removes” the block of text whereas using the visibility property simply “hides” the text leaving the block being filled with nothing. Which method is best will be more due to aesthetics than anything else.

If you want to edit your theme files, look into the comments.php template file (again a standard default naming convention, your theme may vary), and find the default code noted above and change it to the following:

<?php comment_form( 'comment_notes_after=' ); ?>

Always remember, any edits you make to the theme may be over-written with the theme’s next update … always back-up your work.

The function itself can be found in all the themes currently available from Cais at BuyNowShop.com via the WordPress Extend Themes repository. There have been a few minor changes to the function since it was introduced; and, it is just recently undergoing much more dramatic changes.

That being the case, I thought this would be a great opportunity to revisit the function and discuss what has changed since the last time I wrote about it here.

// Start BNS Dynamic Copyright
if ( ! function_exists( 'bns_dynamic_copyright' ) ) {
  function bns_dynamic_copyright( $args = '' ) {
      $initialize_values = array( 'start' => '', 'copy_years' => '', 'url' => '', 'end' => '' );
      $args = wp_parse_args( $args, $initialize_values );

      /* Initialize the output variable to empty */
      $output = '';

      /* Start common copyright notice */
      empty( $args['start'] ) ? $output .= sprintf( __('Copyright') ) : $output .= $args['start'];

      /* Calculate Copyright Years; and, prefix with Copyright Symbol */
      if ( empty( $args['copy_years'] ) ) {
        /* Get all posts */
        $all_posts = get_posts( 'post_status=publish&order=ASC' );
        /* Get first post */
        $first_post = $all_posts[0];
        /* Get date of first post */
        $first_date = $first_post->post_date_gmt;

        /* First post year versus current year */
        $first_year = substr( $first_date, 0, 4 );
        if ( $first_year == '' ) {
          $first_year = date( 'Y' );
        }

      /* Add to output string */
        if ( $first_year == date( 'Y' ) ) {
        /* Only use current year if no posts in previous years */
          $output .= ' © ' . date( 'Y' );
        } else {
          $output .= ' © ' . $first_year . "-" . date( 'Y' );
        }
      } else {
        $output .= ' © ' . $args['copy_years'];
      }

      /* Create URL to link back to home of website */
      empty( $args['url'] ) ? $output .= ' <a href="' . home_url( '/' ) . '" title="' . esc_attr( get_bloginfo( 'name', 'display' ) ) . '" rel="home">' . get_bloginfo( 'name', 'display' ) .'</a>  ' : $output .= ' ' . $args['url'];

      /* End common copyright notice */
      empty( $args['end'] ) ? $output .= ' ' . sprintf( __('All rights reserved.') ) : $output .= ' ' . $args['end'];

      /* Construct and sprintf the copyright notice */
      $output = sprintf( __('<span id="bns-dynamic-copyright"> %1$s </span><!-- #bns-dynamic-copyright -->'), $output );
      $output = apply_filters( 'bns_dynamic_copyright', $output, $args );

      echo $output;
  }
}
// End BNS Dynamic Copyright

What’s changed:

1. A `function_exists` conditional check has been added
2. Better internationalization string formating has been applied.
3. Default arguments have been set to generate a common notice.
4. The `apply_filters` function has been implemented to allow for easier customization.

Also to note, the defaults are now written slightly different than the orginal generated copyright notice structure. The following are the current defaults:

• ‘start’ => “Copyright”
• ‘copy_years’ => the copyright symbol + the dynamically generated years with published posts
• ‘url’ => points to the top level domain with the web site title as anchor text
• ‘end’ => “All Rights Reserved.”

All of these paramters are now easily customized using the common WordPress structure, for example:

bns_dynamic_copyright( 'start=Mine, All Mine!&end=This means you, scrapers!' );

… would produce the following for this site (as of this writing):

Mine, All Mine! © 2009-2011 WP First Aid This means you, scrapers!

Of course, the above may not be appropriate for your own website … or maybe it is.

All the same, feel free to implement this updated function; and, don’t forget to look for it in the next releases of themes from BuyNowShop.com

Enjoy!