Salutare. Recent am reușit să public pe repozitoriul oficial WordPress un plugin la care lucram de ceva timp în timpul liber. E un instrument simplu care face backup bazei de date și fișierelor și le urcă direct în Backblaze B2. De ce am făcut asta? Pentru că m-am săturat de monștri precum Updraft sau Jetpack care îți cer bani pentru orice remote storage serios sau vin la pachet cu 50MB de dependințe inutile care încetinesc dashboard-ul.
Totul a plecat de la un proiect mic pentru un client cu vreo 12GB de imagini. Omul nu voia să plătească 100$ pe an doar pentru un addon de S3/B2, iar restul variantelor free de pe piață erau ori pline de reclame, ori pur și simplu nu funcționau pe servere cu resurse limitate. Am zis că e momentul să scriu ceva minimalist, curat și, mai ales, open-source.
Decizia tehnică: Fără SDK-ul oficial
Prima mare problemă a fost dimensiunea. SDK-ul oficial AWS sau cel de la Backblaze pentru PHP sunt enorme. Dacă le includeam direct, plugin-ul ar fi avut vreo 15-20MB. Am ales să scriu o clasă mică de API care folosește wp_remote_post și wp_remote_get. Am economisit cam 80% din dimensiunea finală a folderului. Plugin-ul meu are acum sub 300KB.
Dar distracția adevărată a început când am trimis codul la review pe WordPress.org. Dacă credeai că e suficient să meargă codul, te înșeli amarnic. Oamenii de acolo sunt draconici, și pe bună dreptate, având în vedere cât malware circulă prin ecosistem.
Cele 3 săptămâni de review și respingerile primite
Mi-au respins prima variantă în mai puțin de 48 de ore. Motivul principal? Prefixarea. Aveam clase de genul class B2Client. Mi-au explicat clar că într-un ecosistem unde rulează mii de plugin-uri, riscul de coliziune e uriaș. A trebuit să trec totul prin namespace-uri sau să prefixez fiecare funcție cu ceva unic, gen my_b2_backup_. E o muncă de chinez bătrân dacă nu ai făcut-o de la început, dar e vitală.
A doua respingere a venit din cauza securității. Folosisem $_POST direct pentru a salva setările în bază de date. Chiar dacă făceam cast la string, nu era suficient. Mi-au cerut să folosesc check_admin_referer() și sanitize_text_field() peste tot. E o greșeală de începător pe care o faci când scrii cod repede pentru tine, dar când livrezi pentru public, nu există scuze.
Challenge-ul cu fișierele mari
La un moment dat, am dat de zidul de 30 de secunde: Maximum execution time exceeded. Dacă încerci să uploadezi un zip de 2GB dintr-un singur request PHP pe un hosting partajat, site-ul crapă. Am rezolvat asta implementând un sistem de chunking (multi-part upload). Practic, sparg arhiva în bucăți de 5MB și le trimit una câte una, cerând serverului să „respire” între ele. Am testat pe un VPS ieftin de 5 euro și a urcat arhiva de 12GB fără să sughită deloc, deși a durat vreo 20 de minute.
Trade-off-uri sincere
Plugin-ul e bun pentru „Push to Cloud”, dar are un mare minus: momentan nu are o funcție de „One-click Restore”. Mi s-a părut prea riscant să scriu o logică de suprascriere a fișierelor și a bazei de date fără să am un sistem de rollback extrem de solid. Decât să las utilizatorul cu un site „alb” (WSOD) la jumătatea procesului pentru că a picat conexiunea, am preferat să-l las să descarce arhiva manual din Backblaze și să facă restore-ul prin SSH sau FTP.
În final, după 3 iterații de review, plugin-ul e live. Are deja vreo 40 de instalări active și niciun crash raportat. A meritat efortul? Da, pentru că am învățat mai mult despre standardele WP în 3 săptămâni decât în ultimii 2 ani de proiecte custom.
Voi ce folosiți pentru storage ieftin? Rămâneți pe S3 sau ați trecut și voi pe alternative gen B2 sau Wasabi?