The update that broke the contact form.

Part 3 of 4·Know before your clients do

The update went well. Every plugin is green. The home page loads. You open the contact page and it looks exactly as it did this morning. You tell the client it is done.

Three days later the client asks why nobody has written in all week. The form is still there. Press Send and a short line under the button says there was an error. Nobody pressed Send except visitors. Visitors do not write in to say the form is broken. They leave.

Loading is not working

Most checks after an update ask one question: does the page load? An uptime monitor asks it every minute. A person asks it by opening a few pages. A page can load perfectly while the thing on it that makes money is broken.

The usual suspects after a plugin update:

• A form that lost its security token or its handler, so every message fails.
• A menu, tab or Add to cart button that no longer responds to a click.
• A PHP warning printed at the top of every page.
• A script error that stops everything after it.

None of these change how the page looks. A screenshot from before and one from after are the same picture.

Snapshot, update, compare

Soundcheck (opens in a new tab) opens the whole site in a real browser, the way a visitor would. It finds the pages from the sitemap and the links, opens each one at desktop and mobile size, clicks what can be clicked, measures and takes screenshots. That is the snapshot, taken before you change anything.

After the update, compare checks the same pages again and shows only what is different, the most serious first. Something that worked and now fails is BROKE. A new problem is NEW: a PHP warning with its file and line, a JavaScript error, a dead button. Before it reports either, it visits the page again, so a hiccup on the server does not end up in your report.

This is a real compare against Soundcheck's own test site on my machine. I took the snapshot with the submit level on, so it filled in the contact form and sent it. Then I switched on two of the test site's broken scenarios: a form handler that fails and a menu script that no longer finds its button.

Both pages still loaded and looked the same. Soundcheck found the form that no longer submits, with the error it showed. It also found the Browse button that does nothing on every page it sits on.

Without the submit level it still checks that each form has its action, its labels and its security token. With it, on staging, it sends the form with test data for Contact Form 7, WPForms, Gravity Forms, Elementor and WooCommerce. Run it with Echo (opens in a new tab) and it also checks that an email went out behind the thank you.

What else it catches

The same snapshot and compare cover the other quiet failures an update brings:

• One cart for everyone. A cache rule changes and the next visitor gets someone else's cart, their logged-in page or a security token that has already expired. With a test login Soundcheck checks what the cache hands to a stranger.
• One change on every page. A new header across 300 pages comes back as one line, not 300. A slider that moves on its own is learned, so it does not fill the report.
• A big shop without a URL list. It finds pages from the sitemap and the links, checks the first pages in each folder and samples the rest of each pattern. A shop with 3,000 products is checked through 13 product pages.

What it will not do

• It submits forms only when you turn that on. It refuses to on any site you list as production.
• It browses politely at five page loads a second and skips clicks that look destructive.
• It reads credentials only from the environment and never writes them into a report.

Soundcheck is free and open source under the MIT licence. The code is on GitHub (opens in a new tab) and the whole set is on the open source page.