Forem: Kushang Tailor

How I Secured WordPress Media Files by Building My Own Upload Restriction Plugin

Kushang Tailor — Wed, 29 Apr 2026 05:52:53 +0000

How I Secured WordPress Media Files by Building My Own

Upload Restriction Plugin

Security is one of those things you don't think about deeply
until something breaks badly.

For me, that moment came while managing multiple high-traffic
WordPress websites. Sites that were running fine — until they
weren't. Slowing down. Getting unstable. Eventually crashing.

The culprit? Unrestricted file uploads.

The Problem — What Was Actually Happening

WordPress is flexible by nature. And that flexibility, if left
unchecked, can become a serious vulnerability.

On high-traffic sites, users interact with forms, media
uploaders, and search inputs constantly. Even with proper input
escaping and sanitization in place, there are edge cases —
scenarios where those defenses don't fully catch what's coming
through. And attackers know this.

Here are the real attacks that happen when file upload
restrictions are weak or missing:

1. Malicious Script Uploads (.php, .exe, .sh)

An attacker uploads a file with a .php or .sh extension through
a form or a vulnerable media endpoint. Once that file lands on
your server, it can be executed remotely — giving the attacker
full control over your WordPress installation. This is called
Remote Code Execution (RCE) and it's one of the most dangerous
attacks on any web server.

2. SVG-Based XSS Attacks

SVG files are XML-based and can contain embedded JavaScript.
When a malicious SVG is uploaded to your media library and
rendered in a browser, that JavaScript executes — allowing
attackers to steal session cookies, hijack admin accounts, or
redirect users to phishing sites.

3. Web Shell Uploads

Attackers disguise a web shell — a backdoor script — as an
innocent looking file. Once uploaded and accessed via browser,
it gives them a persistent, hidden entry point into your server
that survives even plugin updates and password changes.

4. XML & HTML File Injections

Uploading malformed XML or HTML files can trigger parser errors,
expose server information, or be used to inject content into
your site that search engines and users see — damaging your SEO
and your reputation.

5. Large & Unnecessary File Type Uploads

Even without malicious intent, allowing every file type creates
problems. Uploading high-resolution TIFFs, PSDs, or uncompressed
video formats bloats your server storage, slows down your media
library, and eventually crashes shared or underpowered hosting
environments.

On one of my high-traffic projects, the site was slowing down
week by week. No obvious code issue. No server misconfiguration.
Just the gradual accumulation of unnecessary and problematic
files finding their way into the media library — quietly
consuming resources until the site buckled.

The Existing Solutions — And Why They Weren't Enough

Yes, WordPress has some built-in MIME type checking. And yes,
there are security plugins that handle broad firewall rules.

But I needed something specific, simple, and surgical. I didn't
want a bloated security suite. I wanted one thing — the ability
to precisely control which file extensions and MIME types are
allowed to be uploaded to my WordPress sites. Nothing more,
nothing less.

I searched. I couldn't find exactly what I needed.

So I built it.

The Solution — Restrict WP Upload Type

I built and published the Restrict WP Upload Type plugin on
WordPress.org.

The concept is straightforward: give site administrators full,
granular control over which file extensions and MIME types are
permitted in the WordPress Media Library — and block everything
else.

👉 View the plugin on WordPress.org

What the Plugin Does

The plugin provides a clean settings panel inside your WordPress
admin where you can:

Allow or disallow any file extension — choose exactly which file types your site accepts
Control MIME types precisely — not just extensions but the actual MIME type validation, making it harder to spoof
Access 96 file extensions and MIME types — covering images, documents, audio, video, code files, archives, and more
Restrict SVG uploads — one of the most commonly exploited file types in WordPress, now fully controllable
Apply rules globally — restrictions apply across the media library, upload forms, and any standard WordPress upload endpoint

Real-World Use Cases

Here's how different types of sites can use this plugin:

WooCommerce stores — Allow only JPG, PNG, PDF and block
everything else. Prevent customers or vendors from sneaking
executable files through product upload forms.

Portfolio or agency sites — Block PSDs, TIFFs, and RAW
files that designers sometimes accidentally upload, keeping
your server storage clean.

Membership or community sites — Restrict uploads to safe
document formats only. Block PHP, SH, EXE, and all script
file types entirely.

Corporate websites — Allow only PDF and DOCX for document
uploads. Block all image formats if image uploads aren't
needed at all.

