📼 It Started With WordPress 4.7
I still remember the version number: WordPress 4.7. That's when I properly started my journey as a WordPress developer. Not as a "I read a tutorial and now I'm an expert" kind of start — more like a "I broke a client's site three times before lunch" kind of start.
Those were good years, honestly. I built a lot of sites. Small business sites, portfolio sites, e-commerce stores. But there was one problem that followed me across almost every single project, like a background process that never quits: the media library.
Sites would crash. Uploads would eat up server resources. And every now and then, out of nowhere — the dreaded white screen of death, right after someone in the client's team uploaded "just one more file."
🩹 The Debugging Loop I Knew Too Well
Every time this happened, I went into the same routine. Open the error logs, check the wp-content/uploads folder, check PHP memory limits, and dig line by line until I found the culprit.
And more often than not, the answer was almost embarrassingly simple:
- A corrupt file that somehow made it through upload
- A heavy media file nobody bothered to compress
- Someone uploading a .exe or .zip disguised as an image — sometimes by mistake, sometimes not
None of these were WordPress core problems. They were upload hygiene problems. But WordPress, out of the box, doesn't really give site owners a simple way to say "only allow these file types, nothing else." So every time, I'd write a quick one-off fix for that one client, ship it, and move on. It solved the symptom. It never solved the actual disease.
Now, to be fair — the White Screen of Death isn't only caused by bad uploads. Over the years I've seen it come from all sorts of directions: a plugin conflict, a theme function throwing a fatal error, PHP memory limits being exhausted, a corrupted .htaccess file, or even a simple PHP version mismatch after a server update. Uploads were just the culprit I kept running into the most.
🚀 New Job, New Plugins, New Skills
Time moved on, and so did I. I switched companies, and with the new job came new opportunities — this time, actual plugin and theme development work, not just "fix this WordPress site" freelance gigs.
This is where I really understood how plugins and themes are built from the ground up. I started building plugins for clients and for in-house company websites, and eventually shipped my very first personal plugin on WordPress.org — Product Category.
That first release taught me a lot: how WordPress.org review works, how real users behave differently than you expect, and how a plugin is never really "done" — it just moves into its next version.
💤 The Idea That Came During a Nap
Here's the part of the story I still find funny. In early 2022, I was taking a short 10-minute nap — the kind where your brain refuses to fully switch off. And in that half-asleep state, old memories started resurfacing. Corrupt uploads. Wrong file extensions. Clients accidentally uploading a .zip where an image was supposed to go. Years of the same recurring headache, replaying like a highlight reel.
And then the thought hit me:
"What if there was one simple plugin where a site owner could just check which file types are allowed — and everything else gets blocked automatically?"
No more one-off fixes per client. No more custom snippets copy-pasted from an old project. Just one clean toggle-based settings screen.
That nap turned into a plan.
🧩 Planning Before a Single Line of Code
I didn't jump straight into the editor. I sat down and actually mapped out the plugin — what file types needed support, how the settings screen should look, how validation should happen both on the frontend and the server side (because client-side checks alone are basically decorative).
After the research phase, I started building. Following pure OOP structure, keeping things aligned with WordPress coding standards, and making sure every single input was properly sanitized, validated, and escaped — non-negotiables for me, then and now.
🐛 "It Worked Locally... So Why Is Production Rejecting Everything?"
After a solid months of development, the plugin was functionally complete. Time for testing.
I ran it on a few local environments first — smooth. Then I moved it to some live production sites for real-world testing, and that's when things got interesting: uploads stopped working entirely. Every single file, blocked. Media library, dead silent.
My first reaction was pure confusion — it worked perfectly on local, so why was production behaving like it had personally decided to reject every file on Earth?
I dug in. Checked hooks, checked filter priorities, checked MIME validation order. Eventually I traced it back to a plugin conflict — another plugin on those production sites was hooking into the same upload filters, and the two were essentially fighting over who gets the final say on what's "allowed."
So I went back in, added new compatibility functions, and reworked the restriction logic to play nicely with other plugins instead of assuming it owned the upload pipeline alone. Retested. This time — it worked like a charm.
🎉 Launch Day: April 2022
After that final round of verification, I published Restrict WP Upload Type on WordPress.org in April 2022.
If you check the plugin today, it does exactly what that half-asleep idea imagined:
- Control over 97 file extensions and MIME types
- A simple allow/block toggle for each format
- A dedicated SVG security toggle, since SVGs need special handling
- Real-time validation that blocks bad uploads before WordPress even shows its generic error
- A global file size limit
- Zero configuration complexity — install, check some boxes, done
⭐ What the Reviews Taught Me
Shipping the plugin wasn't the finish line — it was the starting line for actually listening. The plugin currently sits at a clean 5-star average across its reviews, and every one of them nudged the roadmap in a real direction.
One review praised how simple and effective the restriction logic was. Another user pointed out something I hadn't considered — they wanted the Restrict Files menu tucked inside the Media menu instead of sitting on its own, and asked for a clearer message telling users which plugin blocked their upload, so support requests wouldn't turn into a guessing game. Another review flagged a rough patch where settings weren't saving properly for one specific site.
I took all of it seriously. Over the following versions, I:
- Moved the settings page under Media > Restrict Files, exactly as requested
- Added a global max file size control
- Made the blocked-upload message fully customizable, so site owners can explain exactly why a file was rejected
- Improved validation so it runs before WordPress's generic security error even shows up
- Added a settings search and enabled/disabled filters, since scrolling through 97 file types isn't fun for anyone
- Tightened up nonce protection and added a proper uninstall cleanup routine
Four reviews might not sound like a lot on paper, but each one represented a real site, a real workflow, and a real reason to keep improving.
🔮 What's Next
The plugin has grown a lot since that April 2022 launch — from a one-page toggle screen to a proper settings experience with search, custom messaging, and file size controls. But I'm not done.
Next on the roadmap: deeper role-based restriction controls, so different user roles can have different upload permissions instead of one global rule for everyone — along with custom MIME type management and upload logs, so site owners get more visibility into who's uploading what.
It's a small plugin in the grand scheme of the WordPress ecosystem. But it came from a real, recurring frustration — and honestly, that 10-minute nap in early 2022 might be one of the more productive naps of my career.
If you manage WordPress media libraries and have ever stared at a white screen after someone uploaded "just one file," you can find Restrict WP Upload Type on WordPress.org.
Top comments (0)