Monthly Archives: November 2014

Including CSS on a Particular WordPress Page or Post

I deployed a site recently that made use of the Testimonials WordPress plugin. This plugin adds a CRUD interface to the WP dashboard where you can add/edit/delete customer testimonials. They can then be displayed in posts or pages using shortcodes. There’s a lot of parameters for the shortcodes but (somewhat strangely) there’s no apparent way of giving a particular instance of a testimonial a CSS class or ID. So there’s no easy way to style a testimonial on a given page of the site. This is particularly annoying if you want the testimonial bigger on a particular page for marketing reasons.

Now, a little aside here, I did PAY for the commercial version of the plugin. I shot off a couple of support emails to the author in the first couple of days of use and he completely didn’t answer one of them (he linked me to a FAQ page that didn’t answer my question), but he did answer a second question. However, when I asked him about the custom CSS class or ID for a testimonial he initially didn’t understand the question (which could have been entirely my fault) and then suggested I PAY for more support if I wanted his help. Now given that I had only just paid for the plugin a week or two before hand I thought that was a little rich. So, needless to say that’s the last email he’ll ever get from me, time to work this out myself.

I picked apart the HTML generated by the testimonial shortcodes. Each one is contained in a DIV with the CSS ID like .post-6666 where 6666 is the ID of the testimonial. The actual body text of the testimonial is contained in a <p> in the parent DIV.  All I needed to do was inject some CSS into the particular page where I needed a different style for the testimonial.  Turns out it’s not too hard.  Just add the following to your child theme functions.php file.

add_action( 'wp_head', 'custom_include_script' );

function custom_include_script()
{
   if(is_page( 'some-page-name' ))
   {    
    ?>
	<style type="text/css">.post-6666 p {font-size: 18px;font-weight: 500;font-style: italic;}</style>
    <?php  
   }		
}

The PHP Is pretty simple to understand. We’ve added an action to the wp_head call. The action checks if the page is the page we are interested in, if it is then it echoes out the CSS for the particular testimonial DIV. Hey presto different text size for the testimonial on a particular page.

Including a Javascript File in a Specific WordPress Page

Including a particular Javascript file for a specific page or post in WordPress is something that can be useful so that you do not needlessly load the file for every page of the site. Let’s take the example where we want to include the file “page-specific.js” file in the WordPress page “A Specific Page”. In this case I’m assuming the path to your page-specific.js file is:

/wp-content/themes/your-child-theme/js/page-specific.js

In the functions.php file of the child theme enter this code:

add_action( 'wp_head', 'custom_include_script' );

function custom_include_script()
{
    if(is_page( 'a-specific-page' ))
    {    
    ?>
	<script src="<?php echo esc_url( get_stylesheet_directory_uri() . '/js/page-specific.js"' ); ?>" type="text/javascript"></script>
    <?php  
    }
}

The PHP Is pretty simple to understand. We’ve added an action to the wp_head call. The action checks if the page is the page we are interested in, and if it is, it echoes out the HTML required to include the JS file. The get_stylesheet_directory_uri() call gets the directory of the child theme we’re using.

PHP in WordPress

I’ve been using PHP in a lot of WordPress posts and pages recently. Usually I just make use of the Exec-PHP plugin. This allows you to put PHP in any page or post using the usual <?php opening and ?> closing tags.  It’s a little clunky for a few reasons, firstly if you edit the page or post in the WordPress Visual editor it messes up the code. You work-around that using the Disable Visual Editor WYSIWYG plugin. A second reason not to do it this way is that editing PHP in the WordPress is horrid. I’d much prefer editing in my IDE of choice where I get nice syntax highlighting and can format the code nicely.

However, there’s a big reason not to include complex PHP directly in your pages or posts. That’s because the PHP is included in the database record for the page or post. Never a great idea from a security point of view. It turns out if you have a need for a complex PHP driven page there’s an easier way. Take the case where we want to create a PHP driven page called “My PHP Page”.

  • In your child theme folder (you are using a child theme I hope) create a copy of your page.php file and call it page-my-php-page.php.
  • Create a new page in WordPress and call it “My PHP Page”.

Now when WordPress renders the new page called “My PHP Page” and it finds the page-my-php-page.php file in the theme directory it will use that file to generate the page content.

I have found this approach particularly useful if you are building a simple CRUD system in WordPress. I’ve created a series of files called (for example) page-add-record.php, page-delete-record.php, page-edit-record.php, page-view-records.php. Each file contains the code required to add/edit/delete/display the database records I am interested in. Then I just need to create corresponding pages in WordPress with the names “Add Record”, “Edit Record”, “Delete Record”, and “Display Records”.

ob_gzhandler and Divi WordPress Theme are not happy bed-fellows

I’ve just finished rolling out a new WordPress site which uses the very nice Divi theme by Elegant Themes.  The site is hosted on Pair, and they do not have gzip compression enabled for Apache.  No problem I thought, someone must have solved that problem.  And sure enough Jon Henshaw had done exactly that.  There’s something not quite right with the way his blog is rendering (because it’s removed the underscores from the code) but basically all I had to do was put this at the top of my child theme header.php file:

ob_start("ob_gzhandler");

Once I’d done that I verified (using Google Chrome) that the download size of the each page on the site had decreased, and sure enough the 500K home page was now just a 100k download. Woot. Or so I thought.

Next morning I got up to a slew of emails asking me what happened to the site as all people could see was a blank page. I checked the site in Chrome, nope, it’s there. Checked it in Firefox, nope it’s there. Checked in IE10, nope there too. All there while I was logged into WordPress. With a growing sense of dread I logged out of WordPress in IE10, refreshed the home page of the site and….a blank page. Same for FireFox and for some reason, Chrome rendered the site just fine. I tracked the problem down to somewhere in the wp_head() call in the header.php file, but I really wasn’t interested in having the site down any longer so I removed the offending code above and the site started working correctly.

Today, with a bit of time on my hands I tested the same call in a couple of other themes (WP 2014 and on this blog) and it didn’t cause an issue. So, the only thing I can conclude at this stage is that ob_gzhandler and the Divi WordPress theme do not play well together.