Cum am trecut un plugin de backup pentru Backblaze B2 prin furcile caudine ale review-ului WordPress.org

Am vrut o alternativă simplă și moka pentru backup-ul site-urilor WordPress direct în Backblaze B2, așa că mi-am scris propriul plugin și l-am publicat pe GitHub. Săptămâna trecută a fost în sfârșit aprobat în directorul oficial WordPress.org după trei rânduri de feedback destul de dur. Dacă ai vrut vreodată să publici un plugin acolo, povestea asta o să-ți salveze câteva zile bune de frustrări și refuzuri.

De ce Backblaze B2 și de ce alt plugin?

Există monștri ca UpdraftPlus, dar sunt greoi, plini de reclame de tip upsell și variante pro. Eu aveam nevoie de ceva lightweight pentru vreo 12 site-uri mici ale unor clienți, unde spațiul total nu sare de 50GB. B2 are primii 10GB moka, iar după aia costă doar 0.006$/GB.

Am scris pluginul în vreo două weekend-uri. Folosește WP-Cron pentru planificare, face o arhivă zip cu clasa ZipArchive din PHP și o urcă prin API-ul oficial Backblaze. Simplu, curat, fără brizbrizuri.

Trade-off-ul sincer? Dacă ai un site de 20GB, scriptul PHP o să crape din cauza limitărilor de max_execution_time pe shared hosting. Nu e un tool pentru mamuți, e gândit strict pentru site-uri de prezentare.

Coșmarul numit "WordPress.org Plugin Review"

După ce am terminat codul, l-am trimis la review. Știam că durează, dar a trecut fix o săptămână până când un reviewer voluntar a pus ochii pe el. Și de aici a început distracția. Prima respingere a venit instant. Chiar dacă ești senior și ai impresia că scrii cod curat, standardele lor de securitate sunt extrem de stricte, pe bună dreptate, la ce exploit-uri apar zilnic în WP.

Am avut de corectat trei probleme majore care mi-au întârziat aprobarea:

1. Lipsa validării de Nonce-uri. La fiecare salvare de setări (unde pui cheia de API Backblaze), trebuie să verifici manual wp_verify_nonce. Altfel, ești vulnerabil la atacuri de tip CSRF. Mie mi se părea evident că doar adminul are acces, dar regulamentul lor nu lasă loc de interpretări.
2. Sanitizarea vs Escaping. Nu e destul să faci sanitize_text_field când salvezi în baza de date. Ei cer să faci esc_attr sau esc_html în momentul în care afișezi setările înapoi în input-urile din admin. Chestia asta mi-a scăpat în două ecrane de configurare.
3. Prefixarea strictă. Toate funcțiile globale și clasele trebuie prefixate (de exemplu, bb2b_ de la Backblaze B2 Backup). Folosisem o clasă helper numită simplu S3_Helper pe care o reciclasem dintr-un proiect mai vechi. Mi-au respins pluginul pentru că risca să se bată cap în cap cu orice alt plugin care ar fi definit aceeași clasă.

Cum arată workflow-ul acum

După ce am rezolvat feedback-ul în 24 de ore, pluginul a fost aprobat și am primit acces la repo-ul lor SVN. Pentru că urăsc SVN-ul din tot sufletul, am configurat un GitHub Action care face push automat în SVN-ul WordPress.org de fiecare dată când fac un release pe GitHub.

Am economisit cel puțin 30 de minute la fiecare release mic pentru că nu mai trebuie să butonez manual prin terminal cu tool-uri arhaice.

Concluzia mea? Merită efortul de a trece prin review-ul lor doar dacă vrei expunere organică în dashboard-ul de WordPress al utilizatorilor. Dacă ai doar un tool intern pentru clienții tăi, ține-l pe GitHub și instalează-l ca .zip.

Voi ați trecut vreun plugin prin procesul ăsta recent? Cât a durat review-ul?