Back to Engineering Logs

My Plugin Got Rejected 3 Times (And They Were Right)

5 min read
wordpress
security
open-source
My Plugin Got Rejected 3 Times (And They Were Right)

Twenty years writing code. Distributed systems, critical APIs… you name it. I thought uploading a plugin to the WordPress repository would be a 5-minute administrative formality.

Upload, wait for validation, done.

Well, no. It got rejected three times.

The frustrating part was that the code didn’t fail. Functionally, it was correct. But the review team kept sending it back due to sanitization issues or standards that I, at the time, considered secondary.

It stings at first. It hits your professional pride when a volunteer tells you your software is insecure after you’ve spent half a life doing this. You read the report and think: “Is it really necessary to escape this variable if it’s only visible in the admin panel?”

The answer is yes.

When you analyze the situation coldly, you understand why. WordPress is not your controlled local environment. It is a hostile ecosystem.

We are used to dedicated servers and controlled deployment pipelines. But a public plugin? It will end up installed on cheap shared hosting, running on obsolete PHP versions, and coexisting with dozens of other questionable quality plugins.

In that scenario, defensive security is not optional. It is a structural requirement.

The reviewers forced me to raise the bar. I learned (again) that an unescaped echo is an XSS vulnerability waiting to happen. That nonces are mandatory to validate the intent of every request, without exception. And that if you don’t prefix every function, you’ll end up causing fatal conflicts with other developers’ code.

Think of it this way: an external security audit costs thousands.

Here you have ecosystem experts reviewing your code line by line, for free, before you publish software that could compromise the security of thousands of websites. They aren’t being pedantic; they are protecting the user.

I had to rewrite a large part of the logic. It was a slow and rigorous process. But the final code is infinitely more robust and secure than the version I tried to publish on day one.

In the end, I owe them one. Thanks to those reviewers, my plugin is not just functional, but safe.

And that is what really matters.

From the Lab

This experiment was conducted by Ionastec. Need this level of technical rigor for your business?

Consult Ionastec