Pause and Play Buttons for jQuery Slideshow

Continuing our slideshow journey with jQuery Cycle plugin, we’d like to improve our slider by adding two more buttons. Last time we looked at creating a slideshow with previous and next buttons, but now we’d like to add buttons for pause and resume. It would be nice to allow site visitors to stop a slideshow with a pause button and resume the slideshow with a play button whenever they’re ready to continue.

If we keep the overall design the same, we just need to do two things to modify the slider. First, we need to upload the images for the pause and resume buttons and add a couple of lines to the HTML markup for positioning the buttons. We’ll fit the pause and play buttons in between the previous and next buttons. Each button will use an anchor tag, an id for CSS and script targeting, and a title for a user-friendly tooltip.

HTML Markup for Slideshow Controls:

Second, we need to add a couple of lines to the script to manage the action when someone clicks either button. Here, we’re assigning Cycle’s pause or resume option to the click function of the selected id, in this case #slide_aft. Adding a ‘return false’ line assures that the site visitor won’t be taken to another page when the buttons are clicked.

jQuery script portion for pause and resume buttons:

The above script portion was placed in the document.ready function($) so that the buttons are able to be used as soon as practical.

Here’s the full slideshow example with button controls for pause, resume or play, previous slide, and next slide.

one
two
three
four

Now, that looks a little better. This slideshow looks more complete having the pause and play or resume buttons, as well as the prev and next buttons.

Previous and Next Buttons in a jQuery Cycle Slideshow

A site visitor to computeraxe wanted to know how to incorporate previous and next buttons in their slideshow using jQuery Cycle plugin. It’s easy! Let’s see an example, ok?

If you haven’t checked out the simplicity of the jQuery Cycle plugin, you should because there’s a whole lot you can do with it. It’s a very versatile plugin and quite popular, which speaks to its usefulness — and cool factor, too. Previous posts here covered the basics about the Cycle Plugin, how to make slides look like Polaroids, using image captions with Cycle, and discussions about a transition effects problem with certain fx.

Let’s get into the example for making previous and next buttons for a slider in jQuery using the Cycle plugin.

Before writing any code it would be a good idea to sketch out the design for the slideshow. The photos or slides will be held in a container div that can be targeted for CSS styling and javascript. Captions and their container paragraph would also be placed inside the container div. In this example we’ll do away with the captions for simplicity and place the previous and next buttons inside the container div.

It turns out that Cycle has two options for creating the functionality for going to the next photo or the previous slide in a sequence. These options are appropriately named ‘next’ and ‘prev’. The values to give for each are the locations of the next and previous buttons. To specify each location, create an id.

Here, we’re using #next2 for the next button and #prev2 for the previous button. Since we’re having only one next/previous button set for this slideshow, an id for each makes sense. If you have more than one slider on a page, a class would be more appropriate. When somebody wants to see the previous slide they’ll click on the ‘previous button’, so the best HTML tag for the slideshow controls is an anchor with a href of ‘#’. We don’t want to leave the page when clicking the previous button, we just want to see the previous slide in the show.

HTML Markup:

Slideshow example using jQuery Cycle plugin with previous and next buttons.

one two three four

We’ll use a couple of small images to accommodate the previous and next slide functionality. One could use the words ‘prev’ and ‘next’ instead of images, if desired. In case a site visitor needs help, we’ve included a tooltip for each button by the way of a title for each anchor.

We want to hide all the images except the first image whenever the document is ready. Else, we’ll use the window load function for the slider action.

jQuery:

Of course, there are many different ways to style your slideshow. Here’s our example Cycle slider with next and previous buttons.

Slideshow example using jQuery Cycle plugin with previous and next buttons.

one
two
three
four

What if you want two sliders on the same page?

The first thing to recognize is that more than one id with the same name won’t work on the same page, so parts of the document for the second slider with an id will have to be changed over to a class or a different id name. CSS will have to be updated to reflect the changes, as will the javascript.

However, using the same class names for the next and previous controls for two sliders on the same page will result in both sliders being controlled by the same set of control buttons. That’s probably not what you’d want, nor what your site visitors would expect. Rename the action buttons (prev, next) and the container for the slides to different class names in order to be able to control the second slideshow. Of course, a second Cycle script would be needed to target the new container for the second slideshow.

Putting Readable Code in a WordPress Post

