Memutar Beberapa Situs WordPress Secara Lokal Dengan DevKinsta

Saat membangun tema dan plugin untuk WordPress, kita perlu memastikan mereka bekerja dengan baik di semua lingkungan yang berbeda di mana mereka akan diinstal. Kami terkadang dapat mengontrol lingkungan ini saat membuat tema untuk situs web kami sendiri, tetapi di lain waktu kami tidak bisa, seperti saat mendistribusikan plugin kami melalui repositori WordPress publik untuk diunduh dan diinstal oleh siapa saja.

Mengenai WordPress, kemungkinan kombinasi lingkungan yang perlu kami khawatirkan meliputi:

  • Versi PHP yang berbeda,
  • Berbagai versi WordPress,
  • Versi berbeda dari editor WordPress (alias editor blok),
  • HTTPS diaktifkan/dinonaktifkan,
  • Multisite diaktifkan/dinonaktifkan.

Mari kita lihat bagaimana hal ini terjadi. PHP 8.0, yang merupakan versi terbaru dari PHP, telah memperkenalkan perubahan yang melanggar dari versi sebelumnya. Karena WordPress masih secara resmi mendukung PHP 5.6, plugin kami mungkin perlu mendukung 7 versi PHP: PHP 5.6, plus PHP 7.0 hingga 7.4, plus PHP 8.0. Jika plugin memerlukan beberapa fitur khusus PHP, seperti properti yang diketik (diperkenalkan dalam PHP 7.4), maka plugin tersebut perlu mendukung versi PHP tersebut dan seterusnya (dalam hal ini, PHP 7.4 dan PHP 8.0).

Mengenai versi di WordPress, perangkat lunak ini sendiri kadang-kadang dapat memperkenalkan perubahan yang melanggar, seperti pembaruan ke versi jQuery yang lebih baru di WordPress 5.6. Selain itu, setiap rilis utama WordPress memperkenalkan fitur baru (seperti editor Gutenberg baru, yang diperkenalkan di versi 5.0), yang mungkin diperlukan untuk produk kami.

Editor blok tidak terkecuali. Jika tema dan plugin kami berisi blok khusus, mengujinya untuk semua versi yang berbeda sangat penting. Paling tidak, kita perlu mengkhawatirkan dua versi Gutenberg: yang dikirimkan dalam inti WordPress, dan yang tersedia sebagai plugin mandiri.

Mengenai HTTPS dan multisite, tema dan plugin kami dapat berperilaku berbeda tergantung pada apakah ini diaktifkan atau tidak. Misalnya, kami mungkin ingin menonaktifkan akses ke titik akhir REST saat tidak menggunakan HTTPS atau memberikan kemampuan yang diperluas ke admin super dari multisitus.

Ini berarti ada banyak kemungkinan lingkungan yang perlu kita khawatirkan. Bagaimana kita menanganinya?

Mencari Tahu Lingkungan

Segala sesuatu yang dapat diotomatisasi, harus diotomatisasi. Misalnya, untuk menguji logika pada tema dan plugin kami, kami dapat membuat proses integrasi berkelanjutan yang menjalankan serangkaian pengujian di beberapa lingkungan. Otomatisasi menghilangkan sebagian besar rasa sakit.

Namun, kita tidak bisa hanya mengandalkan mesin yang melakukan semua pekerjaan untuk kita. Kami juga perlu mengakses beberapa situs WordPress pengujian untuk memvisualisasikan jika, setelah beberapa peningkatan perangkat lunak, tema kami masih terlihat sebagaimana mestinya. Misalnya, jika Gutenberg memperbarui sistem gaya globalnya atau bagaimana blok inti berperilaku, kami ingin memeriksa apakah produk kami tidak terpengaruh oleh perubahan tersebut.

Berapa banyak lingkungan berbeda yang perlu kita dukung? Katakanlah kita menargetkan 4 versi PHP (7,2 hingga 8.0), 5 versi WordPress (5.3 hingga 5.7), 2 versi Gutenberg (inti/plugin), HTTPS diaktifkan/dinonaktifkan, dan multisite aktif/nonaktif. Semuanya berjumlah total 160 kemungkinan lingkungan. Itu terlalu banyak untuk ditangani.

