Many of the leading WordPress security plugins have the ability to force/require strong passwords for users. But one of the requests I’ve received from people is if there is a way to require passwords to be of a certain length. It seems that some users who work with clients are finding that some clients will reset a password to something “easier to remember” but not entirely secure, or the developer is trying to enforce a specific “password policy” and one of the aspects of a policy specifies a certain number of characters.

How to Set a Password Length Requirement

Setting a password length requirement is fairly easy since WordPress already provides a hook that occurs before a password is actually reset.  The hook is validate_password_reset, and it allows developers to verify aspects of the user-entered password before passing it through the password reset function.

Here is an example code snippet:

add_action('validate_password_reset', 'wps_password_min_length_val', 10, 2);
function wps_password_min_length_val($errors, $user){
    if( strlen($_POST['pass1-text']) < 12 ){
        $errors->add('password_too_short', 'ERROR: Password is too short.');
    }
}

The basics of this function (which can be placed in an active theme’s functions.php file or a custom plugin) are as follows:

• The WordPress hook being used is validate_password_reset.
• The function is comparing the value entered into the password reset box (pass1-text) and checking the length of that string (strlen) and making sure that if the entered password value is less than 12, then the following $errors will be rendered out on the screen.
• And since there are “errors” in the password reset process, the process does not continue and returns to the screen to allow the user to try again to create a password that “passes the test.”

You can try this out on your own site by creating a test user, then proceed to reset the password with a shorter password value.

While there are plugins that may perform this functionality, if you can do it with this simple code snippet, why clutter the plugins area with unnecessary plugins.

If you enjoy or find these types of posts useful, please let me know or request a type of tutorial/code solution in the comments below.

Many WordPress users learn about using Dashicons when they go to create their first Custom Post Type and assign a Dashicon to represent that Custom Post Type in the Admin menu.  But then the frustration begins as soon as you attempt to use a Dashicon on the frontend of the site.

The developer resources at WordPress.org make it extremely easy to copy/paste either the Glyph, HTML, or CSS version of a Dashicon.  But if you have ever tried to copy/paste a Dashicon into a widget area or a post you would have experienced the frustration of nothing showing up.

Why Dashicons?

The reason the Dashicon doesn’t show up on the frontend is that the Dashicon stylesheet is not being enqueued to be used on the frontend.  So here are two code snippets you can use to start using Dashicons on your WordPress website immediately.

Add Dashicons as a Dependency

function load_my_styles(){
    wp_enqueue_style( 'mycustomstyle', get_stylesheet_uri(), 'dashicons' );
}
add_action( 'wp_enqueue_scripts', 'load_my_styles' );

Simply Enqueue Dashicon Stylesheet

function enqueue_dashicons(){
    wp_enqueue_style( 'dashicons' );
}
add_action( 'wp_enqueue_scripts', 'enqueue_dashicons' );

I hope this helps you take advantage of Dashicons in your WordPress site.  Let me know how you utilize font icons in your web development.

For many WordPress users who are stepping beyond the basics of WordPress and starting to customize different parts of a site based on the site’s template hierarchy, it can get pretty daunting to figure out WHICH page template is being used to render WHICH part.  The heart of this answer is in understanding more about WordPress template hierarchy. There is even a very useful visual map to help find your way to the right template.

But this post is focused on another seldom talked about feature in WordPress that works with every properly coded theme.  I’m talking about the body class.

<body <?php body_class(); ?>>

The above code can be found in almost all WordPress themes and will output the multiple classes being used on a specific page in the HTML body element.  For example, if you were to visit a blog post page and look at the source code, you might see the HTML body element and corresponding classes that look like this:

<body class="post-template-default single single-post postid-2675 single-format-aside logged-in admin-bar no-customize-support one-col c1">

This long string of classes actually tells us a LOT about what area of a site the visitor is viewing along with other bits of information.  Now since the above example is fairly long, I’m going to pull out several of the classes to go into a deeper explanation.