Writing about PHP or HTML code in WordPress posts or pages often requires that some actual code is shown on the screen for explanation. If special steps aren’t taken to illustrate the code as text, the result is often not what was intended to be seen because the WordPress engine will interpret the code as actual code, not text about code.

If all you want to do is highlight some text that includes code-related words like filenames, function names or plugin names, use <code></code> around those phrases in your text. Using <code></code> turns text into a monospaced font so that it appears differently in your posts than “normal” text. However, using <code></code> around an HTML tag doesn’t do anything except change the presentation of the tag, so the opening and closing angle brackets are interpreted to enclose an actual HTML tag. The result will be a mess and definitely not what you were hoping to see.

To make WordPress show code in a post without interpreting it, you have to do ONE of three things:

  1. Use special character codes to replace angle brackets of tags.
  2. Use the HTML tag <pre></pre> around the code.
  3. Use a plugin to highlight the code syntax.

1. Special Character Codes

Angle brackets, < or >, are what WordPress uses to identify code, whether it’s HTML, inline styles of CSS, or PHP. Content inside angle brackets is interpreted as code by virtue of placement inside the brackets. Instead of interpreting this code we want WordPress to show the code to the site visitors and we can use special character codes to do that.

Character codes are special sequences of letters or digits that are used to represent textual characters. Every character that we see on the screen, including uppercase letters, lowercase letters, numbers, and symbols like <, >, #, $, %, ^, & or *, can be represented by character codes, sometimes called character entities.

Using character codes in posts looks a little strange in the editing panel, but when a browser comes across these codes they are interpreted and their textual equivalent is shown on the screen.

ASCII (American Standard Code for Information Interchange) character codes were developed to represent text in electronic devices and they follow a specific format. The format is that each character entity starts with an ampersand and ends with a semi-colon. The codes are a couple to a few letters or numbers. Numbered character codes always have a hash symbol right after the opening ampersand. Some entities can be represented by either numbered or named codes.

Examples of special character codes:

Character name Character symbol Character ASCII Code
left angle bracket < &lt;
right angle bracket > &gt;
ampersand & &amp;
dollar sign $ &#36;
long dash &mdash;
short dash &ndash;
double quotes " &quot;
at sign @ &#64;

If you need to find a code for language sets other than English, try the unicode site for all the code charts you’ll ever need. There, you can find numeric codes for fun game pieces, like chess, mahjong or checkers, horoscope symbols, smiley faces, weather symbols, music notes, and much more.

Take caution: Just because you can enter a special code to represent a symbol, that doesn’t mean your computer will let you see it. Many operating systems will not have the proper fonts installed to make use of all of these codes, especially if they represent symbols that aren’t on your keyboard. Stick to the ASCII codes as many of the unicodes won’t be seen by your site visitors.

2. HTML tag: <pre>

Perhaps you’d like to show a block of HTML code on your post and have it shown as text. To make sure that your block of code is not interpreted as actual code, wrap it with <pre></pre> tags. The <pre> tag will change the appearance of the code into a monospace font, just like <code> does, but the difference is that <pre> also illustrates the code exactly as it was typed. All text, characters, spaces and line feeds will be reproduced exactly how they were entered. No code will be run when it’s protected inside the opening <pre> and closing </pre> tags.

3. Syntax Highlighter Plugins

A final way to illustrate code in a WordPress post or page is to use a plugin to highlight the code. Several plugins are available for syntax highlighting purposes.

One that I have been using lately is called Crayon Syntax Highlighter. It’s a great plugin that will colorize or highlight code that you wrap with shortcodes. There are lots of options if you want fine control over the color scheme. Themes come with the plugin so you have several choices for making your code look good.

There are two modes where you can highlight code differently using shortcodes, [crayon][/crayon] and [plain][/plain]. Use [plain] shortcodes when the colorized crayon is overkill or when you just want to show a small section of code. Crayon Syntax Highlighter supports a wide range of languages, including HTML, CSS, PHP and JavaScript, for starters.

The colorful [crayon] shortcode is controlled by options where you can pick the colors that you want for representing different sections or purposes in your code. Inline crayons are supported so you could put a line of code within a line of text and the code would be colorized.

Some other popular code-highlighting plugins include SyntaxHighlighter Evolved, WP-Syntax, and CodeColorer. I don’t have any personal experience with these plugins, but they are listed high in popularity at the WordPress Plugin Directory.

Need to Execute Code in a Post?

