The jQuery Cycle Plugin offers an amazing number of transitions for your next slideshow. If any of the two dozen transitions don’t give the effect you’re looking for, the plugin can always be modified to suit. If you’re looking to make some unique transitions, check out the advanced demos on the plugin site.

Over 50 options can be implemented to show your slides in the best light. Options are available for controlling the speed of the transitions, the length of time between slides, as well as running the slideshow backwards or stopping after a certain number of slides have been shown.

Slides can be forced to fit a container and made to be manually paused and resumed. Easing transitions can be specified as can random showing of slides. Options in Cycle are plentiful and definitely worth investigating.

Command strings can be used to pause or resume the slideshow or advance to the next or previous slides. Tie these commands to a click event to let your visitors see the show as they wish.

The Cycle plugin works with two assumptions in creating slideshows. First, it assumes that a container object has been identified, usually via a class or id identifier, that will contain the slides for the slideshow. All children of the containing parent will become a slide.

Second, the slides must all be children of the container. Any object can be a child here, so textual content, images, anchors and divs can all be manipulated and viewed as slides in your slideshow. Don’t put anything else in the slideshow container unless you want it to become part of the slideshow.

Here’s the HTML markup that could be used for a simple slideshow of images:

<div id="show">
<img src="../images/pic1.jpg" alt="one" />
<img src="../images/pic2.jpg" alt="two" />
<img src="../images/pic3.jpg" alt="three" />
<img src="../images/pic4.jpg" alt="four" />
<img src="../images/pic5.jpg" alt="five" />
</div>

The images are contained in a specific container, div#show, which can be styled with CSS. Giving the container and the slides fixed dimensions works best, so make sure to specify the widths and heights.

The default behavior is to fade slides in and out of the container in a continuous and sequential manner, in a cyclical way. So, we’re going to ‘cycle’ through the slides in this slideshow. The javascript for a slideshow using default behavior is simple:

$('#show').cycle();

With Cycle plugin default settings the slideshow starts with the first image or slide and each slide takes one second, or 1000 milliseconds, to be faded in. Each slide is then paused for 4 seconds and then faded out in one second. The slideshow wraps around so that the first slide will be shown after the last one. The fading in and out action occurs continuously and indefinitely with the default settings, as below:

To alter the slideshow behavior pass an effect, other than fade, as a string to the cycle method, like so:

$('#show2').cycle('shuffle');

Check out all the effects that can be used to transition slides: blindX, blindY, blindZ, cover, curtainX, curtainY, fade, fadeZoom, growX, growY, scrollUp, scrollDown, scrollLeft, scrollRight, scrollHorz, scrollVert, shuffle, slideX, slideY, toss, turnUp, turnDown, turnLeft, turnRight, uncover, wipe, and zoom.

Several transitions can be combined in a comma-separated list if you can’t choose just one. Or, use the string ‘all’ to see all the slide transition effects in a random manner.