What I Learned Building This

The most interesting technical challenge was working with
WordPress's upload_mimes filter and wp_check_filetype_and_ext
function. WordPress does its own internal MIME validation, and
overriding it cleanly — without breaking legitimate uploads or
conflicting with other plugins — required careful handling.

I also learned that MIME type spoofing is more common than
most developers realize. An attacker can rename a .php file
to .jpg and attempt to upload it. That's why checking only the
file extension is never enough — you need to validate the actual
MIME type of the file content, not just what the filename claims
to be.

The plugin handles both layers.

The Result

The plugin currently has 300+ active installations on
WordPress.org, a perfect 5-star rating, and has been
tested up to WordPress 6.7.5. It's been live since April 2022
and has remained stable across multiple WordPress versions.

One reviewer described it as "simple, fast and objective."
Another said it "works like a charm."

A particularly useful piece of feedback from a user highlighted
the need to better communicate which plugin blocks an upload
when the restriction triggers — something I've noted for a
future update.

⚠️ One Thing to Keep in Mind — Plugin Conflicts

While the plugin works reliably across most WordPress setups,
there is one scenario worth being aware of.

If another active plugin on your site — such as Elementor,
Divi, or any page builder / media-heavy plugin — also hooks
into WordPress's MIME type functions internally, it may
conflict with this plugin's restrictions.

This happens because multiple plugins are trying to control
the same WordPress filter (upload_mimes) at the same time,
and they can override each other depending on the order they
load.

How to check for this:

After activating the plugin and saving your settings, try uploading a restricted file type
If the restriction doesn't work as expected, temporarily deactivate other plugins one by one to identify the conflict
Re-activate them and check which plugin is overriding the MIME type settings

This is not a bug — it's simply how WordPress plugin
architecture works when multiple plugins touch the same hook.
Being aware of it will save you debugging time and help you
use this plugin more effectively on complex setups.

The Takeaway

If you're running any WordPress site with user-facing upload
functionality — forms, media libraries, WooCommerce product
uploads, membership portals — you should be controlling exactly
what file types are allowed in.

Sanitization and escaping are essential, but they are not
enough on their own. File type restriction is a separate,
dedicated layer of defense that too many WordPress sites skip.

Don't wait for a crash to find out why.

👉 Restrict WP Upload Type on WordPress.org

Have you ever dealt with a file upload attack on a WordPress
site? I'd love to hear how you handled it — drop a comment
below. 🔒

How I Became a Developer and Why? — My 9-Year Journey

Kushang Tailor — Tue, 28 Apr 2026 05:06:11 +0000

From Data Entry at a CA Office to Senior WordPress Developer — My 9-Year Journey

I didn't start my career in front of a MacBook with a cup of
coffee, writing clean code in a cozy home office.

I started in a textile market, standing 12 hours a day, earning
₹3,000 a month.

This is my honest story — the struggles, the fake promises, the
wrong turns, and how WordPress changed everything for me.

Chapter 1: The Textile Market — Where It All Began

After my SSC exams, there were a few months before results came
out. I needed money. So I took up work in the textile market in near by area.

For those who don't know — Gujarat is one of India's largest textile hubs. And the people who keep it running work incredibly hard. I'm talking 12 to 18 hour shifts, six or seven days a week, in hot, loud, and physically exhausting environments. The workers who load, unload, sort, and manage fabric rolls earn somewhere between ₹3,000 to ₹8,000 per month — with no paid leave, no sick leave, no fixed hours, and certainly no work-from-home option.

I was earning ₹3,000 a month. For 12 hours of work every day.

That's roughly ₹8 per hour.

I wasn't complaining — it was honest work and it taught me
discipline. But I knew this wasn't the life I wanted. I knew
there had to be another way.

Chapter 2: The Dream of a Degree — And Why I Let It Go

When my SSC results came, I passed. I was eligible to apply for a BE degree through the diploma-to-degree route. That was the
"expected" path — get a degree, get a stable job.

But my financial situation at home made that impossible.
Engineering fees, books, travel — it wasn't happening.

So I made a different choice. I enrolled in an Android
Development course for ₹12,000. It wasn't a degree. But it was
a skill. And I believed skills could open doors too.

What IT taught me later: In the tech world, nobody asks
where your degree is from. They ask what you've built. Your
GitHub, your portfolio, your live projects — that's your real
resume.

