Vastgehouden
Je WordPress-plugin wordt vastgehouden: wat elke afwijzingsreden echt betekent
De e-mail van het reviewteam is met opzet kort en vaag. Dit is wat elke reden echt betekent, wat hem veroorzaakt, en wat het werkelijk vlottrekt.
Je hebt een plugin ingediend bij wordpress.org. Twee weken later komt er een e-mail van plugins@wordpress.org dat je plugin is vastgehouden om de volgende redenen, gevolgd door drie of vier korte alinea's die klinken alsof ze voor zich spreken, en dat niet doen.
Ik heb die e-mail gekregen. Twee keer, op dezelfde plugin, om twee verschillende redenen. Hierna staat wat elke reden echt betekent — inclusief de twee dingen die ik fout deed en met weken wachten betaalde.
Blijf niet aandringen
Hun e-mail zegt het, en het klopt: statusverzoeken vertragen de wachtrij. Een review duurt één tot zes weken. Er is geen spoedprocedure.
Ga niet in discussie
Het reviewteam is geen helpdesk waarmee je onderhandelt. Elke minuut uitleggen waarom jouw geval anders is, is een minuut niet corrigeren.
Plak de e-mail die je kreeg.
Het reviewteam schrijft in het Engels, welke taal je ook spreekt. Plak hun bericht: deze pagina vertelt je met welke van de zeven redenen je echt te maken hebt — en wat elke reden van je wil.
Draait volledig in je browser. Er wordt niets verstuurd, niets bewaard, er zit geen server achter.
Eerst: hoe de review echt werkt
- 01
Ze bekijken elke keer alles opnieuw
Ze vergelijken je nieuwe inzending niet met de vorige. Een probleem dat de eerste keer niet werd genoemd, kan bij de tweede ronde opduiken — en een uitgebreide changelog in je antwoord is verspilde moeite.
- 02
Ze lezen de broncode
Niet alleen de readme, niet alleen de headers. Een controle naar een minder opvallende plek verplaatsen of een functie hernoemen werkt niet, en maakt van een technisch bezwaar een vertrouwenskwestie.
- 03
Hun e-mail is met opzet kort
Ze verwerken een enorme wachtrij met vrijwilligers. Elke bijzin telt — herlees hun e-mail daarom als aparte ronde, zin voor zin, als je denkt klaar te zijn.
De zeven redenen
Kies degene die bij jouw e-mail past. Elke kaart leidt naar wat hem veroorzaakt en naar wat er wel doorkomt.
Guideline 5, de „trialware”
Plugins mogen geen functionaliteit beperken die volledig op de eigen installatie van de gebruiker draait.
Wat hem veroorzaakt
- Een functie die volledig op de server van de gebruiker draait, kunstmatig begrensd, met een betaalde laag om hem te ontgrendelen
- Het schoolvoorbeeld: een modus „gebruik je eigen API-sleutel” begrensd op N keer per maand — de gebruiker levert de sleutel, de gebruiker betaalt de aanbieder, de berekening kost jou niets
- Let op wat níet het probleem is: geld vragen mag, een Pro-versie hebben mag
Wat er doorkomt
- Haal de limiet weg van alles wat lokaal draait
- Verplaats de functie naar de server, op eigen kosten — dan weerspiegelt de limiet een echte uitgave, en Guideline 6 staat dat uitdrukkelijk toe
- Verkoop support, updates of een gehoste dienst — alles behalve het ontgrendelen van code die al bij de gebruiker draait
Wat echt werkte, en mij verraste
Mijn eerste oplossing hield de lokale modus en haalde alleen de limiet weg, naast een nieuwe beheerde dienst. Dat was conform. Het was ook lastig uit te leggen, want een reviewer moest twee codepaden beoordelen en mij op mijn woord geloven over welke de prijs gold.
De versie die erdoor kwam verwijderde de lokale modus volledig. Is er geen lokale code, dan geldt Guideline 5 helemaal niet. Een eenvoudige conformiteitspositie wint van een verdedigbare.
Orde van grootte: dit is geen patch. Voor mij betekende het een hele modus schrappen, een Cloudflare Worker opzetten met mijn eigen API-sleutel, licentie-webhooks met handtekeningvalidatie aansluiten, quota per installatie toevoegen en het hele generatiepad herschrijven. Het antwoord kennen kostte een uur. Het opleveren dagen.
Naam- en merkbotsing
niet alleen in de naam — dit omvat … de URL's van deze plugin
Wat hem veroorzaakt
- De weergegeven naam, de slug, het text domain, de Plugin URI, elke link in je beheerscherm, de readme, de contributor-gebruikersnaam en het domein zelf
- Een conflict buiten WordPress: niet-verwante technologieprojecten, GitHub, npm, SaaS-producten, merkenregisters
- Een vervangende naam die aantoonbaar niet van jou is — toestemming van de andere eigenaar lost niets op
Wat er doorkomt
- Een puur beschrijvende naam kan met niemands merk botsen
- Het veiligst: neem de beschrijvende helft van hun eigen voorstel en laat het kenmerk weg — zij schreven het, dus misleidend kunnen ze het moeilijk noemen
- Zet je terugvaloptie in dezelfde e-mail, anders koop je nog een ronde van één tot zes weken
- Controleren of een slug vrij is: api.wordpress.org/plugins/info/1.2/?action=plugin_information&request[slug]=JOUW-SLUG geeft „Plugin not found.” als hij beschikbaar is
Drie hernoemingen die een schoon verklaarde grep overleefden
De naam doorbroken door een HTML-tag. Mijn sitelogo stond als Plug<span class="dot">Forge</span>. Geen zoekopdracht op de volledige naam vindt dat — en het was het meest zichtbare element op elke pagina.
Een nóg oudere slug. Tientallen links wezen nog naar de eerste naam van de plugin, twee hernoemingen eerder losgelaten, inclusief de belangrijkste knop. Zoek naar elke dode naam, niet alleen de laatste.
Wat er over het netwerk uitgaat. Een achtergrondworker stuurde de oude naam in zijn User-Agent naar elke externe site die hij aanraakte. Onzichtbaar op het scherm, volstrekt reëel voor de ontvangende servers.
De Contributors-regel
Wat hem veroorzaakt
- De houder van het indienende wordpress.org-account staat niet in de Contributors:-regel van de readme
- Wordt vaak juist gemist omdat de regel al bestaat met andere namen erin — een frameworkauteur, een facturatie-SDK — en dus niet leeg oogt
Wat er doorkomt
- Zet de gebruikersnaam van het indienende account in Contributors:
- Los je ook een merkkwestie op, controleer die regel dan ook: een contributor-naam op basis van de afgewezen naam spreekt de hele hernoeming tegen
Kapotte Plugin URI
Wat hem veroorzaakt
- De URL geeft een 404 — technische fix
- De URL bevat nog de botsende naam — dat is een merkprobleem, zie reden 02
- De URL wijst naar de homepage van je bureau in plaats van naar deze plugin specifiek
Wat er doorkomt
- Controleer live, niet in het bestand: een URL die je in de broncode corrigeerde maar nooit publiceerde blijft een afwijzing
- Open voor je antwoordt echt elke URL die je inzending bevat
Ongedocumenteerde externe diensten
Wat hem veroorzaakt
- Een uitgaande aanroep die niet in een External Services-sectie van de readme staat: wat wordt verstuurd, wanneer en naar welke aanbieder
- Een beschrijving die niet meer klopt met de ingediende code — erger dan geen beschrijving, want het leest als verhulling en niet als vergissing
Wat er doorkomt
- Schrijf die sectie als laatste, als je architectuur niet meer beweegt
- Controleer dat de privacyverklaring waarnaar je vanaf daar linkt hetzelfde zegt
- Noem elk endpoint dat de plugin echt aanroept, op het domein dat hij echt aanroept
Degene die er bijna doorheen glipte
Mijn privacyverklaring zei nog dat de plugin de URL van een afbeelding verstuurde, lang nadat de code was overgestapt op het versturen van de afbeelding zelf. Twee officiële documenten die elkaar tegenspreken over wat de server van de gebruiker verlaat, is precies het soort afwijking waarvoor deze sectie bestaat. Ik vond het een uur voor de herindiening, bij een laatste ronde, toen al het andere al schoon was verklaard.
Een secret meegeleverd in de publieke ZIP
Wat hem veroorzaakt
- Sommige licentie-SDK's schrijven een secret in platte tekst in je hoofdbestand — de gegenereerde code zegt dat soms zelf, in een commentaarregel
- Een met de hand gemaakte ZIP in plaats van een met het buildgereedschap van de SDK, dat het secret automatisch verwijdert
Wat er doorkomt
- Bouw je je archief zelf: pak het uit en grep het voor je uploadt
- Tien seconden controle tegen een fout die na publicatie onomkeerbaar is
„Deze categorie is vol”
Wat hem veroorzaakt
- Een opmerking dat je categorie verzadigd is — dit is geen conformiteitspunt en blokkeert de goedkeuring op zichzelf niet
Wat er doorkomt
- Antwoord met een verifieerbaar technisch verschil, niet met een marketingclaim
- Weersta „beter dan X”: het is niet te weerleggen, en een reviewteam dat het leest vertrouwt de rest van je inzending minder
Hoe je antwoordt
Hun instructie is het waard om letterlijk te volgen: hou het kort en som je wijzigingen niet op. Ze bekijken alles opnieuw vanaf nul, dus een changelog is ruis.
- De bevestiging van wat er is veranderd, in een of twee zinnen — de positie, niet de diff
- Bij een hernoeming een uitdrukkelijk verzoek om de nieuwe slug te reserveren — uit zichzelf doen ze dat niet
- Je terugvaloptie, als er twijfel is
Upload de gecorrigeerde versie via de pagina „Add your plugin”, ingelogd op het indienende account — niet als bijlage bij een e-mail. Een pagina op make.wordpress.org uit 2015 zegt iets anders; die is verouderd. De „Text Domain”-waarschuwing bij het uploaden is normaal tot je slug is gereserveerd.
De lijst die ik doorloop voor elke herindiening
Elke regel komt voort uit een punt dat ik fout deed. Vink ze af — je browser onthoudt het.
Die laatste regel telde het zwaarst: dertien leesrondes over mijn eigen code misten drie blokkerende bugs, en elk daarvan kwam boven in de eerste vijf minuten echt uitvoeren. Je leest code om te vinden wat fout is. Je voert hem uit om te vinden wat ontbreekt.
Wat dit werkelijk kost
Voor een gewone conformiteitsfix — documentatie, headers, contributors, URL's — is een paar uur realistisch.
Bij Guideline 5: wees eerlijk tegen jezelf. Je verandert het verdienmodel van je product en bouwt waarschijnlijk serverinfrastructuur die je niet had. Tussen mijn eerste afwijzing en de laatste herindiening zaten negen dagen, twee afgewezen namen, één Cloudflare Worker, een webhookkoppeling en drie bugs die pas opdoken toen ik stopte met lezen en begon met uitvoeren.
De richtlijnen zijn niet willekeurig, en zodra je het patroon erachter ziet zijn ze consistent: de directory host vrije software die werkt, en alles wordt daaraan afgemeten.
Ik doe dit voor andere pluginauteurs: elk punt uit de afwijzingsmail afgehandeld, de nog niet genoemde richtlijnen ook nagelopen, en het antwoord geschreven zodat jij het alleen nog hoeft te versturen.