Bază de cunoștințe

Dezvoltare locală cu zinnector dev

Cum rulează zinnector dev un WordPress real pe propriul dumneavoastră computer: cele două medii de execuție (WebAssembly fără Docker sau PHP nativ în Docker), alegerea unei versiuni de PHP și WordPress, ce este servit din proiectul dumneavoastră, unde se află mediul de execuție de 570 MB și ce se întâmplă pe Node 26.

zinnector dev rulează un WordPress real pe propriul dumneavoastră computer, servind modulele și temele din proiectul dumneavoastră, cu o versiune PHP pe care o alegeți. Acest articol explică cele două medii de execuție pe care le poate folosi, cum să alegeți versiunile, ce este servit și de unde, precum și unde se află mediul de execuție pe disc — astfel încât ceea ce testați local să fie exact ceea ce implementați.

Cele două medii de execuție și de ce ambele sunt reale

Playground este cel implicit. WordPress Playground compilează PHP în WebAssembly și îl rulează în interiorul Node, astfel încât un laptop fără nimic altceva instalat în afară de Node pornește un WordPress în câteva secunde. Orice versiune PHP de la 5.2 la 8.5 este disponibilă. Acesta include un set restrâns de extensii PHP (intl, redis, memcached, conform versiunii curente), ceea ce este suficient pentru majoritatea activităților de dezvoltare de module și teme.

Docker rulează containere native php-fpm și MariaDB. Este mai lent, necesită un demon Docker și aproximativ 1,2 GB de imagini și acceptă PHP de la 7.4 la 8.5 — dar rulează un PHP nativ cu setul complet de extensii, inclusiv imagick și gd. Este soluția corectă atunci când ceea ce trebuie să testați este o extensie pe care versiunea WebAssembly nu o include.

zinnector dev                       # playground
zinnector dev --runtime docker      # native PHP + MariaDB

Nu se trece niciodată la Docker în mod silențios. Un dezvoltator care crede că folosește WebAssembly, dar se află de fapt pe Docker, a primit un răspuns eronat de la un instrument care încerca să ajute; prin urmare, acesta trebuie solicitat în mod explicit prin nume.

Alegerea versiunilor de PHP și WordPress

zinnector dev --php 8.1 --wp 6.7    # develop against a specific pair
zinnector dev --port 9401           # when 9400 is taken
zinnector dev --no-login            # do not sign in to wp-admin automatically
zinnector dev --verbose             # show the runtime's own output

Valorile implicite provin din fișierul zinnector.json din proiect — php, wordpress, runtime și port — pe care zinnector new îl scrie și pe care ar trebui să îl includeți în comit, astfel încât toți cei care lucrează la proiect să ruleze aceleași versiuni. Un parametru specificat în linia de comandă are prioritate față de fișier pentru execuția respectivă.

Versiunea pe care o declarați și versiunea care rulează sunt aspecte diferite. zinnector dev --once pornește mediul de execuție, afișează ceea ce raportează acesta în mod real — versiunea PHP, versiunea WordPress, extensiile încărcate — și se oprește. zinnector check --probe utilizează aceeași măsurătoare atunci când compară proiectul dumneavoastră cu un slot de găzduire.

Ce este servit din proiectul dumneavoastră

Mediul de execuție montează direct directoarele wp-content/plugins, wp-content/themes și wp-content/mu-plugins ale proiectului dumneavoastră, astfel încât un fișier pe care îl salvați este activ la următoarea reîncărcare. Directoarele care există, dar nu conțin conținut real, sunt în mod deliberat nemontate: un director themes/ gol montat peste temele proprii ale mediului de execuție ar lăsa WordPress fără nicio temă, ceea ce generează o eroare 500 cu pagină albă în loc de site-ul dumneavoastră. Acesta este motivul pentru care structura inițială păstrează directoare goale cu un fișier .gitkeep și de ce acestea nu maschează nimic până când nu plasați o temă în ele.

Unde se află mediul de execuție

Mediul de execuție WordPress este descărcat la prima utilizare, mai degrabă decât livrat împreună cu interfața în linie de comandă (CLI) — pachetul care conține fiecare compilare PHP are aproximativ 570 MB, iar un dezvoltator care doar listează site-uri nu ar trebui să fie încărcat cu acesta. Este păstrat în memoria cache proprie a Zinnector®, ~/.cache/zinnector/runtimes/playground/<version> (sau oriunde indică ZINNECTOR_CACHE_DIR), niciodată în proiectul dumneavoastră, astfel încât nu poate ajunge în depozitul dumneavoastră sau în arborele pe care îl măsoară zinnector push. Descărcarea este efectuată de propriul dumneavoastră npm, rulat ca node npm-cli.js — niciodată printr-un shell.

Versiunea mediului de execuție este asociată strict cu versiunea CLI, astfel încât doi dezvoltatori de pe un proiect rulează aceleași compilări PHP. zinnector dev --reset-runtime elimină mediul de execuție instalat și îl reinstalează, reprezentând remedierea pentru un mediu de execuție care s-a instalat, dar nu pornește.

Pe Node 26 sau versiuni mai noi

CLI-ul în sine rulează pe orice versiune de Node începând de la 24 în sus. Modulul nativ al mediului de execuție oferă însă fișiere binare precompilate doar pentru Node 24 și 25 (începând cu septembrie 2026). În loc să compileze ceva — ceea ce pe Windows înseamnă instalarea Visual Studio — Zinnector® descarcă o versiune Node 24 destinată exclusiv mediului de execuție, de aproximativ 30 MB, verificată pe baza sumelor de control publicate de nodejs.org, în aceeași memorie cache. Mesajul de instalare precizează acest lucru atunci când este cazul. Nimic din versiunea dumneavoastră de Node nu se modifică.

Resurse conexe

Toată documentația pentru dezvoltatori →

Cele mai recente din blog

Ce am scris despre găzduire, SEO și administrarea site-urilor la scară largă.

SEO și link building din stratul de găzduire: Perspectiva unui operator în 2026

Cum influențează găzduirea indexarea și distribuția autorității legăturilor (link equity) în 2026: menținerea paginilor indexate, evaluarea domeniilor vechi înainte de a construi pe ele, construirea de linkuri fără amprentă (footprint) și o perspectivă onestă asupra a ceea ce infrastructura poate și nu poate face pentru SEO.

Citiți articolul →

Optimizarea WordPress pentru viteză și securitate: o listă de verificare pentru performanță și module

O listă practică de verificare pentru un WordPress rapid și securizat: stocarea în cache la nivel de server, o memorie cache de obiecte per site, puținele module care merită rulate, menținerea stivei la zi și paginile WooCommerce pe care nu trebuie să le includeți niciodată în cache.

Citiți articolul →

Cum să alegeți găzduirea web gestionată în 2026: Ghidul cumpărătorului

Ce diferențiază cu adevărat o găzduire administrată bună de o mașină ieftină cu panou de control — migrări, copii de rezervă, izolare, stocare în cache reală și scalare corectă — și cum să o evaluați înainte de a vă lua un angajament.

Citiți articolul →

Citiți blogul →

Încă întâmpinați dificultăți?

Asistența este inclusă în fiecare plan, biroul este deschis 24 ore pe zi și ne puteți scrie în oricare dintre cele 58 limbi ale noastre — vă răspundem în limba dumneavoastră.

Contactați asistența → Toate articolele →