Salutare! Am vrut o soluție simplă de backup direct în Backblaze B2, fără bătăi de cap și mai ales fără să plătesc licențe premium doar ca să folosesc un bucket S3-compatible. Așa că acum câteva luni am scris propriul plugin, l-am pus pe GitHub și, după o luptă destul de lungă cu echipa de review de la WordPress, am reușit să-l urc pe directorul oficial.
De ce încă un plugin de backup?
Am avut un proiect cu vreo 12 site-uri de prezentare ale unui client. Nimic complicat, dar aveam nevoie de backup zilnic în cloud. Când am văzut că majoritatea pluginurilor mari din repo îți cer bani ca să te lase să configurezi altceva în afară de Google Drive sau Dropbox, m-am enervat. Backblaze B2 e incredibil de ieftin, în jur de 6$ pe TB pe lună, dar integrarea nativă lipsea din variantele gratuite.
Am zis că nu are cum să fie atât de greu. Am scris un wrapper simplu peste API-ul Backblaze, l-am cuplat cu wp_cron și gata. Fără interfețe încărcate cu reclame agresive de tip "upgrade to PRO". Doar pui cheia API, numele bucket-ului și alegi ora la care să ruleze.
Coșmarul numit "WordPress.org Plugin Review"
Aici a început distracția. Dacă n-ați mai trimis un plugin la review în ultimii doi ani, pregătiți-vă psihic. Procesul nu mai este automatizat complet și durează enorm. La mine a durat fix 43 de zile doar ca să primesc primul feedback de la review-erii manuali.
Codul meu a fost respins inițial din trei motive mari:
- Lipsa sanitizării datelor: Am uitat să trec variabilele de configurare prin
sanitize_text_fieldînainte de a le salva în baza de date. Clasic. - Folosirea directă a cURL: Am folosit direct funcții de cURL pentru upload-ul de fișiere mari în bucăți (chunked upload). Regula lor spune clar: trebuie să folosești API-ul intern din WordPress, adică
wp_remote_postsau clasaWP_Http. A trebuit să refac toată logica de transport. - Încărcarea globală a scripturilor: Încărcam fișierele JS și CSS în tot panoul de administrare, nu doar pe pagina mea de setări. Asta e o greșeală de începător pe care am făcut-o pur și simplu din grabă.
După ce am rezolvat astea și am trimis patch-ul, a mai durat încă 10 zile până când am primit acceptul final și acel mult așteptat acces la SVN-ul lor.
Trade-off-uri și stadiul actual
Pluginul e acum live, are în jur de 150 de instalări active și crește organic. Totuși, fiind un proiect scris în timpul liber, are niște limitări clare de care trebuie să fii conștient.
În primul rând, fiind bazat pe wp_cron, dacă ai un site fără trafic, backup-ul s-ar putea să nu ruleze la fix. În al doilea rând, pentru baze de date mari, de peste 2GB, procesul poate da timeout pe servere de hosting ieftine. Pe VPS-uri unde controlezi max_execution_time merge brici, dar pe shared hosting e la noroc.
Un alt compromis asumat este lipsa funcției de restore direct din interfață. Momentan doar urcă arhiva în cloud. Dacă vrei restore, o descarci manual din Backblaze și o pui prin SSH. Am preferat să țin codul extrem de simplu și sigur în loc să adaug funcții complexe de scriere în fișiere care pot deschide breșe de securitate.
A meritat efortul? Pentru mine da, am salvat costul unor licențe inutile și am învățat regulile lor stricte de igienă a codului.
Voi ce folosiți pentru backup-urile clienților voștri? Scripturi bash în cron la nivel de server sau vă bazați pe pluginuri din WP?