Chapter 3: Data Entry by Day, Android by Dawn

To pay for the course, I joined a CA office as a full-time data
entry operator. My stipend was ₹7,000 per month.

My daily routine looked like this:

Early morning — Android development classes
All day until 7–8 PM — Data entry at the CA office
Night — Study, practice, repeat

Data entry work is underrated in how mentally demanding it is.
You need to be precise, fast, and consistent — for hours on end.
I also picked up accounting work using Tally, which added more
responsibility to my plate.

I was good at it. My speed improved. My accuracy was solid.

But here's the hard truth about this career path — salary growth
is painfully slow. Even in well-established banks and finance
firms, the reality is difficult. A bank clerk or junior
accountant in India earns roughly ₹15,000 to ₹25,000 per month.
A bank manager might earn ₹50,000 to ₹80,000 — but only after
10 to 15 years of service, late night shifts in some branches,
and very rigid working hours. There is no remote work. There is
no flexibility. And the ceiling is always visible from where you
stand.

I paid my entire ₹12,000 course fee in EMIs from my data entry
salary. Every month, a piece of my stipend went toward buying
myself a better future.

What IT taught me later: In tech, salaries can grow 3x to
5x within the first five years alone — based on your skills, not
your seniority years. A senior developer today earns what a bank
manager takes decades to reach.

Chapter 4: The Fake Course — The Hardest Lesson

After completing the Android development course, the institute
had promised job placement. That was part of the deal.

They didn't deliver.

I pushed myself. I traveled outside my city for interviews — as
a fresher, with no experience, competing against candidates from
engineering colleges. I gave multiple interviews. I learned from
each one.

But the institute had made commitments they were never capable
of keeping. The "placement support" was practically non-existent.
No real industry connections. No resume guidance. No interview
preparation. Just hollow promises made to sell a course.

This is a reality that thousands of students across India face
every year. Coaching institutes and private training centers
often market themselves with big claims — "100% job guarantee",
"placement in top companies" — but deliver very little. They
collect the fees, run a basic course, and when it comes to
actually finding you a job, you're on your own.

I had paid ₹12,000 — money I had earned through months of early
mornings and long workdays — and I had nothing to show for it
professionally.

It was a frustrating and expensive lesson. But it also forced me
to take control of my own career. Nobody was going to hand me a
job. I had to find it myself.

Chapter 5: ₹4,000 a Month and a Bet on WordPress

In 2017, I found a web development company willing to take me
as a fresher.

The stipend was ₹4,000 per month.

Less than what I was earning in data entry. Less than what I
made in the textile market.

But I took it — because I saw the future clearly.

Within 3 months, my dedication was noticed and my salary was
increased to ₹8,000 per month. Progress — but still not enough
to live comfortably.

So I did what most people wouldn't expect from a developer —
I signed up as a Swiggy delivery partner.

Yes, after coding all day, I was delivering food orders in the
evening. And honestly? The money was good. Better than my
development stipend at the time. Swiggy delivery in a busy city
like Surat can earn you ₹15,000 to ₹25,000 per month depending
on your hours and orders — so it genuinely helped me stay
financially stable during a critical phase of my learning.

But after 2 to 3 months, I made a decision that changed
everything. I quit the Swiggy job completely.

Not because it was bad money. But because I realized I was
splitting my energy at exactly the wrong time. The evening hours
I was spending on deliveries were hours I could spend practising
code, building projects, and growing faster as a developer.
Short-term comfort was slowing down my long-term growth.

I quit. I went all in on web development. And I never looked back.

Here's why web development made sense to me and still does in
2026:

Salary growth is real and fast. A fresher web developer in
India starts at ₹10,000 to ₹20,000 per month. Within 3 years,
a skilled developer can earn ₹40,000 to ₹80,000. Senior
developers and specialists working with global clients can earn
₹1,00,000 to ₹3,00,000+ per month — or the equivalent in USD
working remotely.

Remote work is a reality. The job I do today, I can do from
my home, from a café, or from another country entirely. No
commute. No rigid office hours. No standing for 12 hours in a
warehouse.

The work culture is different. 8-hour workdays are standard.
Paid leaves, sick leaves, and casual leaves are normal. Many
companies provide hardware support — laptops, monitors,
peripherals — so you don't need to invest your own money to do
your job. Some even provide internet allowances.