Untuk menyederhanakan masalah, alih-alih membuat situs untuk setiap kemungkinan kombinasi, kita dapat menguranginya menjadi beberapa lingkungan yang, secara keseluruhan, terdiri dari semua properti yang berbeda.

Misalnya, kami dapat menghasilkan lima lingkungan ini:

  1. PHP 7.2 + WP 5.3 + inti Gutenberg + HTTPS + multisitus
  2. PHP 7.3 + WP 5.4 + plugin Gutenberg + HTTPS + multisitus
  3. PHP 7.4 + WP 5.5 + plugin Gutenberg + tanpa HTTPS + tanpa multisite
  4. PHP 8.0 + WP 5.6 + inti Gutenberg + HTTPS + tanpa multisite
  5. PHP 8.0 + WP 5.7 + inti Gutenberg + tanpa HTTPS + tanpa multisite

Memutar 5 situs WordPress dapat dikelola, tetapi tidak mudah karena melibatkan tantangan teknis, terutama mengaktifkan versi PHP yang berbeda, dan menyediakan sertifikat HTTPS.

Kami ingin memutar situs WordPress dengan mudah, bahkan jika kami memiliki pengetahuan sistem yang terbatas. Dan kami ingin melakukannya dengan cepat karena kami memiliki pekerjaan pengembangan dan desain yang harus dilakukan. Bagaimana kita bisa melakukannya?

Mengelola Situs WordPress Lokal Dengan DevKinsta

Untungnya, memutar situs WordPress lokal tidak sulit saat ini, karena kita dapat menghindari pekerjaan manual, dan sebaliknya mengandalkan alat yang mengotomatiskan proses untuk kita.

DevKinsta adalah alat semacam ini. Ini memungkinkan untuk meluncurkan situs WordPress lokal dengan upaya minimal, untuk konfigurasi apa pun yang diinginkan. Situs ini akan dibuat dalam waktu yang lebih singkat untuk minum secangkir kopi. Dan tentu saja harganya kurang dari secangkir kopi: DevKinsta 100% gratis dan tersedia untuk pengguna Windows, macOS, dan Ubuntu .

Seperti namanya, DevKinsta dibuat oleh Kinsta , salah satu penyedia hosting terkemuka di ruang WordPress. Tujuan mereka adalah untuk menyederhanakan proses bekerja dengan proyek WordPress, baik untuk desainer atau pengembang, pekerja lepas, atau agensi. Semakin mudah kita mengatur lingkungan kita, semakin kita bisa fokus pada tema dan plugin kita sendiri, semakin baik produk kita.

Keajaiban yang mendukung DevKinsta adalah Docker , perangkat lunak yang memungkinkan untuk mengisolasi aplikasi dari lingkungannya melalui wadah. Namun, kami tidak diharuskan untuk mengetahui tentang Docker atau container: DevKinsta menyembunyikan kompleksitas yang mendasarinya, jadi kami dapat meluncurkan situs WordPress dengan menekan sebuah tombol.

Pada artikel ini, kita akan mengeksplorasi cara menggunakan DevKinsta untuk meluncurkan 5 instance WordPress lokal yang berbeda untuk menguji sebuah plugin, dan fitur bagus apa yang kita miliki.

Meluncurkan Situs WordPress Dengan DevKinsta

Gambar dari atas menunjukkan DevKinsta saat membukanya untuk pertama kalinya. Ini menyajikan 3 opsi untuk membuat situs WordPress lokal baru:

  1. Situs WordPress baru
    Ini menggunakan konfigurasi default, termasuk rilis WordPress terbaru dan PHP 8.
  2. Impor dari Kinsta
    Itu mengkloning konfigurasi dari situs yang ada yang dihosting di MyKinsta.
  3. Situs kustom
    Ini menggunakan konfigurasi khusus, yang disediakan oleh Anda.

Menekan opsi #1 akan benar-benar menghasilkan situs WordPress lokal tanpa memikirkannya. Saya bisa menjelaskan sedikit lebih jauh jika saja saya bisa; sebenarnya tidak lebih dari itu.

