It’s one of the more frustrating “rabbit holes” a developer can fall down: chasing errors in software your project is using, that you didn’t write yourself, but which is both required and affecting an outcome in your own code. I’m not bald because of genetics!

An example: the Gravity Forms plugin is a good product–I use it a fair amount–but there is a maddening bug when trying to use their “form widget” in a sidebar.

It’s a very basic PHP bug–they simply forgot to check whether variables are “set” before trying to access them. PHP doesn’t like that. But because their code is executed within the WordPress Widget API, errors are spirited away unless you work to prevent that “magic” from happening.

(I get the impression a fair number of developers don’t try to see what’s behind the curtain beyond setting WP_DEBUG to true. Gods help me, I’ve worked with people who didn’t even make that effort!)

Not to drag this out, here’s the “gist” I wrote to demonstrate the Gravity Forms error to them:

For most coders, the error is not hard to spot–it’s one all of us make every day.

I “helpfully” re-wrote the code a bit so it would not throw an error (and I probably went a bit overboard in prepping the data, but that’s what I do):

The most interesting thing to me was their response, which was first “we don’t believe you” (essentially) and then once demonstrated became “we’re not going to fix it”. That’s weird, it’s an easy fix. Doesn’t that seem weird?

In any case, a lot of time can be lost on a project trying to track down and work around stuff like this. It’s also very difficult to get a client to compensate you for your lost time, so it’s a double-whammy.