Skills compound over time. Every project I do makes me
better at the next one. In data entry, doing more data entry
just made me faster at data entry. In WordPress development,
learning PHP leads to WooCommerce. WooCommerce leads to plugin
development. Plugin development leads to React and headless
architecture. The learning never stops — and neither does the
income growth.

Where I Am Today

It's 2026. That ₹4,000/month fresher is now a Senior WordPress
Developer with 9 years of experience.

I've built and published plugins on WordPress.org. I've handled
data migrations, performance optimizations, WooCommerce
customizations, and headless WordPress projects. I work with
modern tools — React, Next.js, Tailwind CSS, Cursor AI — and
collaborate with global teams using Slack, Basecamp, and more.

The textile market taught me discipline.
The CA office taught me precision.
The fake course taught me self-reliance.
The Swiggy bag taught me that shortcuts don't exist —
only trade-offs.
And WordPress gave me a career.

If you're reading this from a similar background — a small town,
a tight budget, a job that doesn't feel like it's going anywhere
— I want you to know that the path isn't always straight. Mine
certainly wasn't.

But if you find the right skill and commit to it fully, the
direction changes.

Keep building. 🙌

How I Built a WooCommerce Plugin That Works With Every Page Builder

Kushang Tailor — Mon, 27 Apr 2026 13:14:47 +0000

The Problem I Noticed

When I was working on WooCommerce stores for my clients, I kept
running into the same frustrating issue — there was no good way
to create a fully customizable WooCommerce product category page
that worked across all editors.

Every solution I found was locked to a specific page builder.
Elementor users had one option. Gutenberg users had another.
SiteOrigin users were mostly out of luck. And if your client
used no editor at all — just plain shortcodes — forget it.

I thought: why should the editor choice limit what you can
build?

So I built the Product Category plugin — and published it
on WordPress.org.

What the Plugin Does

In simple terms, it lets you create a fully customizable
WooCommerce product category listing page — and it doesn't
matter which editor you or your client prefers.

It works with:

✅ Elementor — via a dedicated Widget with live preview
✅ Gutenberg / Block Editor — via its own custom React Block
✅ SiteOrigin — via a Widget
✅ WP Bakery / JS Composer — via Shortcode
✅ No editor / Classic editor — via Shortcode

One plugin. Every editor. No compromises.

Key Features

Here's what you can control right inside the plugin settings:

Set a custom title for your category listing
Show or hide specific product categories via dropdown
Choose from multiple category display styles
Set rows and columns for the layout grid
Sort categories by Name or Slug (ASC / DESC order)
Show or hide category descriptions
Show or hide pagination
Show or hide category thumbnail images
Add proper Alt tags to category images (for SEO & accessibility)

And the best part — with Elementor and Gutenberg, all of this
is live preview. You see changes in real time as you design.

The Challenge: Supporting Multiple Editors

The hardest part wasn't building the features — it was
architecting the plugin so that the same core logic could power
four completely different integration points.

Each editor has its own way of registering and rendering
components:

Elementor uses a Widget class that extends \Elementor\Widget_Base
Gutenberg uses register_block_type() with a block.json definition
SiteOrigin uses SiteOrigin_Widget
Shortcode uses WordPress's add_shortcode() function

The key decision I made was to keep the rendering logic
centralized in one function, and have each editor integration
simply call that function with its own set of parameters. This
way, a bug fix or a new feature only needs to be written once —
and all four editor integrations benefit immediately.

What I Learned

Building this plugin taught me a lot about how different
WordPress ecosystems actually work under the hood. Each page
builder has its own lifecycle, its own way of passing data, and
its own rendering context.

It also taught me the importance of backward compatibility.
The plugin has been live since 2019 and I've maintained it
through multiple WordPress versions — all the way up to WP 6.9.
Every update had to ensure existing users weren't broken.

And perhaps most importantly — it taught me to listen to
users. Features like pagination, Alt tag support, and the
Gutenberg block were all added based on real feedback from people
using the plugin in production.

The Result

The plugin currently has 200+ active installations on
WordPress.org, a 5-star rating, and has been stable through
7 years of WordPress updates.

👉 Check it out on WordPress.org

If you're a WooCommerce developer who's ever struggled with
editor compatibility, I hope this gives you some ideas. And if
you use the plugin, I'd love to hear your feedback!

Feel free to connect — I'm always happy to talk WordPress,
WooCommerce, or plugin architecture. 🙌