The other day we were having a workplace discussion about setting up a new internal tool, in this case, a documentation library. You see, we needed a place to store all of our internal guidelines and workflows, something we could all contribute to and new employees could reference when needed. This library could hold our procedures for launching a website, for example, or running an accessibility audit. And it needed to be a little more robust than a bunch of Google Docs or pinned threads in Slack.
We began by discussing a few SaaS offerings — tools like Confluence, which comes from the team behind Trello and Bitbucket, two things we use pretty often. But of course, it didn’t look quite right for us, considering the cost. So we explored a few other, lesser-known options, but again, nothing looked quite right. At some point, throwing money at an online tool that you’ve never heard of just feels… scary. What if it shuts down or they increase pricing? What if we don’t end up liking it or it’s missing a key feature from its roadmap? All of that data entry becomes a sunk cost.
Finally, I just decided to be that guy. The guy who says the thing many developers reading this now are thinking: why don’t we just build it ourselves? And not only that, I had to take it that extra step further: why don’t we just build it ourselves with WordPress?
The truth is, no matter what project comes up, that is always what I’m thinking: “I could probably build that on WordPress.” What do I need, user accounts? Check. Content editing capabilities? Check. Completely extensible codebase and database architecture? Check. Ability to build the whole thing as a headless Vue.js app or something using the REST API if I’m feeling it? Check.
Now, are there better frameworks than WordPress for something like this? Most definitely. There’s probably a reader right now screaming into his Dvorak keyboard that Laravel is what I really need (not wrong), or perhaps Gatsby.js is the only way to go (I’m partial to anything referencing F Scott Fitzgerald). But the truth is, the benefits of leveraging our own WordPress knowledge are worth so much time saved that it’s hard to justify any other toolset. Sometimes a project comes along where you have a decent padding of time and money to intentionally learn something new. This is probably not that month.
So, I did a quick check, and of course there are already a few “documentation library” plugins out there that look pretty decent. But if I’m being honest with you, I really, really, REALLY do not like using a plugin if I don’t have to. I understand that plugins are one the most important, groundbreaking features of WordPress that enable this big, beautiful ecosystem we’re all swimming in. Plugins are great and I build them for clients all the time. But I can’t imagine I’m the only one who feels a little plugin-phobic at times.
Using plugins feels like building a house of cards to me. Because you never need one plugin. You need a suite of plugins. You need an all-you-can-eat, Las Vegas buffet of plugins.
This happens all the time on client websites: You need the plugin for e-commerce, say, but then you need another third-party plugin for the payment handler and another one to juice up the login/registration page, and another one to track the recurring memberships and another one to override the email templates and another one to tweak the onboarding flow and another one to modify the user permissions and another one to bridge the layout with your theme and another one to connect it to your CRM and another one to migrate users to your email marketing service and another one to modify the account dashboard and another one that syncs to your Google calendar and another one for that widget or block and another one and another one and another one.
And now you’re afraid to update. And you’re afraid not to update.
And you still didn’t get that one key feature you wanted.
This is the house of cards, something I’ve been thinking about since reading this spot-on piece by Kim Coleman.
This is the double-edged sword of the WordPress ecosystem: There’s a solution for every problem. And a problem with every solution.
For many of us in the development space, we tend not to worry about this, because the WordPress way is extensibility. Worst case scenario, I can take everything I have now and code my way into a solid solution without modifying WordPress itself. That’s the guarantee that I have when I start a project on WordPress.
So will I grab something “off-the-shelf” or will I wrangle together a few custom post types, some custom fields, and draw up a few template files? Most likely the latter, because if I’m going to build a house of cards, I’d at least like to know what’s holding it together.