If what you’re really after is to put executable code in a post or WordPress Page, check out this post on executing PHP in WordPress blogs.

Include jQuery or JavaScripts in WordPress

Plugin and theme authors use jQuery for their special effects, but there seems to be some confusion about the proper way to include JavaScript files in WordPress. If you’d like to use jQuery effects on your pages or in your theme, or if you want to include any javascript plugin or personal script, read on to see how to do it properly with WordPress sites.

Queue Up Your Scripts with Actions

Since jQuery itself is already included in the core of WordPress, how should we include a javascript file that we’ve created or even one of the popular jQuery plugins that rely on jQuery? WordPress helps us in this endeavor with a function called ‘wp_enqueue_script()‘ and two actions that are used to call this special function.

The actions are used for either the user side or the admin side, depending on the purpose of your javascript. Use the ‘wp_enqueue_scripts‘ action to call wp_enqueue_script() for use in your themes. If the script functionality is needed on the admin side, use ‘admin_enqueue_scripts‘ action instead.

The format of the wp_enqueue_script() function call is as follows:

wp_enqueue_script('$handle', '$src', '$deps', '$ver', '$in_footer');

where $handle is the name of the script as a lowercase string, $src is the URL to the script, $deps is an array of scripts that the script you’re calling depends on or the scripts that must be loaded first for your script to work, $ver is the script’s version number in string format, and $in_footer is a boolean value to indicate whether the script should be loaded in the <head> or at the end of the <body> in the footer.

The $handle string is the only required parameter, so the other four parameters are optional. The $src, $ver, and $in_footer parameters default values are ‘false’, and $deps defaults to an empty array.

It seems that $src would need to be a required option, but WordPress already knows about several scripts and where to find them. Consult the list of default scripts included with WordPress to pick up their handles.

For example, to queue the jQuery Color plugin, we’d simply use this:

wp_enqueue_script('jquery-color');

To include a script and specify the source, try this for including the jQuery Cycle plugin in the <head>:

wp_enqueue_script('jquery-cycle', 'URL', array('jquery'), '1.3.2');

The URL should not be a hard-coded value for local scripts. Refer to the Function Reference pages in the codex for proper URL formats for plugins and themes.

Register Your Scripts First

Make sure that your scripts are registered first before calling them. Registering a script basically tells WordPress where to find the code for your script. Use the function wp_register_script() to specify the location and handle of your script. The format is similar to the wp_enqueue_script() function:

wp_register_script('$handle', '$src', '$deps', '$ver', '$in_footer');

The parameters have the same meanings and default values as used with wp_enqueue_script(). When in doubt, see what the WordPress Codex has to say about wp_enqueue_script() and wp_register_script().

Create a Function for the Header

Put it all together using wp_register_script(), wp_enqueue_script(), and the appropriate action to call the functions. Create a simple function, like id_scripts() below, and use the add_action() hook to queue up the scripts.

As a side note jQuery itself doesn’t have to be queued via a statement like wp_enqueue_script('jquery');, because it is listed as a dependency of ‘script-alpha‘ in this case.

When enqueuing a custom script that depends on a jQuery plugin, specify jQuery and its plugin in the $deps parameter of the wp_register_script() action for the custom script. For example, if your custom script depends on the jQuery Cycle plugin, which itself depends on jQuery, use array('jquery', 'jquery-cycle') for the $deps parameter. This specifies that both jQuery and its plugin Cycle should be loaded (in that order) before the custom script.

Place this code in the header.php of your theme. Remember, first register the javascript file, then enqueue it and make sure this is done before the wp_head(); statement. Your custom script can then be placed in header.php after the wp_head() call.

Use Theme functions.php to Safely Reference Your Script

When using a child theme take note that the header.php in a child theme will override the default header.php in the parent theme. Instead of placing the script-queuing code in the header, one could more safely put this code in functions.php. The advantage to that way is that the functions.php of a child theme is processed before the functions.php of the parent theme. Both the parent and child theme functions.php are processed, unlike header.php files.

If you’re the least bit unsure about messing with header.php, then just use functions.php to queue up your javascript files. Don’t forget the opening and closing PHP tags in functions.php, else it won’t work. Put the javascript that would come after the wp_head() call in a separate .js file in the child theme and you’re good to go.

Verify that everything is working correctly by viewing the source of the HTML document for a WordPress post that should have the script included. The <script> tags should be visible in the header or in the footer depending on how the scripts were called.