In Google Docs, it’s a fairly simple task to create a ‘form’, and then to embed that form into your WordPress footer so that users can report bugs.  The bugs, when submitted, are automatically posted to a spreadsheet in your Google Docs, which can be shared with multiple users.

Step 1 – Create the form in Google

This is a fairly straight forward process. After creating the form, you’ll want to choose “more actions”, “embed” – and grab that code, and put it aside until later.

Creating Google Docs Form

For my own bug tracking form, I’ve chose the following questions:

  • Page URL
  • Bug Description
  • Severity of Bug Fix (see below)
  • Browser version(s) bug was detected

I also add these fields to the spreadsheet where the data is collected:

  • Priority Note (if needed, user can explain why something has a certain priority, or if they have changed someone else’s prioritization)
  • Fixed date
  • fixed by
  • fix verified by

For my users, I have a suggested Severity Rating:

  • 1 – ‘Show Stopper’ – i.e. it is impossible to continue with the testing because of the severity of this error / bug.  In a live environment, this is a bug so severe that it disrupts business, and requires available resources to address the issue ASAP.
  • 2 – Critical – testing can continue but we cannot go into production (live) with this problem.  In a live environment, this is a bug that impacts business to a degree that it must be addressed quickly (same day).
  • 3 – Significant – testing can continue this feature will cause disruption to business processes in live operation.  In a live environment, this is a bug that impacts business and should be addressed efficiently (same week).
  • 4 – Minor – testing can continue and the system can go live with only minimal departure from agreed business processes.  In a live environment, this bug should be added to the next release build.
  • 5- Very Minor – both testing and live operations may progress. This problem should be corrected, but little or no changes to business processes are envisaged.  Also applies to ‘Cosmetic’ Problem e.g. colors; fonts; pitch size However, if such features are key to the business requirements they will warrant a higher severity level.  In a live environment, it should be evaluated whether this bug needs to be addressed in the next release build.
  • 6 – Suggestion – New idea that would improve system functionality, usability, performance, or visual/customer appeal, but not a “bug”.

Putting the Code in my WordPress footer

I then add a piece of code to my WordPress Footer.  By including the IF statement, users who are NOT logged-in to WordPress won’t see the form.  I do include a link to log-in, so that users can make that simple leap.

<?php if ( is_user_logged_in() ) {
} else {
echo ‘<a href=”/wp-admin”>login</a>’;

And replace  GOOGLE FORM EMBED CODE HERE with the embed code you got from Google.  The end result will look like this:


if ( is_user_logged_in() ) {

echo ‘<iframe src=”” width=”760″ height=”721″ frameborder=”0″ marginheight=”0″ marginwidth=”0″>Loading…</iframe>’;

} else {

echo ‘<a href=”/wp-admin”>login</a>’;



If you use your Footer include everywhere, the bug reporting form should show up everywhere now.  Just remember to share the Google Docs spreadsheet where the information is being dumped with the relevant users.

Once you’re gotten your bug reporting form where you like it, you can save it as a template, and re-use as needed, saving a lot of effort.

This entry was posted on Wednesday, June 2, 2010 and is filed under Blogging, Content Marketing, Digital Advertising.

Related Posts

Your thoughts? Please comment below.