Jika Anda adalah pengguna Kinsta, menekan opsi #2 memungkinkan Anda untuk langsung mengimpor situs dari MyKinsta , termasuk dump database-nya. (Btw, ini juga bekerja dengan arah yang berlawanan: perubahan lokal di DevKinsta dapat didorong ke situs pementasan di MyKinsta .)

Terakhir, saat menekan opsi #3, kita dapat menentukan konfigurasi kustom apa yang akan digunakan untuk situs WordPress lokal.

Mari kita tekan tombol untuk opsi #3. Layar konfigurasi akan terlihat seperti ini:

Beberapa input hanya-baca. Ini adalah opsi yang saat ini diperbaiki tetapi akan dapat dikonfigurasi di masa mendatang. Misalnya, server web saat ini disetel ke Nginx, tetapi pekerjaan untuk menambahkan Apache sedang berlangsung.

Opsi yang saat ini dapat kami konfigurasikan adalah sebagai berikut:

  • Nama situs (dari mana URL lokal dihitung),
  • versi PHP,
  • Nama basis data,
  • HTTPS diaktifkan/dinonaktifkan,
  • Judul situs WordPress,
  • versi WordPress,
  • Email admin, nama pengguna dan kata sandi,
  • Multisite diaktifkan/dinonaktifkan.

Setelah menyelesaikan informasi ini untuk situs WordPress lokal pertama saya, yang disebut “GraphQL API pada PHP 80”, dan mengklik “Buat situs”, yang dibutuhkan DevKinsta untuk membuat situs hanya 2 menit. Kemudian, saya disajikan layar info untuk situs yang baru dibuat:

Situs WordPress baru tersedia di bawah domain lokalnya sendiri graphql-api-on-php80.local . Mengklik tombol "Buka situs", kami dapat memvisualisasikan situs baru kami di browser:

Saya mengulangi proses ini untuk semua lingkungan yang berbeda yang diperlukan, dan voila, 5 situs WordPress lokal saya siap dan berjalan dalam waktu singkat. Sekarang, daftar layar awal DevKinsta di semua situs saya:

Menggunakan WP-CLI

Dari konfigurasi yang diperlukan untuk lingkungan saya, sejauh ini saya telah memenuhi semua item kecuali satu: menginstal Gutenberg sebagai plugin.

Mari kita lakukan ini selanjutnya. Kita dapat menginstal plugin seperti biasa melalui WP admin, yang dapat kita akses dengan mengklik tombol “WP admin” dari layar info situs, seperti yang terlihat pada gambar di atas.

Lebih baik lagi, DevKinsta dikirimkan dengan WP-CLI yang sudah diinstal, sehingga kita dapat berinteraksi dengan situs WordPress melalui antarmuka baris perintah.

Dalam hal ini, kita perlu memiliki pengetahuan minimal tentang Docker. Menjalankan perintah dalam wadah dilakukan seperti ini:

 docker exec {containerName} /bin/bash -c '{command}'

Parameter yang dibutuhkan adalah:

  • Wadah devkinsta_fpm disebut devkinsta_fpm .
  • Perintah WP-CLI untuk menginstal dan mengaktifkan plugin adalah wp plugin install {pluginName} --activate --path={pathToSite} --allow-root
  • Jalur ke situs WordPress, di dalam wadah, adalah /www/kinsta/public/{siteName} .

Menyatukan semuanya, perintah untuk menginstal dan mengaktifkan plugin Gutenberg di situs WordPress lokal adalah ini:

 docker exec devkinsta_fpm /bin/bash -c 'wp plugin install gutenberg --activate --path=/www/kinsta/public/MyLocalSite --allow-root'

Menjelajahi Fitur

Ada beberapa fitur praktis yang tersedia untuk situs WordPress lokal kami.

Yang pertama adalah integrasi dengan Adminer , alat yang mirip dengan phpMyAdmin, untuk mengelola database . Dengan alat ini, kita dapat langsung mengambil dan mengedit data melalui kueri SQL khusus. Mengklik tombol “Pengelola basis data”, pada layar info situs, akan membuka Adminer di tab browser baru:

