So You Want Your Extension Validated? A Field Guide to Surviving phpBB's Extension Review Process

Let's be honest about something the phpBB community doesn't say out loud often enough: plenty of good extensions die in validation, and plenty of them die for reasons that have nothing to do with bad code.

The Extensions Validation Team isn't a hostile gatekeeper. It's a small group of volunteers applying a style guide to a flood of submissions, and if you show up understanding how that process actually works, your odds improve dramatically. If you show up defensive, you'll learn nothing and your extension will rot in the queue. Here's the playbook.

Naming Isn't Cosmetic — It's Infrastructure

The vendor/extension naming convention isn't bureaucracy for its own sake. Your extension lives in ext/yourvendor/yourextension/, and that vendor name is your permanent identity in the ecosystem. Pick it like you mean it.

• Vendor names should be unique, lowercase, and stable. Don't grab something generic like "mods" or "forum" — you're squatting on namespace someone else needs.
• Extension names should describe function, not marketing. nicepostcounter beats superultimatepro every time.
• Check the Extensions Database before you write a line of code. Submitting a name collision is an instant, avoidable rejection.

The Validator Is Not Your Enemy

Here's the mindset shift: a validation ticket full of corrections isn't criticism of you as a developer. It's the cheapest code review you will ever get, performed by someone who has seen every way an extension can break a board.

The common rejection reasons are almost boringly consistent:

• Not using the DI container properly — instant service injection instead of new Object() scattered through your code.
• Template events instead of core edits — if you're telling users to modify core files, you've already failed.
• Hardcoded language strings — everything user-facing goes in a language file, full stop. US devs, note that your strings should be written for translation, not just English-only.
• Missing migrations — schema changes belong in proper migrations, not install scripts.
• SQL without the tools class — direct database access bypasses phpBB's abstractions and will get flagged every time.

None of these are subjective. They're in the documentation. Reading the extension rules twice before submitting once is the single highest-ROI hour in this entire process.

How to Respond to Feedback Without Torching Your Reputation

This is the part nobody teaches. When a validator posts a list of issues, your response options are basically:

1. Fix everything, thank them, resubmit.
2. Push back politely on specific points, with technical reasoning.
3. Argue that your way is fine, actually.

Option 3 has a 100% failure rate. Option 2 is legitimate — validators are volunteers and occasionally miss context, especially with unusual extension designs. But push back on the code, never the person, and never in a wall of text. "I used direct SQL here because the tools class doesn't support this query type — is there a preferred alternative?" gets a collaborative response. "This requirement is stupid" gets your ticket closed and your name remembered.

The phpBB community is smaller than it looks. The validators, the extension authors, the people answering questions on the forums — they're overlapping groups. A developer known for gracious responses to review feedback gets faster, more generous help on their next project. A developer known for flaming gets their next extension reviewed with a fine-tooth comb, fairly but thoroughly.

The Unwritten Rules

A few things that aren't in the official docs but absolutely matter:

• Support your extension after approval. An abandoned support thread is the fastest way to get your extension marked abandoned and delisted. Budget the time before you submit.
• Test against a clean install AND a board with popular extensions. Conflicts with the big ones — like common SEO or attachment extensions — surface in the wild, and catching them first is the difference between "supported" and "broken."
• Version your releases properly. Semver isn't optional, and "beta" releases with schema changes that change between betas will generate support chaos you created yourself.
• Don't resubmit to bump the queue. The team knows. They always know.

The Long Game

Yes, validation can take weeks. Yes, some rules feel pedantic until the day a poorly-written extension from 2019 takes down someone's production board and you understand exactly why the style guide exists.

The developers whose extensions become ecosystem staples — the ones admins install without a second thought — all went through the same queue, the same corrections, the same learning curve. The difference between them and the graveyard of abandoned mods isn't talent. It's patience and professionalism during review.

Write clean code, read the rules, thank your reviewers, and support what you ship. That's the whole secret.