ლოკალური შემუშავება zinnector dev-ით

zinnector dev უშვებს რეალურ WordPress-ს თქვენს საკუთარ კომპიუტერზე, რომელიც ემსახურება თქვენს პროექტში არსებულ პლაგინებსა და თემებს თქვენ მიერ არჩეული PHP ვერსიით. ეს სტატია ხსნის ორ გარემოს, რომელთა გამოყენებაც მას შეუძლია, ვერსიების შერჩევის წესს, იმას, თუ რა საიდან ეწოდება და სად მდებარეობს შესასრულებელი გარემო დისკზე — ისე, რომ ის, რასაც ლოკალურად ტესტავთ, ზუსტად ის იყოს, რასაც აქვეყნებთ.

ორი შესასრულებელი გარემო და მიზეზი, თუ რატომ არის ორივე რეალური

ნაგულისხმევად გამოიყენება Playground. WordPress Playground აკომპილირებს PHP-ს WebAssembly-ში და უშვებს მას Node-ის შიგნით, ამიტომ ლეპტოპს, რომელზეც Node-ის გარდა არაფერია დაინსტალირებული, WordPress-ის ჩასართავად მხოლოდ რამდენიმე წამი სჭირდება. ხელმისაწვდომია PHP-ს ნებისმიერი ვერსია 5.2-დან 8.5-მდე. ის შეიცავს PHP გაფართოებების მცირე კომპლექტს (intl, redis, memcached მიმდინარე აგების მონაცემებით), რაც სავსებით საკმარისია პლაგინებისა და თემების უმეტესობასთან სამუშაოდ.

Docker უშვებს ნატიურ php-fpm-სა და MariaDB კონტეინერებს. ის უფრო ნელია, საჭიროებს Docker დემონს დაახლოებით 1.2 გბ მოცულობის იმიჯებს და მხარს უჭერს PHP-ს 7.4-დან 8.5-მდე ვერსიებს — სამაგიეროდ, ის უშვებს ნატიურ PHP-ს გაფართოებების სრული კომპლექტით, მათ შორის imagick-ით და gd-ით. ეს არის სწორი გამოსავალი მაშინ, როდესაც შესატესტი გაფართოება არ არის წარმოდგენილი WebAssembly-ის აგებაში.

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

Docker-ზე ავტომატური გადართვა არასდროს ხდება. დეველოპერს, რომელსაც ჰგონია, რომ WebAssembly-ს იყენებს, რეალურად კი Docker-ზეა, ინსტრუმენტმა შესაძლოა არასწორი ინფორმაცია მიაწოდოს, ცდილობს რა მის დახმარებას, ამიტომ მისი გამოძხება სახელის მითითებით არის საჭირო.

PHP-სა და 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

ნაგულისხმევი პარამეტრები აღებულია პროექტში არსებული zinnector.json ფაილიდან — php, wordpress, runtime და port — რომელსაც წერს zinnector new და რომელიც უნდა დააკომიტოთ, რათა პროექტში ჩართულმა ყველა პირმა ერთი და იგივე ვერსიები გამოიყენოს. ბრძანებათა სტრიქონში მითითებული ფლაგირება კონკრეტული გაშვებისთვის უპირატესობას ანიჭებს ფაილის პარამეტრებს.

ვერსია, რომელსაც აცხადებთ, და ვერსია, რომელიც ეშვება, სხვადასხვა ცნებაა. zinnector dev --once რთავს შესასრულებელ გარემოს, ბეჭდავს მის რეალურ მონაცემებს — PHP ვერსიას, WordPress ვერსიას, ჩატვირთულ გაფართოებებს — და ჩერდება. zinnector check --probe იყენებს ზუსტად ამავე გაზომვებს მაშინ, როდესაც ადარებს თქვენს პროექტს ჰოსტინგის სლოტს.

რა მოწოდება ხდება თქვენი პროექტიდან

გარემო პირდაპირ აერთიანებს თქვენი პროექტის wp-content/plugins, wp-content/themes და wp-content/mu-plugins დირექტორიებს, ამიტომ შენახული ფაილი უკვე მომდევნო განახლებისთანავე აქტიურია. ის დირექტორიები, რომლებიც არსებობს, მაგრამ რეალურ კონტენტს არ შეიცავს, მიზანმიმართულად არ მონტირდება: ცარიელი themes/, რომელიც აერთიანებს გარემოს საკუთარ თემებს, WordPress-ს თემის გარეშე დატოვებდა, რაც თქვენი საიტის ნაცვლად გამოიწვევს ცარიელ 500-იან შეცდომას. სწორედ ამიტომ ინარჩუნებს კარკასი ცარიელ დირექტორიებს .gitkeep ფაილით და სწორედ ამიტომ არ ახდენს ისინი არაფრის გადაფარვას მანამ, სანამ მათში რაიმე თემას არ ჩაათავსებთ.

სად მდებარეობს შესასრულებელი გარემო

WordPress-ის გარემო CLI-ის შემადგენლობაში არ მოჰყვება და პირველივე გამოყენებისას იტვირთება — პაკეტი, რომელიც PHP-ის თითოეულ აგებას ატარებს, დაახლოებით 570 მბ-ია, და დეველოპერი, რომელიც მხოლოდ საიტების სიის ნახვით შემოიფარგლება, არ უნდა იხდიდეს მის საფასურს. ის ინახება Zinnector®-ის საკუთარ ქეშში, ~/.cache/zinnector/runtimes/playground/<version> (ან იქ, სადაც ZINNECTOR_CACHE_DIR მიუთითებს), და არა თქვენს პროექტში, რათა არ აღმოჩნდეს თქვენს საცავში ან იმ ხეში, რომელსაც zinnector push აანალიზებს. ჩამოტვირთვას ახდენს თქვენივე npm, რომელიც ეშვება როგორც node npm-cli.js — და არა შეელის მეშვეობით.

გარემოს ვერსია მიბმულია CLI-ის ვერსიას, ამიტომ ერთ პროექტზე მომუშავე ორი დეველოპერი PHP-ის ერთსა და იმავე აგებას იყენებს. zinnector dev --reset-runtime შლის დაინსტალირებულ გარემოს და თავიდან აინსტალირებს მას, რაც წარმოადგენს იმ გარემოს აღდგენის გზას, რომელიც დაინსტალირდა, მაგრამ არ ირთვება.

Node 26-ზე ან უფრო ახალ ვერსიებზე

თვითონ CLI მუშაობს Node-ის ნებისმიერ ვერსიაზე 24-დან მოყოლებული. თუმცა, გარემოს ნატიური მოდული წინასწარ აგებულ ბინარულ ფაილებს აწვდის მხოლოდ Node 24-სა და 25-ს (2026 წლის სექტემბრის მდგომარეობით). იმის მაგივრად, რომ რაიმე აკომპილირდეს — რაც Windows-ის შემთხვევაში Visual Studio-ს ინსტალაციას ნიშნავს — Zinnector® მხოლოდ გარემოსთვის ქაჩავს Node 24-ს, დაახლოებით 30 მბ-ს, რომლის სისწორეც მოწმდება nodejs.org-ის მიერ გამოქვეყნებული საკონტროლო ჯამებით, იმავე ქეშში. ინსტალაციის მოთხოვნა ამის შესახებ მიუთითებს გამოყენებისას. თქვენს საკუთარ Node-ში არაფერი იცვლება.

დაკავშირებული

• დაწყება · განთავსება · ბრძანებების ცნობარი · ხარვეზების აღმოფხვრა