• single – This class tells us we are in a singular post.  It could be a standard blog post; it could be a single post from a custom post type.  This also tells us that the web page is not a feed or archive view.
•  single-post – This class tells me we are on a singular post from the “post” custom post type.  If we had a custom post type called “reports”, this class would appear as single-reports.
• postid-2675 – This class is generated by the actual Post ID of the post.  For example, if you wanted to apply some CSS style to this specific post, you could target .postid-2675{color:#ff2200;} (or something along those lines).
• single-format-aside – This class indicates that the post being displayed is a single post that is using the Post Format Aside.
• logged_in – This class will show up in the body class for any user that is actively logged into the site.

There are also additional classes in the above HTML body element example that are more theme specific to indicate the number of columns, custom layout options, and more.  Other types of classes you might see, depending on the page being referenced: home, page, blog, archive, category, author, etc.

The ability to identify and decode the information contained within the string of HTML body element classes can assist any developer in not only being able to target specific views but also can grant knowledge as to which template file a view is using within the theme.

Helpful Information for the Voce Theme

The Voce Theme has a custom solution based on a conditional logic that helps serve up different template files based upon core WordPress template hierarchy.  The simple response is that everything, every view and location on the site, is served through the index.php template file in the theme folder. But if you were to dig into the actual PHP files, you would see that there is a solitary function in the index.php file…. wpsvoce().  While this post won’t go into how this function works, I will say that this function builds and renders the layout structure that you see and use for your WordPress sites.

At this point, we as WordPress developers, really need to understand the basics of template hierarchy.  But for the purpose of this post, I’ll be focusing solely on how this relates to the Voce Theme and how we can interpret the above HTML body element classes to find the correct page template to edit.

Reminder: Never edit the /voce-theme/ (parent theme) files.  Always copy a page template file to your child theme’s /templates/ folder.  If no /templates/ folder exists in the child theme you can simply create one.

Hierarchy is important in any WordPress theme and especially with the Voce Theme.  At the base level, everything falls to the content.php file in the templates directory.  All the other content-***.php files are based on several conditions.

• Sometimes the theme will look for Post Formats being used.  Example: content-quote.php would be used to display any post that contains the Quote post format option.  If a post contains the Quote post format option and WordPress is unable to find a content-quote.php file, then it will attempt to display the post using the base content.php file.
• Sometimes the theme will be displaying an Archive page, and in this example, WordPress will be looking for the content-archive.php template file.  If that file is not found, then the post will be displayed using the content.php file.
• Sometimes the theme will be on a WordPress Page, and so WordPress will be looking for the content-page.php template file.  If that file is not found, then the page will be displayed using the content.php template file.

If you want to dig a little deeper and see exactly how the Voce Theme makes a choice as to which template part is loaded, you can look at the loops.php file in the parent theme folder.  You can look for the get_template_part(‘template/content’, **********); code to identify which conditional is loading which template file.

So what does this mean for customizing the look of content?

If you were to look at the HTML body element list of classes and see a CSS class of single-post.  You can be sure that WordPress will be looking for the content-single.php template file to render that content.  And the way template hierarchy works is that WordPress will first look in the child theme for that /templates/content-single.php template file and if it doesn’t find that template file in the child theme, WordPress will look for the /templates/content-single.php template file in the parent theme.

Now, this is where it gets a little more complicated because if both of those file locations are not found, the Voce Theme then starts looking in the child theme for /templates/content.php and if not found look for the /templates/content.php in the parent theme.

What template files are included by default in the Voce Theme?

• content.php – Lowest level fallback method of displaying content if no other template file is found.
• content-archive.php – This is used by any archive view.
• content-aside.php – This is used when a specific post has the Post Format Aside assigned to it.
• content-attachment.php – This is used to display a specific attachment page.
• content-page.php – This is used to display any page (WordPress Pages).
• content-quote.php – This is used when a specific post has the Post format Quote assigned to it.
• content-search.php – This is used when a search result is rendered.
• content-single.php – This is used for single post pages.
• content-status.php – This is used when a specific post has the Post Format Status assigned to it.
• no-results.php –  When no post is found from the query (but the URL is valid) this template is used.
• 404.php – This is used when an invalid URL is used. 404 Error.

Anytime you want to make modifications to any of these files; you should copy/paste a copy of that file into your child theme’s /templates/ folder.

WordPress has a method of splitting your content to only show the “top half” on the is_home() conditional location.  (This is normally the “Blog” feed page in WordPress.  It could be your homepage, or it could be a custom page depending on your theme and setup.)  This “splitting method” is called the “Read More” link.

The “Read More” link is identified as <!--more-->  in the code/content area of your WordPress post/page.  The location in your post content that contains this “Read More” link will return an active link from the blog feed to the full post page.  What happens next when a reader clicks on the “Read More” link presents the “issue” that WordPress owners experience.

The “Read More” link jumps to the place in the code where the <!–more–> tag had been placed, essentially chopping off the top of the post.  While some themes and designs may not be bothered by this experience, many developers create custom user experiences that differ from the blog feed and the individual post page.  Therefore the “Read More” link jump can be a jolting feeling for the readers.

The following piece of code can be placed in the active theme’s functions.php file and will remove the jumping element of the “Read More” link.  This code snippet will provide a straight link directly to the post page allowing for the intended theme experience to occur.

function eliminate_readmore_jump( $link ){
    $offset = strpos( $link, '#more-' );
    if ($offset) {
        $end = strpos($link, '"', $offset);
    }
    if ($end) {
        $link = substr_replace($link, '', $offset, $end-$offset);
    }
    return $link;
}
add_filter('the_content_more_link', 'eliminate_readmore_jump');

An example of when this code might be useful would be when a featured image is only used on the full single post page but not on the blog feed.  If the “Read More” jump process bypasses the visual experience of the featured image the effect of the blog could be diminished.

WordPress has a function called wpautop() that very kindly “autowraps” and adds paragraph tags (<p></p>) around elements of your content.  While this is extremely helpful for users, those that may be more unfamiliar with HTML and those that only want to use WordPress as a content publishing platform.  Those users that desire more control over the structure of the site may want to manage what elements exist or don’t exist in the content structure.

For a long time, WordPress users have had access to filtering out the wpautop() function by adding a simple line of code to their functions.php file of their active theme folder.

remove_filter( 'the_content', 'wpautop' );

But the above code can also leave users with an unintended issue.  This code snippet will remove ALL the auto-inserted paragraph tags.  To truly have control over when and where this wpautop() function interacts with content, we need to be able to manage this on an individual post/page level.

This is where WordPress’ Custom Fields come to the rescue. If you do not see a metabox on your post/page editor screen, you may need to enable the metabox to be visible from within the Screen Options located inside the drop-down tab in the upper right of your screen window.

Once you enable Custom Fields by checking the box, you will see a new metabox appear in the edit post/page area.

From within this metabox, we can press the “Enter New” link to create a newly named unique field. In the “Name” input box enter the text wpautop.  (Side Note: After your initial time of adding the wpautop value to the Name input box, all proceeding attempts to add this field can be done through the drop-down box.) Then in the corresponding value box located to the right, enter the text false.  Now the metabox name and value should look like the following image.

Once you save your post/page this Custom Field value is now stored in the postmeta of this specific post ID… which means that in our code we can identify whether a certain post ID has a Custom Field that is declaring wpautop => false.  We do this “conditional check” in a small function that is placed in the functions.php file of your active WordPress theme folder.

function wpautop_filter_control( $content ){
    if ( get_post_meta( get_the_ID(), 'wpautop', true) == 'false' ){
        return $content;
    } else {
        return wpautop($content);
    }
}
remove_filter( 'the_content', 'wpautop' );
add_filter( 'the_content', 'wpautop_filter_control' );

The above code snippet will now check to see whether the active post ID has the wpautop custom field value set to false.  If it finds that particular custom field setting exists, it will return the_content without the wpautop() function running on the content.  If that exact custom field setting is not found, then the_content is returned after running wpautop on the content.

Now you have complete control over disabling wpautop() function on a per-post basis.