jQuery Stop Action Improves InnerFade Plugin

When animations go wrong it’s usually in the timing. Perhaps the browser can’t keep up with all that it’s asked to do or the operating system is bogged down by other tasks. In any case the lack of enough working memory or CPU cycles will have animations stacking up until there are enough resources to do all those fancy moves.

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):

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.

Using PHP Inside Content of WordPress Blogs

Using PHP inside of content on WordPress sites may not produce the expected results. As WordPress is built in PHP, you might think you could just start typing PHP code inside a post to pull some information from a database. Sorry to say, but it doesn’t work that way.

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.

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.


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


  • 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.


  • 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.


  • 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!