Posted on

Adding gotoIf and other Flow Control to Selenium IDE

selenium ide

Some of my Selenium IDE test scripts make use of the gotoIf command.   Flow control logic like the gotoIf and label statements are not part of the standard Selenium IDE core library.   Like most apps these days, Selenium IDE has a method for extending the base functionality with plugins and core extensions.   The “sideflow” core extension from darenderidder is an extension that provides the oft-referenced goto controls for Selenium IDE.

Adding sideflow Flow Control To Selenium

I like to keep current with any repository updates, so I use git to clone the repository into my documents folder on my Vagrant WP Dev Kit CentOS box.    Using SmartGit I clone via the github URL:

Open Selnium IDE, go to the Options menu and select options.  Under the Selenum Core extensions browse to the sideflow.js file that was cloned via git.

Installing Selenium IDE SideFlow Extension
Installing Selenium IDE SideFlow Extension

The other option is to just download the sideflow.js file here.   No promises or guarantees this is current or will work on every system.  You should really grab the code from the source.

Example Selenium IDE Script

Here is an example script that uses flow control to ensure only ONE Store Locator Plus locations page is added. If the page already exists it skips the page setup process on my test site.

<tr><td rowspan="1" colspan="3">SLP - Add Page, SLPLUS</td></tr>
<!--Open WP Pages Interface-->
	<td>xpath=//table[@class='wp-list-table widefat fixed pages']//td[@class='post-title page-title column-title']//a[contains(text(),'Locations')]</td>
Posted on

WordPress Dev Kit : Legacy Publisher

WordPress Plugin Directory Banner

This article is about my legacy publishing process for development WordPress plugins and themes.   It is my workflow and it is far from perfect.  It will evolve over time and I am in the midst of making several big changes using new tools to assist in the process.   To get some background on the process you may want to follow along with the WordPress Workflow and WordPress Development Kit threads on my blog.

My Setup

My WordPress development is fully contained in a VirtualBox running CentOS 6.5 with a full GUI interface.   I am working on building an distributing some Vagrant boxes that will help others replicate the process.  My base CentOS 6.5 GUI box is online but is not a full setup… yet.   You can read about Vagrant in the WordPress Workflow thread.

My plugin development environment consists of a standard WordPress production build (3.8.1 today) with the typical wp-content/plugins subdirectory.  On my development system I work directly inside of these directories.  It provides instant access to the modified code without running a repetitive series of push/pull commands to move stuff into a “ready to review” state.    I find this configuration to be far more efficient and rely on semi-intelligent scripts to help me “weed out” the development environment when building the production-ready kits.    As a last step before production I have a test box on a remote server where I install the production releases as a clean last-minute sanity check.  This will migrate to a Vagrant-based “clean production simulator” to provide more robust testing.

How does my “inline production” setup look?

The Build Scripts

The top-level build scripts go in my ./wp-content/plugins directory.   That is not exactly accurate.   I should say that symbolically linked file pointers (symlinks for Linux geeks… or shortcuts in Windows lingo) go in that directory.   This includes the makezip, update_wrepo, exclude and common files that are part of the legacy/publisher section of the new WP Dev Kit I’ve published on Bitbucket.

Plugin Assets

Within each plugin subdirectory I create an assets subdirectory.  This is where my “build and production helpers” go.   My scripts specifically avoid this directory when packaging the “for consumption” products.  Within this directory I currently store things like raw image assets that typically get pushed the WordPress Plugin Directory, a full copy of the WordPress svn repository for any plugins published there, and other “goodies” I need for production that I do not distribute.  This is where my new Grunt and other build helpers will go.

Published Files Store

There is a separate directory under my home directory, ~/myplugins, where the published files go.   This helps keep my production files separate from the main plugins.  This will eventually change as I improve and streamline the process.

NetBeans “Push” Project

I also have a special directory under my home directory where I keep non-WordPress NetBeans projects.   One of those projects is a private project named “csa_licman”.  One of the many things this project does, which will also be changing, is sync any changes I make in the subdirectories of the csa_licman project up to my live server.  I use this to “publish” my premium add-ons to my live server.    I will not cover that part of the project here or the NetBeans automated FTP push setup.

