Am scris un plugin de backup în Backblaze B2 și l-am trecut de review-ul WordPress.org

Am lansat recent pe GitHub și în directorul oficial WordPress un plugin simplu de backup direct în Backblaze B2. L-am scris pentru că m-am săturat de soluțiile mamut care cer bani pentru orice integrare cloud elementară. Dacă vrei să-ți publici și tu propriul plugin pe wordpress.org, am trecut prin tot procesul de review și îți spun exact unde te lovești de zid.

De ce am scris codul ăsta?

La o agenție unde ajut pe partea de mentenanță avem în jur de 40 de site-uri mici și medii. Spațiul pe serverul de hosting costă, așa că backup-ul local e exclus pe termen lung. Backblaze B2 oferă primii 10 GB gratuit și apoi te costă în jur de 6 dolari pe terabait pe lună. E de departe cea mai ieftină variantă de stocare rece (cold storage) de pe piață.

Am căutat un plugin simplu. Toate cele mari (Updraft, BackupBuddy) fie te pun să plătești addon-uri anuale pentru B2, fie vin la pachet cu tone de scripturi care încarcă adminul de pomană. Așa că am pus mâna pe tastatură și am scris un plugin dedicat.

Trade-off-ul e destul de clar: pluginul meu face exact două lucruri. Împachetează baza de date, face un zip cu directorul wp-content și le urcă în bucket. Nu are restaurare cu un singur click (trebuie să le descarci manual și să le pui înapoi prin FTP/phpMyAdmin), nu are split automat la fișiere de 10GB. Merge brici pentru site-uri de până la 2-3 GB, dar e o idee proastă pentru mamuți de e-commerce cu mii de produse.

Calvarul numit "WordPress Plugin Review"

După ce am terminat codul și l-am urcat pe GitHub, am zis să-l trimit în repo-ul oficial. Știam că durează, dar nu mă așteptam să devină un mic job part-time de câteva săptămâni.

Am așteptat fix 38 de zile până când un reviewer voluntar s-a uitat pe codul meu. Și, evident, mi l-a respins din prima. Am făcut trei greșeli mari pe care le-am trecut cu vederea, deși scriu PHP de peste un deceniu:

1. Igienizarea datelor (Sanitization și Escaping): Am folosit stripslashes și am crezut că e de ajuns pentru setările din admin. Greșit. Trebuie să folosești funcțiile lor specifice: sanitize_text_field() la salvare și obligatoriu esc_attr() sau esc_html() la afișare în formularul de setări. Chiar și pentru chestii banale precum afișarea cheii de API.
2. Prefixarea globală: Am avut o clasă utilitară numită simplu B2Client. Mi s-a atras atenția că dacă alt plugin folosește aceeași librărie neoficială de Backblaze, site-ul crapă cu Fatal Error. Am fost obligat să adaug un prefix unic la tot: clase, funcții, constante și opțiuni din baza de date. Din B2Client a devenit Wpb2_B2Client.
3. Căi absolute greșite: Încărcam direct o clasă din SDK-ul meu folosind căi relative, în loc să folosesc plugin_dir_path(). Pe unele servere cu setup-uri custom de symlink-uri, chestia asta dădea erori majore de încărcare.

Cum am automatizat deployment-ul (GitHub -> SVN)

Cea mai mare durere la WordPress este că încă folosesc SVN (Subversion) pentru stocarea pluginurilor. Să lucrez cu SVN în mod direct mi se pare masochism curat în prezent.

Am rezolvat problema asta elegant cu un GitHub Action numit 10up/action-wordpress-plugin-deploy. Acum, când fac un release pe GitHub cu un tag nou (de exemplu v1.1.2), acțiunea rulează automat în background, îmi trage codul curat, elimină fișierele de test și îl împinge direct în repo-ul de SVN de la WordPress. Am economisit cam 20-30 de minute la fiecare update și am scăpat de instalat clienți de SVN pe mașina locală.

Voi cum gestionați backup-urile pentru clienții mici? Mergeți pe soluții sase-uri mari sau preferați chestii simple, scrise de voi?