Am urcat un plugin de backup în Backblaze B2 pe WP.org: cum a fost review-ul

Am publicat recent un plugin gratuit pe wordpress.org care face backup automat la baza de date și fișiere direct într-un bucket Backblaze B2. M-am săturat să plătesc licențe anuale de 70$ pentru UpdraftPlus doar ca să trimit fișiere într-un cloud ieftin, așa că am decis să-l scriu de la zero și să-l fac open-source. În rândurile de mai jos povestesc ce am învățat din procesul de review și unde își atinge soluția limitele.

De ce Backblaze B2 și nu clasicul AWS S3?

La un client cu vreo 40 GB de imagini și PDF-uri, AWS S3 începea să coste nejustificat de mult din cauza transferurilor lunare. Backblaze B2 are un preț de 6$ pe lună per TB de stocare, iar primii 10 GB sunt gratis. Față de cei 23$ pe care îi cere AWS pentru aceeași capacitate, diferența se simte când gestionezi zeci de site-uri.

Problema clasică la implementarea asta e dependența de SDK-uri masive. Dacă bagi tot AWS PHP SDK într-un plugin WordPress doar ca să folosești compatibilitatea S3, umfli arhiva zip cu vreo 15 MB de vendor code. Am preferat să consum direct REST API-ul nativ de la Backblaze folosind doar funcțiile interne din WordPress. Zip-ul final are sub 180 KB, fără dependențe externe.

Dușul rece din procesul de review WP.org

Am trimis pluginul la review cu gândul naiv că în trei zile e pe director. A durat 26 de zile doar până l-a deschis cineva din echipă, iar apoi a urmat un schimb lung de mailuri.

Echipa de securitate de la WordPress e extrem de riguroasă și m-au respins la prima iterație pentru chestii pe care le treci ușor cu vederea la proiecte interne:

1. Foloseam $_POST fără wp_unslash() înainte de sanitizare. Dacă ai ghilimele sau caractere speciale, WordPress le adaugă slash-uri automat, iar fără unslash riști să salvezi chei API corupte în options table.
2. Făcusem un apel intern cu curl_exec() pentru a testa conexiunea rapid. Regula lor e de fier: folosești exclusiv wp_remote_post() sau wp_remote_get(), altfel pici testul pentru servere care rulează în rețele cu proxy.
3. Lipsea verificarea de capabilități (current_user_can('manage_options')) în funcția de AJAX care declanșa backup-ul manual. Verificam doar un nonce valid, dar nonce-ul în WP e gândit doar pentru protecție CSRF, nu pentru autorizare.

Trade-off-uri reale și unde crapă

Să fim cinstiți cu limitele arhitecturale: pluginul merge brici pe instanțe mici și medii. L-am testat pe un magazin WooCommerce cu o bază de date de 800 MB și backup-ul a durat 4 minute pe un VPS modest cu 4 vCPU.

Dar dacă ai un site cu peste 10 GB de uploads pe un shared hosting ieftin, abordarea asta nu e potrivită. PHP timeout-ul standard de 30 de secunde și limita de memorie de 128 MB te blochează rapid dacă încerci să arhivezi fișiere uriașe din interfața web. Nu am implementat încă un sistem complet de background workers cu streaming asincron. Pentru site-uri gigantice, un cron de sistem cu un script Bash și B2 CLI e de zece ori mai stabil decât orice script PHP rulat prin WP-Cron.

Codul e public pe GitHub sub licență GPLv2. Pentru mine a fost un exercițiu excelent de scriere curată de cod conform standardelor WordPress. Voi cum rezolvați backup-urile pe magazine medii: vă bazați pe cron de server sau lăsați aplicația să se descurce?