Fitur penting kedua adalah integrasi dengan Mailhog , alat pengujian email yang populer. Berkat alat ini, email apa pun yang dikirim dari situs WordPress lokal sebenarnya tidak dikirim, tetapi ditangkap, dan ditampilkan di kotak masuk Email:

Mengklik email, kita dapat melihat isinya:

Mengakses File Instalasi Lokal

Setelah menginstal situs WordPress lokal, foldernya yang berisi semua filenya (termasuk inti WordPress, tema dan plugin yang diinstal, dan item media yang diunggah) akan tersedia untuk umum:

  • Mac dan Linux: di bawah /Users/{username}/DevKinsta/public/{siteName} .
  • Windows: di bawah C:\Users\{username}\DevKinsta\public\{siteName} .

(Dengan kata lain: file situs WordPress lokal dapat diakses tidak hanya melalui wadah Docker, tetapi juga melalui sistem file di OS kita, seperti menggunakan My PC di Windows, Finder di Mac, atau terminal apa pun.)

Ini sangat nyaman karena menawarkan jalan pintas untuk menginstal tema dan plugin yang kami kembangkan, mempercepat pekerjaan kami.

Misalnya, untuk menguji perubahan plugin di semua 5 situs lokal, kita biasanya harus pergi ke admin WP di setiap situs, dan mengunggah versi baru plugin (atau, sebagai alternatif, gunakan WP-CLI).

Dengan memiliki akses ke folder situs, kita cukup mengkloning plugin dari reponya, langsung di bawah wp-content/plugins :

 $ cd ~/DevKinsta/public/MyLocalSite/wp-content/plugins $ git clone git@github.com:leoloso/MyAwesomePlugin.git

Dengan cara ini, kita bisa git pull untuk memperbarui plugin kita ke versi terbaru, membuatnya segera tersedia di situs WordPress lokal:

 $ cd MyAwesomePlugin $ git pull

Jika kita ingin menguji plugin yang sedang dikembangkan di cabang yang berbeda, kita juga dapat melakukan git checkout :

 git checkout some-branch-with-new-feature

Karena kami mungkin memiliki beberapa situs dengan lingkungan yang berbeda, kami dapat mengotomatiskan prosedur ini dengan menjalankan skrip bash, yang mengulangi situs WordPress lokal dan, untuk masing-masing, menjalankan git pull untuk plugin yang diinstal di dalam:

 #!/bin/bash iterateSitesAndGitPullPlugin(){ cd ~/DevKinsta/public/
for file in * do if [ -d "$file" ]; then cd ~/DevKinsta/public/$file/wp-content/plugins/MyAwesomePlugin git pull fi done } iterateSitesAndGitPullPlugin

Kesimpulan

Saat merancang dan mengembangkan tema dan plugin WordPress kami, kami ingin dapat fokus pada pekerjaan kami yang sebenarnya, sebanyak mungkin. Jika kami dapat mengotomatiskan pengaturan lingkungan kerja, kami kemudian dapat menginvestasikan waktu dan energi ekstra ke dalam produk kami.

Inilah yang memungkinkan DevKinsta. Kita dapat memutar situs WordPress lokal hanya dengan menekan sebuah tombol, dan membuat banyak situs dengan lingkungan yang berbeda hanya dalam beberapa menit.

DevKinsta sedang dikembangkan dan didukung secara aktif. Jika Anda mengalami masalah atau memiliki pertanyaan, Anda dapat menelusuri dokumentasi atau menuju ke forum Komunitas , di mana pembuat DevKinsta akan membantu Anda.

Semua ini, gratis. Kedengarannya bagus? Jika demikian, unduh DevKinsta dan buka situs WordPress lokal Anda.

June 15, 2021

codeorayo

Ampuh! Ini rahasia mengembangkan aplikasi secara instan, tinggal download dan kembangkan. Gabung sekarang juga! Premium Membership [PRIVATE] https://premium.codeorayo.com

Leave a Reply

Your email address will not be published. Required fields are marked *