You can find details on getting NetBeans projects to watch a directory and FTP files elsewhere on the NetBeans site.  I will be changing this complex part of the system to automated Grunt processing in a later revision to the WP Dev Kit.    For now you can keep the myplugins directory and manually FTP files from there to any private directories.

Keep in mind that anything going to the public WordPress Plugin Directory will be handled via the legacy script.   The NetBeans push project is only for my premium add-on packs that are not hosted in the WP Plugin Directory.

My tool kit currently consists of:

git – for managing my code repository.  I find it faster and lighter than svn.

svn – solely for publishing to the WP Plugin Directory.

smartgit – my GUI to help me cheat with git commands, I am MUCH faster with the GUI.

NetBeans – my IDE setup specifically for PHP development with heavy use of phpDoc hints in my code.

Firefox with Firebug – my test and development browser because Firebug is the easiest-to-use development tool set.

command line with Bash – the Linux command line for executing my Bash scripts, most of this should work on OSX as well.

Using The Legacy Publisher

Here is how I setup and use the legacy publisher scripts in my setup.   I call them “legacy publisher” scripts as I am learning Grunt and working toward a more intelligent processor.  The legacy publisher is based on simple Bash scripts which can be complex to configure and extend.   Grunt provides a managed system that will fetch various plugins to do a lot of cool stuff that would take me far to long to replicate in Bash.    Why re-invent the wheel?

After I get my new dev box setup and I have WordPress up-and-running and my development plugins in place under the wp-content plugins directory I attach my legacy publisher kit.   I am not going to cover the NetBeans push setup under csa_licman though you will see it referenced in the shell scripts.   Always answer “n” to “publish to live server” when running any of the legacy scripts and you will not have issues as that part of the script will not be executed.

Under my login I use git to fetch the WP Dev Kit from Bitbucket,  setup my published files directories, I then link the legacy publisher kits into my WordPress plugin directory:

