There is a long-running discussion at LexBlog about the benefits and perils of third-party solutions. This discussion has been going on for so long that if you look closely enough, you can find evidence of it in this A List Apart post from 2014 by our own Scott Fennell. This post, is also the subject of Scott’s WordCamp Portland Maine talk this year, so the battle clearly rages on (shameless plug for Scott/WordCamp Portland Maine here – he’s in some rarefied air with this speaker list!).
As with most things, I find my opinions on this subject to be complex. On the one hand, I’ve personally seen what happens when a site manager grows accustomed to a WordPress plugin only to see the support for it slowly fade as the developer (or company) behind it slows their involvement in supporting and managing the codebase. On the other hand, I’ve
npm install‘d my way to freedom from more issues than I’d like to admit.
Today was a day where I was saved by a third-party solution. WP Crontrol, a plugin from John Blackbourn, is a handy tool that provides a user interface for CRUDing WP-cron events. Typically, the problems that plague the WP-cron elude us as WP Engine provides a true cron that we use on all of our environments to ensure that scheduled actions take place when our publishers (and us) expect them to. However, this isn’t a perfect solution as long-running crons can cause a bottleneck to appear at the top of the cron stack with those cron jobs stopping others from firing. This is a pretty frustrating issue for someone that just wants their scheduled post to go live without worrying, and difficult to troubleshoot as cron events are held off in the database without a great way to manage them.
Enter WP Crontrol. After installing this plugin, I was able to easily see a list of cron events that clearly should have fired by now. After deleting the oldest cron, the rest cleared up in short order.
Now, Mr. Blackbourn is a well-known quantity in the WordPress realm. We use his plugin Query Monitor regularly, he’s a core contributor, and works at Human Made, a highly-regarded WordPress agency. This is a far cry from the sorts of solutions that Scott or other members of the LexBlog product would typically have concerns about.
But where do you draw the line? As I eluded to above, npm is something I’ve grown accustomed to using, and many of those modules have dependency chains that stink to high heaven. LexBlog taps into a number of third-party plugins that are now a core part of our product offering. WordPress itself is a third-party solution that we have built our business upon. There is no escaping the power of these tools, and I wouldn’t want to even if I could.
The trick, as Scott so eloquently puts it at the end of his post on A List Apart, is knowing when to leap into someone’s helping hands, and knowing when to take a stand:
It’s not that third parties are bad per se. It’s just that the modern web team strikes me as a strange place: not only do we stand on the shoulders of giants, we do so without getting to know them first—and we hoist our organizations and clients up there, too.
So look before you leap. It’s never as easy as just installing and forgetting.