Word Press was released in the fantastic world of 2003, before 5G, wifi-7, and meta glasses.
I have been seeing Word Press everywhere the last few years. So many highlights of what people are doing with it, so many people wanting it managed. I wondered to myself if Word Press was something I needed to learn to make myself more marketable. Since I have actively avoided it, I wondered what exactly I was missing out on.
Investigation
A surface level investigation reveals that Word Press is a frequent target for bad guys, ( I refuse to say hacker because I want to remove the stigma that all hacking is bad. ) and you would have to pay special attention to patches, updates, and backups along with app hardening. Ignoring an update leaves you open to bugs or exploits. Complex customizations can make updating risky. Conflicts, bloat, and lack of optimization can slow you down. I don't think I need to continue, there is a lot of uncertainty.
Not sure if I'm interested in joining that party. So, THIS is why I see all of these Word Press jobs available. It all makes sense now. 😂
When I was first starting in web development, I would read all these Word Press memes and general complaints. It gave me a cringe feeling. To make matters worse, it seemed like every other available position was managing Word Press. Come oooooonnn dude. You want me to optimize on top of someone else lack of care? Hmm. No. Hire a developer. We need jobs! Let us build you something far more elegant, custom, and up to date. All we ask for in return is job security, no? 😂😂😂
Word Press may single handedly lead to the rise of the junior developer once again. 🤣 🥳 I’m not going to waste my time learning an over-bloated system with high security risks. I’ve got enough drama in my life. Personally? Knowing what I know now, I would not run the risk of putting my personal ecommerce site on Word Press. The bigger you are and the more you buy into, the more you expose yourself. I'm probably severing any possibility of ever working with Word Press here. Oh wellsies.
It’s better to stay as O.G. and annoyingly granular as possible. It’s more secure. It gives you pride. It gives you control, if you can accept responsibility for yourself and others. That's not to say there isn't use cases for using prebuilt tools and templates, there are. But I digress.
If security is not a valid concern for your use case, like in the case of a static website or recipe archive of some sort, than by all means, Word Press away! I’m sure this is perfect for some applications.
Here is a source of entertaining Word Press memes: https://www.wpfixit.com/wordpress-memes/
From my brief digging this morning, I've learned that Word Press is a fertile land of plugin chaos. 🦄 I will continue building fully functional features on my website from scratch, as I want to keep a thin slice of sanity. Leave it to a developer to complain about Word Press, of course. I guess it was my turn. 🤣
For Mr. Fancy Businessman
Hire a developer Mr. Fancy Businessman, that Junior developer will take you far further in the way that you prefer than Word Press likely ever could. Especially if you have anything of a unique situation. If the “bad guys” don’t understand your system architecture, you become more of a pain in the *ss to exploit. You bullet proof yourself to a degree. Be annoying and let them go for low hanging fruit elsewhere.
To My Peers
And to my peers: Don’t get overly reliant on AI. Go build a system at home, on a small computer, on a Linux device. Learn how to host it all and make it secure on your own network. Be a powerful developer, make the people that came before you proud. No laziness. If you want a junior role you must outshine the current capabilities of existing systems. That’s going to be a lot of work. Start now. (Or make your own business!)
Now, I am not completely dense. I only have an outsider perspective. What can you tell me about the ins and outs of Word Press land? I challenge you to slant my opinion. I am genuinely curious if for nothing else than entertainment value.
Top comments (18)
Since you asked to be slanted a bit, here's one. WordPress core has installed minor security releases on its own by default since version 3.7 and since 5.5 you can turn on auto-updates for each plugin. A lot of the scary stories are sites where nobody turned that on, or a dead plugin nobody replaced. A custom site has the same chore, it just shows up as npm or composer updates instead.
Loved the lighthearted tone of the post, but as a developer working in threat modeling and security architecture, I couldn't resist jumping into the debate with a few counterpoints!
1. The "Obscurity" Trap: Assuming custom code is safer because "bad guys don't know your architecture" is a classic security anti-pattern (Security through Obscurity). Kerckhoffs's principle and Claude Shannon reminded us long ago: "the enemy knows the system." Automated bots and scanners don't care what your stack is; they hunt for unvalidated inputs, broken auth logic, XSS, and SQLi regardless.
2. The Reality of Custom Code: In 2026, nobody builds a modern web app 100% from scratch without third-party packages or libraries. If a junior dev builds a custom system without deep threat modeling and security audits, every line of unvalidated code becomes an invisible zero-day waiting to happen. Moving away from WP doesn't eliminate security debt—it just shifts the entire patching burden onto a single dev.
3. Why WordPress Gets Hit: WP powers roughly 40% of the web, so naturally it’s a giant target. But its core is actually battle-tested by thousands of security researchers. Over 95% of WP vulnerabilities stem from unpatched third-party plugins and poor maintenance, not the core CMS itself.
4. Business Reality: "Mr. Fancy Businessman" relies on speed and predictable costs. Rebuilding a complex app from scratch for tens of thousands of dollars—plus indefinite custom maintenance—rarely makes financial sense. Businesses stay on platforms like WP because it's far cheaper to harden the app, set up a WAF, and automate backups than to reinvent the wheel.
At the end of the day, neither AI nor WordPress is to blame. Security comes down to developer responsibility, proper data validation, and threat modeling—regardless of whether you're using a CMS or writing Node/Go/Python from scratch.
Thanks for sparking such a fun discussion!
Thank you for your extremely thoughtful comments @kate8382 ! I suppose I did oversimplify a bit here.
And I totally get your point about plugins, but what percent of businesses on Wordpress are using a plugin? Nearly 100%. Even if we can blame the developer of the plugin, the business still suffers as a result.
And what about vulnerability chaining, in the case where two plugins are fine by themselves but their combined flaws are combined into an exploit? Rabbit holes..... everywhere. 😂
Fair point! That’s the classic compositional risk problem—and honestly, it’s not unique to WordPress at all.
Whether you’re stitching together WP plugins or pulling in dozens of npm packages in a custom Node/React stack, you're dealing with distributed teams building isolated pieces without knowing how they'll interact in the wild. Two completely benign modules can easily create an exploit path when combined.
You don't shut down and rebuild an entire factory from scratch because one bolt failed—you put strict quality gates, isolation boundaries, and interface contracts between the machines. In software, it comes down to architectural governance and validating how components talk to each other, regardless of the underlying CMS or framework!
On the chaining question — I've seen it happen when one plugin exposes a field and another exposes an endpoint that can read it, and neither looks risky alone. The practical check I use is listing which plugins touch the same data or user roles, and treating those pairs as one surface to audit together.
Nice @rushdeploy , that sounds like an excellent strategy!
Clean architecture is easy to maintain in a slide deck; the real test is how gracefully the system degrades under cascading production failures.
Minimizing abstraction layers and owning your critical runtime path will always outperform adding more third-party glue.
That sends a chill down my spine! 😂 If you have a story I would love to hear it!
And I like how simply you put it "minimizing abstraction layers." So graceful.
Your question about vulnerability chaining stuck with me, especially after the replies about one plugin exposing a field and another exposing a route. That pairing is exactly what makes plugin chaos hard to judge from a single plugin review. I also liked the nudge to build a small system at home instead of leaning on AI for every step. Hands on practice with the pieces makes the security tradeoffs much clearer than reading about them.
The line that hit me: "WordPress may single handedly lead to the rise of the junior developer once again."
Okay, you challenged us to slant your opinion, so here goes. 😂
You are 100% right about the plugin chaos and the security nightmares. But I think the "hire a developer to build it custom" argument misses a massive business reality: maintenance.
If a junior dev builds a custom app from scratch, it might be elegant and secure on day one. But what happens when that dev gets a new job? Or when the client wants to change a simple image and doesn't know Markdown? Custom code requires a developer for every tiny change. WordPress exists because it democratizes publishing. The non-technical business owner actually owns their content.
Also, I'd push back a bit on the security aspect. Yes, badly maintained WP sites are hacked constantly. But a lot of custom-built apps by junior developers are terrifyingly insecure because they don't have the security teams that WordPress core has patching vulnerabilities 24/7.
Security through obscurity ("if bad guys don't understand the architecture") isn't security—it's just hoping nobody cares enough to look.
I completely agree with your point about building things from scratch to learn. It's the best way to grow. But for Mr. Fancy Businessman, a managed, secure WordPress site might actually be safer than a half-finished custom app.
What do you think? Am I completely off base here?
There's another security issue here that I think deserves attention: trusting a vendor's infrastructure doesn't necessarily mean trusting everything it delivers.
A good example is the June 2026 OptinMonster supply-chain incident. Attackers compromised credentials associated with Awesome Motive's CDN and modified JavaScript files served to OptinMonster, TrustPulse, and PushEngage users.
The interesting part wasn't just the compromised scripts. The malicious JavaScript could capture authentication tokens and WordPress nonces when an administrator visited a page while logged in. It then used that access to create unauthorized administrator accounts and install a hidden backdoor.
What makes this particularly concerning is that the attack didn't require exploiting a vulnerability directly in every affected WordPress installation. The malicious code arrived through infrastructure those websites already trusted.
I think this exposes a weakness in how we approach legacy maintenance. Updating WordPress core and keeping plugins patched are necessary, but they don't address every layer of the software supply chain.
For production environments, I'd also consider:
There's a difference between maintaining software and continuously verifying the integrity of everything that software depends on.
I'd be interested to know how you approach this boundary: at what point does trusting a third-party plugin or service become an architectural risk rather than simply a maintenance decision?
Hello @sinarezaei , thank you for sharing your thoughts. In my opinion, most things cannot be trusted. And to your point of the OptinMonster incident: places that something seems to originate from may not themselves be to blame. That is a whole judgement and who-done-it can of worms I can't even imagine. When is it an architectural risk? In my opinion, as soon as it leaves your hands, as soon as it's shared, and as soon as someone else can touch it. That might be a bit extreme, but I've grown to believe it is the truth.
I have an appreciation of your elegant monitoring strategy idea. Anything that can offer insights is fantastic, but that could itself invite more unwanted things into the picture, perhaps? Do you typically monitor using your own tools or do you have favorites, and could you give me an example? Thank you! ✨
I usually think about this as layered monitoring rather than relying on a single security plugin. The approach also depends on the environment.
For client WordPress projects, I use established security tools where they make sense. But for my own infrastructure, I prefer combining different tools with custom monitoring built using Node.js and Next.js.
One reason is that security tools usually specialize in specific attack patterns. A firewall might handle malicious requests well, but that doesn't mean it can detect a compromised third-party script, an abused administrator session, or every vulnerability in a plugin.
There's also the operational side of security. Aggressive firewall rules can create problems of their own. For example, a legitimate admin request from a page builder might trigger a WAF rule, or incorrect IP detection behind Cloudflare could result in an administrator getting locked out. Wordfence even provides a Learning Mode to help reduce these false positives.
For a WordPress environment, I'd combine tools like WP Activity Log for admin and plugin activity, server-side file integrity monitoring through Wazuh or OSSEC, and CSP reporting to track unexpected third-party script behavior.
Here's a more interesting example: imagine an e-commerce site using OptinMonster, which loads JavaScript from an external CDN. The plugin itself hasn't changed, WordPress core is fully patched, and everything looks normal in the dashboard. But the CDN starts serving a modified JavaScript file.
A CSP report might reveal unexpected script behavior, while file integrity monitoring checks whether local plugin files have changed. At the same time, activity logs could flag a newly created administrator account or an unexpected privilege escalation. Individually, these events might not look related, but correlating them by timestamp can reveal a much bigger problem.
I'd also keep monitoring credentials read-only wherever possible, send logs to a separate system, restrict access to reporting endpoints, and avoid giving security tools more permissions than they actually need.
Of course, custom monitoring needs to be secured and maintained too. I don't assume building my own tools automatically makes them safer. The point is to understand what each layer can detect, what it can miss, and how they work together.
I wouldn't try to blindly trust every tool. I'd rather make sure no single tool has enough access or authority to compromise the entire environment. For me, that's what a practical layered security approach looks like.
I've worked with WordPress for a very long time and made a living out of it from 2007 to 2016. Left it because I got busy with other things, but it certainly is far better than building everything from scratch.
My short take is:
Building something from scratch may become a security nightmare if you don't work on it for a long time handling all the security loopholes others have worked on for decades.
XSS issues, SQL injections, privilege escalation, escaping and double escaping issues etc. are not as simple as they sound when you will have to work on all of them together. LLMs, even the most advanced ones can detect these, but are very poor in fixing these.
A well maintained WordPress site is still your most cost effective option.
Last but not the least, since WordPress still has 30-40% of the entire web adoption rate, if you can break into the Plugin ecosystem, you can make a decent living out of it. A $10/year plugin subscription doesn't sound a lot, until you have 20K subscriptions.
It's easier to get 20K paid subscribers with a good WordPress plugin that solves a pain point, than making a mobile app that receives 20K downloads.
That is what 30-40% global adoption rate gives you.
No wonder why all the jobs are WordPress jobs.
I have been seeing a lot of Wordpress job postings in my area but I'm not clicking it since I don't have any idea about that. But from your description alone (thank you btw), I am now happy that I don't know it in the first place. It seems like wirings are all over the place. Yeah, I agree, I'm happy with my custom made simple feature for everyday web apps, thank you.
@codingwithjiro I think it's important to point out that while Wordpress is an easy target for many reasons, the fundamental concept is how responsible one is, for ones own code. @kate8382 makes a good point on that.
But, I also get the sentiment, totally. haha
Haha, thanks for the shoutout @annavi11arrea1! And honestly @codingwithjiro, I totally get that feeling of dodging a bullet—I have the exact same emotional reaction every time I look at a React dependency tree! 😂
Ecaterina's counterpoints are worth reading, but I think your instinct is pointing at something real even if obscurity is not the answer. A lot of WordPress risk is not in the core. It is in how sites are run: plugins added by hand on a live server, updates skipped because nobody is sure what will break, and no record of what is actually installed.
At Ascendra Ventures we rebuilt a marketing site that ran as one EC2 box holding the web server, database and uploads, with deploys done by copying theme files over SSH. The change that mattered most was making the site an immutable image. Cloud Build bakes the platform, plugins and theme, and it rolls onto Cloud Run. A plugin change became one line in a manifest plus a rebuild, so you always know what is running and can roll back. Staging redeploys on every push and production needs approval.
It does not fix a vulnerable plugin, but it removes the drift that makes updates feel risky, which is often why they get skipped.
Did the comments change your mind at all about taking WordPress maintenance work?