public function upload_chunk( string $file_path, string $upload_url, string $auth_token, int $part_number ) {
$file_handle = fopen( $file_path, 'rb' );
fseek( $file_handle, ( $part_number - 1 ) * self::CHUNK_SIZE );
$data = fread( $file_handle, self::CHUNK_SIZE );
fclose( $file_handle );
$response = wp_remote_post( $upload_url, [
'headers' => [
'Authorization' => $auth_token,
'X-Bz-Part-Number' => $part_number,
'Content-Length' => strlen( $data ),
'SHA1' => sha1( $data ),
],
'body' => $data,
'timeout' => 120,
] );
return ! is_wp_error( $response ) && wp_remote_retrieve_response_code( $response ) === 200;
}Am lansat recent un plugin open-source de WordPress care face backup automat direct în Backblaze B2, fără să ceară abonamente lunare pentru funcții de bază. L-am urcat deja pe GitHub și a trecut prin furcile caudine ale review-ului oficial de pe WordPress.org. Vreau să povestesc puțin din culise, mai ales despre ce înseamnă să treci un plugin prin echipa lor de securitate în 2024.
De ce încă un plugin de backup?
Administrez în jur de 35 de site-uri de WordPress pentru clienți mici și mijlocii. Până acum ceva timp foloseam o combinație de UpdraftPlus și AWS S3, dar când au schimbat politica de pricing pentru extensiile de stocare terță, suma totală devenise aberantă. În paralel, Backblaze B2 oferă stocare la aproximativ $6/TB pe lună, iar primii 10 GB sunt moca.
Sincer, nu aveam nevoie de 100 de opțiuni obositoare. Voiam doar trei lucruri simple:
- Să facă dump la baza de date și zip la
wp-content. - Să trimită fișierele prin API-ul B2 nativ în bucăți de câte 10MB (chunked upload).
- Să șteargă backup-urile mai vechi de 30 de zile.
Am scris varianta inițială într-un weekend. A mers brici pe un site cu 12GB de fișiere media, așa că am decis să-l curăț și să-l public gratuit.
Compromisurile din arhitectură
Ca să nu umflu pluginul cu foldere enorme în vendor, am refuzat să includ SDK-ul oficial AWS sau Backblaze. Doar SDK-ul lor oficial adăuga vreo 15MB de fișiere PHP extra. Am preferat să scriu un client minimalist de B2 API folosind funcția nativă wp_remote_post().
Trade-off-ul direct: pluginul nu are interfață de restore automată în dashboard. Dacă cade site-ul de tot, oricum nu mai poți da click pe "Restore" din panoul de administrare. Descarci zip-ul din consola Backblaze și faci restore manual sau prin CLI. Pentru mine și echipa mea e arhi-suficient, dar pentru un utilizator non-tehnic e un minus clar.
Calvarul review-ului pe WordPress.org
Aici a început distracția reală. A durat 4 săptămâni și am avut nevoie de 3 runde de refactorizare ca să fiu aprobat în directorul oficial. Echipa lor folosește scanere automate foarte drastice, urmate de o verificare manuală la linie de cod.
Câteva chestii pe care le-am învățat pe pielea mea:
- Prefixare maniacală: Fiecare funcție, clasă, constantă și variabilă globală trebuie să aibă prefixul pluginului (de exemplu
wpb2_). Dacă folosești un helper generic genformat_bytes(), îți resping build-ul instant. - Escaping și Sanitization: Nu e suficient să sanitizezi input-ul când salvezi datele în DB. Trebuie să folosești
esc_html(),esc_attr()sauwp_kses()absolut peste tot unde afișezi ceva în admin HTML, chiar și pentru opțiuni salvate intern. - Nonces peste tot: Orice acțiune AJAX sau trimitere de formular are nevoie de validare strictă de nonce și verificare de capabilități (
current_user_can('manage_options')).
Punctul cel mai sensibil a fost gestionarea bucăților mari de fișiere fără să dau timeout la PHP pe hosting ieftin. Am rezolvat prin executarea procesului pe fundal prin WP-Cron, împărțind zip-ul în bucăți de 10MB pe care le urc secvențial.
Ce urmează?
Codul e 100% open-source pe GitHub sub licență GPLv2. Urmează să adaug suport pentru notificări pe Slack și Discord când un backup e finalizat cu succes sau eșuează.
Voi ce soluție folosiți pentru backup-urile site-urilor WP pe care le administrați? Vă bazați pe uneltele oferite de host sau folosiți soluții externe stocate în cloud-ul propriu?