Devenia WordPress plugin guide

WordPress.org Plugin Review: A Practical Submission Checklist

A practical, lightly satirical guide to the WordPress.org plugin review process: queues, slug changes, Plugin Check, long emails, and what actually helps before approval.
Generated editorial image of blank checklist cards and a folder for plugin review preparation.

Prepare for the WordPress.org plugin review queue

So you built a WordPress plugin. Congratulations. Now you want to share it with the world through WordPress.org.

How hard can it be? Upload a zip file, wait a bit, done. Right? Not quite.

Reader decision

Have you run Plugin Check before submitting?
Do the plugin name, slug, folder, main file, and text domain match?
Are you ready to read the whole review email and wait through the queue?

What the review process usually looks like

The workflow has three practical phases: prepare the package, resolve review feedback, and repeat only the checks that changed.

Step 1: Prepare and submit

Run the checks, inspect the zip contents, confirm the plugin headers and text domain, and submit through the current WordPress.org process. Review time depends on queue length and follow-up work, so do not promise a fixed approval date.

Step 2: Read and resolve feedback

Read the full review message, separate required fixes from suggestions, make one coherent change set, and test the exact package you plan to resubmit. Keep a short change log so the next reviewer can see what changed.

Step 3: Repeat until the requirements are met

Approval is iterative when the package or documentation still has gaps. Treat each response as a concrete requirement, update the package, and re-check identifiers that depend on any renamed slug or folder.

Why review threads become hard to follow

The review emails can be a mix of automated messages, AI-generated suggestions, actual human feedback, other conversations, and documentation links.

They can also be thousands of words long, with nested quotes going back through the whole thread. The important bit may be buried deep in the email.

Common surprises

The slug dance: display name, slug, text domain, folder name, and main file name all need to line up.
Follow the instruction in the current review thread. If the required response path is unclear, ask one focused question rather than guessing or sending multiple unrelated replies.
The generic name trap: descriptive plugin names can be too generic for WordPress.org.
Plugin Check may expect one slug while the review thread points you toward another.
A 52-email thread can hide the actual change that matters.

What actually helps

Despite the chaos, the useful lessons are practical and repeatable.

Pick a unique name

Choose a branded name from the start, such as YourBrand Thing rather than a generic function name.

Keep identifiers matching

Folder name, main file name, slug, and text domain should all match. Do not get creative.

Read the whole email

The important instruction may be buried after automated text, AI suggestions, or quoted thread history.

Expect iteration

You may change plugin name, slug, text domain, folder, or file names more than once.

Treat review feedback as a process to work through, not as a single pass/fail event.

Why the process exists

Reviewers check code that may run on many sites, so the process focuses on security, licensing, privacy, and directory requirements.

What feels frustrating

  • Review time changes with queue length and follow-up work; check the current queue guidance before setting expectations.
  • The emails can be long, confusing, and sometimes contradictory.
  • A plugin that felt done at version 1.0 may need several review-specific updates.

What the review protects

  • Every plugin on WordPress.org could theoretically run on many websites.
  • One bad plugin can create a serious security or stability problem for site owners.
  • The process is trying to keep WordPress safer, even when the workflow is confusing.

Submission checklist

Before submitting, check the small details that create the most back-and-forth.

Plugin Check passes locally.
Plugin name is unique and branded enough.
Slug, folder, main file, and text domain match.
The review email has been read all the way through.
Documentation links and human feedback have been separated from automated noise.
If the review team changes the slug, re-check every identifier that depends on it.

Preparation does not remove the queue, but it reduces avoidable review loops.

Frequently asked questions

How long does WordPress.org plugin review take?

Review time varies with current workload and follow-up issues. Check the current WordPress.org guidance rather than promising a fixed number of weeks.

What causes repeated review loops?

Common causes include generic plugin names, slug changes, mismatched text domains, folder names, main file names, and missed instructions in long emails.

What should plugin developers do before submitting?

Run Plugin Check, choose a unique branded name, keep slug/folder/main file/text domain aligned, and read every review email carefully.

The TL;DR

The process can be confusing, but it eventually ends.

Expect WordPress.org plugin review to take weeks.
Expect name, slug, and text-domain changes.
Run Plugin Check before submitting.
Remember the reviewers are volunteers doing important work.

Submit a reproducible package, keep the identifiers aligned, and record every review change. That turns a confusing queue into a repeatable release process.