Alternatively, you can use an options object to set the fx option among others. The code below specifies fade, zoom and curtainY effects to bring the slides in and out of the container. Each slide will be brought in slowly (800 ms) and taken out quickly (400 ms) taking a total of 3 seconds for each complete transition. This is the code for the slideshow (#show3) at the top of this post.

$('#show3').cycle({
  fx: 'fade,zoom,curtainY',
    speedIn: 800,
    speedOut: 400,
    slideExpr: 'img'
    timeout: 3000,
    nowrap: true
});

The parameter slideExpr is given a string value of ‘img’ in order to produce a slideshow without long blank pauses in between slides when using WordPress. WordPress and other content management systems may introduce extraneous markup when preparing webpages. The markup may be incorrectly interpreted by different browsers used to view slideshows created with Cycle, so it’s become important to specify the elements that are supposed to be cycled in the slideshow. Thus, the addition of slideExpr: ‘img’ as an optional parameter is necessary for image slideshows in WordPress.

The slideshow just above will be shown only one time and end with the last slide because the nowrap option is set to true. This might be a good thing to remember for leaving a textual message on the screen with your last slide instead of having the slideshow run indefinitely.

If you get stuck or need a little help with figuring out how to work the Cycle plugin, visit the jQuery Forum.

Some animations run continuously and others may be controlled by setting timers or stopping the animations at predetermined times. Other animations happen after some event has occurred, like when a user mouses over an element on the page or clicks a button.

Animations created with the jQuery InnerFade plugin run continuously, which may create a problem if the users’ computer resources aren’t up to the job.

It was noted that an InnerFade news ticker animation of links worked fine and as expected when the browser tab was left open and running. Working with another tab open and going back to the news ticker site, the news items got stacked onto one another so that the text was unreadable and the timing was double time.

Reloading the page or waiting for a couple of seconds to pass brought the expected behavior back. The animations caught up to where they should have been and the behavior continued as expected.

I’m not exactly sure why the animations stacked up in my page and not in the demo page by the plugin author, but I found a solution to this stacking problem.

jQuery lets us use a stop() action to clear the previously requested animations that haven’t finished yet. Optional parameters for the stop() action are clearQueue and gotoEnd, which are false by default.

To use the stop() action in this case, set both parameters to true. This will clear all animations in the queue and jump to the place where the action should be at now.

If it were important to catch up to the latest animation, use true for the optional gotoEnd parameter. When set to true, the gotoEnd parameter figures out what the screen should look like at the end of the present set of animations in the queue and goes there.

In the section of the code that responds to the slide or fade settings, I used the stop() action to clear the queue and catch up. The InnerFade plugin was altered on lines 93 and 96 (of the original script) by inserting .stop(true,true) just before the fadeOut() or slideUp() methods.

line 93...$(elements[last]).stop(true,true).slideUp(settings.speed);
line 96...$(elements[last]).stop(true,true).fadeOut(settings.speed);

Below is the portion of the original script that has been modified (on lines 3 and 6 here):

$.innerfade.next = function(elements, settings, current, last) {
        if (settings.animationtype == 'slide') {
            $(elements[last]).stop(true,true).slideUp(settings.speed);
            $(elements[current]).slideDown(settings.speed);
        } else if (settings.animationtype == 'fade') {
            $(elements[last]).stop(true,true).fadeOut(settings.speed);
            $(elements[current]).fadeIn(settings.speed, function() {
							removeFilter($(this)[0]);
						});

The script now works even better!

When two separate link lists were animated with the InnerFade plugin on the same page, the first one stacked up and the second list went blank when the stop() action was used with only the first parameter set to true, so it was important to set both the clearQueue and gotoEnd parameters to true.

The stop() action also comes in handy to clear the queue when event-driven animations get backed up from too much user input, like mousing over and out too fast.

An oddity in all this is that I couldn’t replicate the bad behavior (of the original plugin) inside of WordPress. The stacking up of animations was noticed in a static page outside of WordPress. To see the original and improved InnerFade plugins in action, go to the Good Ideas static page.

Is there some way that WordPress manages the scripts differently? I dunno, but the take away message here is to make sure and test your scripts to see how they act in various circumstances.

According to the Codex -

In Version 2.6, users were given the ability to move their /wp-content/ directory to anywhere they want, and many users already keep all WordPress files (like /wp-admin/ and /wp-includes/) in an unusual place.

In case you’ve moved the files for your WP installation, you probably have a good handle on paths and how to traverse them. For those who don’t, it can be a hair-pulling experience to find the right path. Once the right path is found, work can continue.

WordPress Paths

To help avoid those DUH! moments, here are some functions and constants that WordPress has defined regarding paths. Once you’re familiar with these functions, writing useful and working code should become easier. Optional parameters may be of use in modifying the output for several of the following templates, including $path, $file or $scheme.

plugin_basename()

Usage: plugin_basename(__FILE__); Returns: the name of the plugin and file, such as “myPlugin/myPlugin.php”

get_theme_root()

Usage: get_theme_root(); Returns: path to themes directory. No trailing slash.

get_theme_root_uri()

Usage: get_theme_root_uri(); Returns: URI for themes directory. No trailing slash.

get_theme_roots()

Usage: get_theme_roots(); Returns: Themes directory with a leading slash, like “/themes”.

site_url()

Usage: site_url(); Returns: Site directory with no trailing slash.
http://www.site.com OR http://www.site.com/wordpress

admin_url()

Usage: admin_url(); Returns: Admin directory with trailing slash.
http://www.site.com/wp-admin/

content_url()

Usage: content_url(); Returns: Content directory with trailing slash.
http://www.site.com/wp-content/

plugins_url()

Usage: plugins_url(); Returns: Plugins directory with trailing slash.
http://www.site.com/wp-content/plugins/

includes_url()

Usage: includes_url(); Returns: Includes directory with trailing slash.
http://www.site.com/wp-includes/

home_url()

Usage: home_url(); Returns: Home directory with no trailing slash.
http://www.site.com

ABSPATH (constant)

Usage: ABSPATH. Returns: Home directory with no trailing slash.

TEMPLATEPATH (constant)

Usage: TEMPLATEPATH. Returns: Path to current theme with no trailing slash.

There are a few more functions for multisite installations and backwards capability specified in the Codex.

PHP Paths

Some PHP functions worth noting -

• __FILE__ returns the filename of the script that is currently being run
• dirname() returns parent directory’s path for a given filename with no trailing slash
• basename() returns the filename component of path without any parent directories
• getcwd() returns current working directory

Use the functions or constants indicated to build your paths instead of hard-coding them. You’ll save yourself a LOT of trouble when it comes time to move your WordPress installation to a new server or directory.

WordPress takes your blog content and runs it through some backend shenanigans to create the output that you see on the screen. WP expects to find other content in posts, like text and images, not code.

To run PHP code inside a blog post or Page, you’ll have to work a little differently than simply filling up the space in the text editor.

There are two ways (at least) of using PHP inside WP blogs to produce the desired output. The first way is to set up a WP template page that points to a pre-written PHP page that is identified in a Page. The second way is to use a plugin that facilitates PHP code execution inside content areas in WordPress. Both ways have their advantages and disadvantages.

Using WP Template Pages to Execute PHP Code

A template page is used to identify a pre-written PHP page. By saying “a pre-written PHP page” I mean a .php file that you’ve already written and which has been executed successfully by a server. A template file has at the top of it a PHP comment which identifies the template name followed by an include statement that identifies the .php file. WP template files must follow this format to be properly identified by the WordPress engine as a template file.

<?php
/*
Template Name: soccer-roster
*/
include (TEMPLATEPATH . ‘/soccer-roster.php’);
?>

The above snippet  is a complete template file which indicates the name of the template as “soccer-roster” and the path to the associated PHP file, soccer-roster.php. The template file is best saved with “template” in the file name. It must be located in the site’s theme folder.

After creating the template file and .php file, upload both to the theme folder. Create a blank Page. Do not put anything where you would normally write the content, but go ahead and give it a meaningful title. On the Add New Page page, look for the “Page Attributes” widget. Click the down-arrow to expand the list of templates and select your template. Using the example above, you would select the “soccer-roster” template. If the template is not stored in the theme folder, it will not appear in this drop-down list. Save the page and preview it. The PHP code, from soccer-roster.php, should be executed just as you would expect.

PROs

• No interference from WP, code interpreted as stand-alone PHP.
• Page renders as expected.

CONs

• Can only be used with Pages, not posts or text widgets.
• May have to wrestle with adapting PHP output into style of site.
• CAUTION: Use a child-theme to safely save site-specific template files.

If your site relies heavily on plugins, using template pages may be the best method, see below. If it’s not a big deal to style the PHP output pages like the rest of your site, creating WP Pages that use templates is a breeze. If you need to put code in a post or text widget, keep reading.

Using WP Plugins to Execute PHP Code

Modifying WordPress themes is not for everyone, so using a plugin to execute PHP code may be the easier option. There are more than a handful of plugins available for the task. I chose to use Exec-PHP plugin for WordPress. It is a very well documented plugin. Thank you, Sören.

Download, unpack, upload and activate the plugin in the usual fashion. Verify these settings to make the plugin do its magic:

• Disable tag balancing by unchecking ‘WordPress should correct invalidly nested XHTML automatically’ in the Settings/Write menu.
• Disable the WYSIWYG editor (visual editor) in the user’s settings through the Users/Your Profile menu.
• Assign the ‘unfiltered_html’ capability to the user, if user is not the administrator. Can use role manager plugin to assign this capability to other users.
• Assign the ‘exec_php’ capability to the user, if user is not the administrator. Can use role manager plugin to assign this capability to other users.

Once I disabled the visual editor, my site was ready to go.

PROs

• Easy, just change a couple of settings in blog admin. Plugin gives highly visible warning on Add New Post or Add New Page pages if the settings are not correct.
• PHP code can be written in the normal fashion using the <?php ?> tags. It does not need to be marked up in any special way as it might with other plugins.
• PHP can be used in text widgets and posts, as well as Pages.

CONs

• Can’t use plugins that embellish or rely on the WYSIWYG editor.

Didn’t try any other PHP-execution plugins because Exec-PHP worked as soon as the visual editor was disabled.

As mentioned either method will get you there, it’s just a matter of style. If you need the visual editor to create your posts, use the template method. If you want to put PHP code in posts and text widgets, use the plugin method. Good luck!

The improvements in WordPress continue. Check the state of your blog’s health by running the new Health Check plugin. Currently, it will check for the versions of PHP and MySQL that are running your blog. In order to work with WP 3.2, your server will need to be up-to-date and running —

• PHP version 5.2 or greater
• MySQL version 5.0.15 or greater

In an attempt to help others into the 21st century, WordPress will no longer work using PHP 4 or MySQL 4.

WordPress will also drop support for Internet Explorer 6. Yay! There are other improvements coming, so stay tuned!

First, use the Dashboard Widget Scheduled Posts plugin. This plugin creates a widget for your WP Dashboard that lists the upcoming posts that are scheduled, but not yet published.

Second, use the Future Posts Calendar plugin. This plugin creates two sets of calendars based on your scheduled posts. One calendar resides in the right column of the New Post page that you’ll see when you’re writing a new post or editing a previous one. The second calendar will be seen by site visitors as it resides in a widget that you can choose to add to a sidebar of your blog.

When there are no scheduled posts, the future calendar on the New Post page will have the current date in bold.

No future posts scheduled at this time.

When at least one post is scheduled for future publication, the future calendar – either on the New Post page or in the blog sidebar – will have differently colored backgrounds depending on the number of posts scheduled for that day.

Posts scheduled to appear on the 20th and 21st on the month.

A green background indicates one post, light blue means two posts and blue means three posts scheduled for that day.

Clicking a date in the calendar will change the scheduled posting date. Nice feature!

If you’re not bothered by editing code, you can alter the PHP file to make a dashboard widget, too.

If you want to ad a widget to your dashboard, uncomment the line add_action('wp_dashboard_setup', 'fpc_setup_dashboard_widget'); in the future_calendar.php file.

The dashboard widget only shows the date of future posts in the calendar format, so I prefer the Dashboard Widget plugin as it includes post titles.

I reviewed two plugins that were developed to display the scheduled posts as a Dashboard Widget.

Future Dashboard Widget creates a widget for the dashboard that lists the Scheduled Posts by date, including the post titles and first line of content. The entries are listed in reverse time order so the next post to be posted will be at the bottom of the list. A link is provided to see “All Scheduled Posts”.

Dashboard widget of scheduled posts from Future Dashboard Widget plugin.

Note the day, date, time, title and text format with last posting listed first.

Dashboard: Scheduled Posts creates a Scheduled Post widget for the dashboard, but lists the entries in order so that the next post to be published will be listed at the top of the list. A link is provided to see “View All” scheduled posts.

Dashboard widget of scheduled posts from Dashboard: Scheduled Posts plugin.

Note the title, date and text format with first posting listed first.

I’m going to go with the Dashboard: Scheduled Posts plugin. I like the widget format better than that of the Future Dashboard Widget plugin and the order that the posts are listed seems more intuitive. Thanks Viper007!

• modify the child-stylesheet to make things look how you want
• create child-directory for new child theme
• add template files to child-directory, if you wish
• upload child-directory to /wp-content/themes/
• activate new child theme

The child-stylesheet must be saved with the name “style.css” in the child-directory. The child-stylesheet header (which has to be at the top of the sheet) must contain a few lines that identify its parent theme, like so:

/*
Theme Name:     Twenty Ten Child
Description:    Child theme for the Twenty Ten theme
Author:         Your name here
Template:       twentyten
Version:        0.1.0
*/

@import url("../twentyten/style.css");

{put new style rules here}

You can add a line for the Theme URI: and Author URI:, if you like. Only the Theme Name: and Template: lines are required, the others are optional.

The @import rule indicates the directory of the parent theme and the location of the stylesheet. All you have to do is put in the new css rules below the import line.

That’s it!

If modifying the stylesheet doesn’t quite get all the changes you want, realize that you can add any template file to the child-directory and that will over-ride the parent file with the same name. For example, say you want to stick in a block for an advertisement right under the header image. Copy header.php and add a new <div> at the bottom of the page just below <div id=”main”> and stick the ad code in this division. Upload this new header.php into the child-directory and it will replace the one from the parent template.

Activate your new child theme and see how it looks!

WordPress theme developers have a lot more help in 2011 compared to just a few years ago. With the publishing of the new standard themes and lots more interest in WordPress in general, there is a ton of info for you to soak up. Seek and ye shall find!

If you’re just starting to develop your own themes, get a good understanding of the Twenty Ten theme created by the WordPress team. You’ll learn a lot about how to put together your own theme by studying this standard theme that’s included when you download WordPress.

One of the advancements in WordPress 3.0 was the introduction of menus. To learn a bit about using the menus in your own theme, get a handle on how they’re used in the Twenty Ten theme. A great menu intro by Justin will start you on your way to understanding menus.

If you’re lost and don’t know where to start, look to the WordPress codex for help in getting started in developing themes for WordPress.

If you get lots of comment spam and DO have the Akismet plugin installed and updated in your WordPress, check the dates of the posts that the spam-comments are being left on. Chances are high that much of the spam is left on older posts. I guess the spammers figured we wouldn’t notice?

Take a look at the Discussion settings from the WP main menu. Note under Other comment settings the third line down where you can fill in the number of days after which an article can’t be commented on.

Discussion Settings in WordPress

Fill in some value less than 30 days and that will knock down the number of spam comments left on your blog. Don’t forget to scroll down the discussion settings page and hit the Save Changes button.

There is at least one alternative WordPress plugin (and there’s probably many more, but I haven’t needed to check for any) that was commented on in a positive way, called WP-Spam Free. Might be worth checking out.

Keep bloggin!