cd ~
mkdir myplugins
git clone ./wp-dev-kit
cd /var/www/wpslp/wp-content/plugins
ln -s ~/wp-dev-kit/legacy/publisher/*

I am now ready to use the legacy kit to build my production zip files and publish them by hand to my server or use to push them to my WordPress Plugin Directory listing.

Simple Self-Hosted Plugins

My premium add-on plugins are the simplest setup for this environment.   Once I have my legacy publisher scripts in place I can create my base plugin files right in the plugin directory.   I edit my readme and php files, test locally, and when ready I publish them in one step with the makezip command.  Since I have a NetBeans automated push project I can answer “y” to the publish to live server question and get the files over to my server.  If you do not have this setup you can answer no and manually FTP the files in ~/myplugins to your final destination.

cd /var/www/wpslp/wp-content/plugins
./makezip slp-enhanced-results
Legacy Publisher Makezip Example
Using legacy publisher scripts to create a production zip file.

WordPress Hosted Plugins

WordPress hosted plugins, such as the Store Locator Plus plugin, require a bit of extra work to get them ready for production.    After the initial setup is in place I can update the production release using the script.    In this setup I use the assets subdirectory to assist in the production.   It is where the svn repository lives that gets updates to the WordPress servers. 

Store Locator Plus Plugin Development Folders
Store Locator Plus plugin development folders.

I start with my plugin directory in place and build the setup necessary for the legacy script to publish to WordPress:

cd /var/www/wpslp/wp-content/plugins
cd store-locator-le
mkdir assets
echo '<?php // Silence is golden.' > index.php
svn co '' svnrepo
mkdir public

My plugin is now ready for publication. I go to the wp-content/plugins directory and run and answer the prompts whenever I am ready to push to the WordPress plugin directory. The process also build a local zip file in the ~/myplugins directory so I can keep a copy on my servers.   The script will update trunk, create the version branch and even try to clean up any tags or branches if a push of the same version has failed previously.

WP Directory Marketing Assets

Getting asset files into the WordPress repository is also part of the script.   This is the preferred method for storing your plugin banner and screen shots as it lists them on the WordPress site without filling up the .zip distribution that goes to the client.  With the legacy publisher it is easy, though a bit of a manual process.   I store my banner and screenshot files in the ./assets subdirectory (note to self: should create a wp_marketing_images subdir).  Since the assets directory is never part of the published file set they are ignored.   To add assets to the WP Plugin Directory publication I create an assets directory under the svnrepo, copy over the image files I want, and run svn up from the svnrepo directory.

The Scripts

The following scripts are included in the legacy/publisher directory in my WordPress Dev Kit:

Setup common Bash variables that the other scripts use to run.


The list of directories and files to be excluded when zipping up the plugin directory.

The script that packages up the plugin directory.   Currently with some extra “cruft” to rename some of my plugin directories to a different zip file name when doing the “publish to live server” logic.

Runs makezip, unpacks the zip file into the assets/public directory to ensure a clean copy of the plugin, copies to svn repository trunk and branches to push to the WP Plugin Directory.

Posted on

Simple Web App Testing

After all the discussions about testing web apps and working with a variety of relatively horrible app testing platforms, I have been learning Selenium IDE.  Selenium IDE is the “little brother” of the full blown Selenium Web Driver.    Where Web Driver is a robust client/server framework with distributed testing and full test logic options, IDE is a simple light weight scripting plugin for your browser.

 That is what I like about IDE.   I know what it is and don’t push it beyond those limits.  It is basically a “web input” record & playback utility with a few commands added to make it a rudimentary testing system. I now use it for testing the WordPress plugin base functionality with limited effort.   Spending an extra 10 minutes writing a test case pays off in numerous “one-click-and-done” script runs in the future when I want to do something like “make sure the Pro Pack name search is not broken” after a new release.
The premise is simple, when you add Selenium IDE to your browser as a plugin you get a menu option in the browser “Selenium IDE”.   You can record a script by clicking a record button, “do you web thing”, then stop recording.  You now have a script outline.   Click the “run this button” on the interface and the script runs again.
One caveat.   The recorded scripts are not very good.  They get the job done for a quick start, but you are much better off spending and extra 5 minutes and writing the test commands by hand. They are far more efficient and accurate.

Getting Started

When you select it a new popup window opens with a simple test case table on the left and commands table on the right.   The Test Case table is mostly for Test Suites (groups of test cases you run in sequence) so we’ll ignore it for now.    On the right side is the commands and it start out with a “blank slate” of commands.   I have another blog post about the commands I use that handle 90% of my test scripts that you can use as a quick cheat-sheet.
To start a new script you use the right-side command window.  The general command sequence is to  click on a new blank line, start typing a command in the bottom-of-screen command box and press enter to auto-complete, enter a target which identifies an on-screen element in jQuery-like fashion, and a value for certain commands.  Repeat.

An Example Session

Here is how I create a simple test to make sure SLP Pro Pack is installed and allowing lat/long editing to occur:
  • Click the first blank line.
  • Select command on the bottom entry form.
  • Start typing “open”.  This is the “open  a web page in same window” command.
  • Select target.  type the relative path (you can use a full http address, but I want my scripts to run on any server)
  • Click on the next blank line & continue building out my script.

I won’t bore you with each command, here is a screen shot of the Pro Pack Edit Location lat/long script that is also on GitHub.

selenium script example
selenium script example


The commands are detailed in my other post, but the quick summary:

  • open = open a web page
  • waitForElementPresent = pause execution until something that needs to be on the page is present
  • clickAndWait = click an element and wait for the page to reload before continuing
  • type = type text into an HTML element, like an input box
  • assertValue = flag an error and STOP SCRIPT EXECUTION if the value does not match


The “target” element of the script commands can be tricky for people that do not know XHTML or JavaScript/jQuery style targets.   I find the easiest way to manage this is to make sure my web apps have discrete input names or IDs on most elements or useful and distinct class names for IDs that may be dynamic like “location-id-33”.   With a unique name or ID you can get to your target element easily, just type name=foo or id=bar and you are there if it is the only element with that ID or name.

For items without a discrete name or with multiple instances you can combine XHTML-like references with other elements.   Two key things to remember about this, using a single-slash means “exactly at this point in the document hierarchy and double-slashes means “first found”.     For example /table/thead/tbody/tr[1] is THE first row after the table, thead, tbody elements.  If any are missing it will fail.    In contrast /table//tr[1] will meant the first table row that can be located after the first table in the document.    I often mix-and-match “select by name” and the double-slash “first found” options so that something like this shows up:


This is useful in WordPress where I can never be certain that a theme will not change the page structure.  In this case it says “find the first table element with an id set to foo, within that find the second tr element (since a theme/plugin may throw in some thead or other element I continue the // format), find the second th element in that row, and select the first hyperlink with a class set to ‘bar’.

Targets take some getting used to, but luckily you can test your “guess” at the right path after it is entered with the “find” button that will go show you which element it thinks you mean on the page that is currently rendered in the browser window.

What I’ve Learned

A couple of important things I’ve learned along the way.   First, use waitForElementPresent judiciously.   I usually put this in place before I interact with the first item on the screen.  The “…AndWait” commands wait for the page to load but with so much jQuery page loaders out there it is common for the element you need to not be ready when the page first comes online.   The “waitFor…” commands can wait a long time and will not always flag an error if they time out.    Use “assert…” whenever something critical must be on the page or to flag a script as failing.   “assert…” is NOT the only way a script will fail, which is a feature I like about Selenium IDE.  If you try to click an element and it is not there it fails the script but tries to continue running.  This makes it very easy to write light-weight test scripts.

No Excuses

Overall it is not as robust as many testing platforms, but that is a good thing IMO.   Because it is light & easy you can get Selenium IDE in place and get your first test scripts online in well under an hour.    That means you really have no excuse not to be doing at least RUDIMENTARY repetitive task testing on your web apps.

I’ve started using this to test my WordPress plugins and try to add at least one new short test case in each plugin release.  It adds about 10-15 minutes on average to the test cycle but it means one more feature is tested before each release.  Even now with just a dozen test suites I’ve prevented at least two significant functional bugs from getting out to the public.

Use Selenium IDE and do some web tests.   The user community will thank you for it.

### Technorati Claim Code CGBQWRFD3GA5 ###
Posted on

Selenium IDE Commands

I’ve been using Selenium IDE for a few months now with very simple test scripts.   Mostly scripts I’ve recorded to test my WordPress plugins.   They are not very sophisticated, but as my release schedule has increased so has my need for more robust testing.  Unfortunately the Selenium IDE 2 documentation is sparse at best.   Maybe they have a complete list of commands and how they work, but I can’t find it.

So I decided to create my own Selenium IDE commands list.   This is my cheat sheet and is based on my current knowledge as an end user.  It may not be accurate, so always check what you read here before applying it to a production test suite.

Using Selenium IDE

One of the first lessons I learned is that recording/playing back scripts is a great way to get started.   The second lesson learned seconds later is that the scripts are far from perfect, very inefficient, and always need editing.

Add wait commands, it is key to successful tests.   Always make sure an element is loaded before running full speed through the script.

Edit the first couple of commands to go directly to the test URL.  Often the scripts start elsewhere.

Realize this is not a full programming language.  Out of the box it does NOT support if, goto, or loop constructs.  It is a pure linear command execution.  If you need more you should get an add-on OR use the full Selenium RC line.

Selenium IDE Commands

(that I use)



locator – an element locator


Make sure an element is present, if not fail and abort the remainder of the test.


I use this to make sure that a previous test suite or action did what I expected.  If not, something is horribly wrong.   Assert commands tell Selenium IDE “hey, something bad happened… stop testing”.



target – a piece of javascript that returns a value

value – what you expect the value to be set to


Make sure the javascript executes.  The find button will not work here, you must execute the command to test this.


This is a recent addition to my Selenium IDE arsenal.  I use it to check custom CSS rules and make sure that when I tweak a CSS rule via my admin panel textarea field that it makes it to the front end.   I check the computed style of a specific element and make sure the attribute is set as I expect.  For example, check that the final style sets a font size to 48px.

Example target:


Example value:




locator – an element locator


Check a toggle-button (checkbox/radio).


This is a great way to force a checkbox on.   The mirror command is uncheck.

  • command: check
  • target: you element finder i.e. name=checkbox_name_property
  • value: n/a (leave blank)



locator – an element locator


Clicks on a link, button, checkbox or radio button. If the click action causes a new page to load (like a link usually does), call waitForPageToLoad.


A good idea to use waitForElement to make sure your locator is present before doing this.



url – the URL to open; may be relative or absolute


Opens an URL in the test frame. This accepts both relative and absolute URLs. The “open” command waits for the page to load before proceeding, ie. the “AndWait” suffix is implicit. Note: The URL must be on the same domain as the runner HTML due to security restrictions in the browser (Same Origin Policy). If you need to open an URL on another domain, use the Selenium Server to start a new browser session on that domain.



selectLocator – an element locator identifying a drop-down menu
optionLocator – an option locator (a label by default)


Select an option from a drop-down using an option locator.


The easiest way to select an element on a pulldown list is:

    • command: select
    • target: id=<input id>
    • value: label=<text string of item to select>

Here are notes on the selectors from Selenium IDE:

Option locators provide different ways of specifying options of an HTML Select element (e.g. for selecting a specific option, or for asserting that the selected option satisfies a specification). There are several forms of Select Option Locator.

    • label=labelPattern: matches options based on their labels, i.e. the visible text. (This is the default.)
    • label=regexp:^[Oo]ther
    • value=valuePattern: matches options based on their values.
    • value=other
    • id=id: matches options based on their ids.
    • id=option1
    • index=index: matches an option based on its index (offset from zero).
    • index=2

If no option locator prefix is provided, the default behaviour is to match on label.



locator – an element locator

value – the value to type


Can also be used to set the value of combo boxes, check boxes, etc. In these cases, value should be the value of the option selected, not the visible text.


This is what I use to “type” data into an input field.



locator – an element locator


Uncheck a toggle-button (checkbox/radio).


This is a great way to force a checkbox off.   The mirror command is check.

  • command: uncheck
  • target: you element finder i.e. name=checkbox_name_property
  • value: n/a (leave blank)



locator – an element locator


true if the element is present, false otherwise


Verifies that the specified element is somewhere on the page.


I try to use this before I click on anything, enter input values, etc.  Often an element is not loaded yet.  This waits until it is (or fails).

Checking if a hyperlink that contains specific text is a good way to manage the AJAX operations of WordPress categories.    You can use the following command set:

command: waitForElementPresent
Target: xpath=//a[text()='Category Name']

My Script(s)

I  have my Store Locator Plus testing scripts on a public GitHub repo for anyone that wants to see them.

Enjoy & please share your Selenium IDE wisdom here.  We can all use help when it comes to using this tool.

Posted on

SLP Maps and Late Loading Scripts

Since the Store Locator Plus 3.2 release, our SLP plugin now defaults to the less efficient “Early Loading” mechanism for rendering our required JavaScript.  This adds a lot of unnecessary overhead for other pages on the site but works with more themes.

Pro Pack users have an option to turn off “early loading” with the “force load javascript” checkbox on the main settings page.   Turn this off if your theme and plugins are “late loading friendly”.  Your site will just a little faster on all the non-SLP pages.

The Discussion

We often run into sites that do not load the Store Locator Plus map ever since our version 3.X update that uses late loading to be more intelligent about how scripts are loaded.   Here is an excerpt from an investigation with a client installation related to this issue that will shed some light on the problem.


 I need to create an option for “early loading” and “late loading” of scripts.  There are simply too many themes or plugins that break late-loading plugins.

 Late loading is WAAAAYYYY more efficient.   What it means is we can detect “hey, this page is showing a SLP map” and only then load all the heavy javascript to support it (google maps API, our scripts, etc.).
Early loading means we load all of our scripts on every single page, regardless of whether the page needs it or not.  The bonus… it always works.    The downside, it is slower.  Especially on very busy sites.
However, in the past 6 months since we changed to the smarter model we have come to realize there are THOUSANDS of plugins or themes that are just not well engineered.   Thus we realize we must engineer our plugin to be even smarter.
With version 3.2 Store Locator Plus will default to “early loading” and always load our scripts.  It will work on more sites but be slower.    The Pro Pack will have an option to turn on “late loading”, removing the early loading and making the plugin more efficient.  If it doesn’t work (like on your site) you simply uncheck the box and go back to the slow but working method.
In the long run you are better off using only themes and plugins that do not break plugins that take advantage of the late loading feature available since WordPress 3.2.  Your site will load faster as more & more plugins start using this methodology.
The short version, it is going to take quite a bit more effort but this is the best solution.   The fix for your site is to select a theme & plugins that are well engineered.  Your new site is not working because the theme is not calling the proper WordPress 3.2+ action hook sequence.
The bottom line of all this.  Some plugins and themes are not well engineered.  When we release version 3.2 of SLP we will provide an option to “be slow and work around bad plugins/themes” or “be fast, I am using a great theme and well designed plugins”.


After days of looking for workarounds to the problem we have discovered that a key element for Store Locator Plus to function efficiently is the use of wp_localize_script.  This is the cleanest and most efficient way to get PHP variables, like your map settings, into the JavaScript engine for Google Maps.
Some themes, it turns out, do not properly support late loading scripts.  In order for wp_localize_script to work after a shortcode has been rendered the script must be loaded in the footer, or “late loaded”.
We do this to ensure that any attributes you add to the shortcode are passed to the JavaScript engine.  This is the only way to override map defaults on a per-page basis.   Thus, if your theme does not support late loading scripts (which is a WordPress 3.x+ standard) then Store Locator Plus may not work on your site.
The first thing to do is ask your theme provider to update their theme to properly support late loading and localized scripts.   Then check back here for updates.  We are working hard to make our plugin compatible across as many themes and plugins as possible.

Update #2

A follow-on discussion with our client about why we do late loading and why “other plugins don’t seem to break but SLP does”.
Most plugins will not have a problem because they are not nearly as complex as Store Locator Plus.
We use 3 very inter-dependent elements of WordPress and JavaScript to make the plugin as efficient as possible and not slow down your site.   All 3 pieces need to fire at the right time and the process cannot be interrupted.
1) Register the script early in the WordPress process.
2) Localize the script (very few plugins do this, less than 0.1%).  This is the best method for getting WordPress settings into JavaScript.   It is relatively new, very few developers know about it.  As such almost no plugins do this.  It is sad because WordPress promotes this as THE WAY to get JavaScript & WordPress talking efficiently.
3) Enqueue the script.
99.9% of plugins will never break because they don’t localize scripts.  Instead they do the old inefficient (and insecure I might add) way of getting WordPress data into JavaScript.    Sadly since 99.9% of plugins that need WordPress data in JavaScript just copy what someone else did, instead of learning how to do it properly, the problem gets replicated more than TWO YEARS after WordPress provided a better solution.
I know because I did the same thing 2 years ago until I discovered localization of scripts and spent time learning how it works and why it is better.
So the short version… it does not surprise me that other plugins don’t break when someone (Media Grid) inadvertently short-circuits late loading JavaScript like that found in SLP.
The checkbox, BTW, turns OFF late loading JavaScript. SLP does not break but every page load is going to be slightly slower on your site as long as the box is checked.
For “fun” you should look at a random page and see all the CSS and JavaScript that loads.   80% of it is never needed/used for the page you are looking at.   That is because 99.99% of plugins don’t care they just force their stuff to load ALL THE TIME whether it is needed or not (early loading).   We explicitly try to NOT do that mostly because we need to talk to Google.  Run your site on a slow Internet connection and you’ll see why we try to only load up our stuff when absolutely necessary.