I submitted SwiftLing to the WordPress.org plugin directory on 23 October 2026, and it was approved on 28 October. The review came back with a list of security and coding points, and fixing them took one pull request. This post lists what they found and what I changed, for anyone who is about to submit a plugin.
Short answer
- The automated check flagged unsanitized input, unescaped output, a translation function without a text domain and a false positive about a bundled library.
- I fixed the input and the output at the place where they are read and printed, and added a test that fails if the problem comes back.
- Plugin Check reported 0 errors and 19 warnings on the new package, the same as before.
What they found
- Input that was not sanitized. A draft of a support request was saved from the request as it came, and the path and request address were used while building slugs. I now sanitize each value where I read it.
- JSON printed with its escaping switched off. I had printed some JSON into script elements with flags that leave characters as they are. Output printed inside a script element is the place where the escaping matters most.
- The language switcher printed its HTML without escaping. The switcher can be changed by a filter, so its output went through no check. I now pass it through
wp_kseswith a list of the HTML the switcher may contain. - A
_nxcall without a text domain. A translation function needs the domain, or the text cannot be translated. - A class flagged as a bundled library. It was my own class for Advanced Custom Fields, and it only looked like a library from outside. This is a false positive, and it stayed on the review as a note that does not block.
What I changed
- Sanitize on input, escape on output. Every value is cleaned where I read it, and every value is escaped where I print it, with the function that fits the place: text, attribute, address or HTML.
- No suppressions. The code had no suppression comments for these checks, except one for the JSON I print into a script element, where the data is built by
wp_json_encode. - A test that scans the source. A test reads the plugin’s files and fails if an unsanitized read or an unescaped print appears again. A rule that depends on people remembering fails in time, and a test does not.
- Admin icons. The icons of the admin screens go through one list that allows only the SVG tags the icons use.
What I learned
- Read the checklist of the review before you write the code, not after. The points are the same for every plugin.
- Prove that your fix did not break anything. My switcher’s output now passes
wp_kses, and I checked that the markup of SwiftLing Pro’s currency still passed it. - Build the package from the files you track, not from your working folder. A hidden folder of tool settings would have ended up in the package.
- Answer in the same thread, briefly. The reviewers want to know what you changed, not a story.
What the review did not do
A passed review is about the directory’s rules, not about whether the plugin works well. I tested SwiftLing with many page builders and form plugins, and I write about each of them on this blog.
Questions
How long does the WordPress.org plugin review take?
SwiftLing was submitted on 23 October and approved on 28 October, five days. The queue and the answer time vary.
What does the review check?
Security, such as sanitizing input and escaping output, the licence, the use of text domains, the plugin’s name and ownership, and files that should not be in a plugin.
Can I run the checks before I submit?
Yes. The Plugin Check plugin runs most of them on your own site.
Last updated 29 October 2026. SwiftLing 1.0.3.