ev borcu WordPress sitesi
Yerel WordPress Geliştirme Ortamınız için En İyi Kurulum
Bir WordPress web sitesini çalıştırırken, en azından sitenin yerel bir kopyasını çalıştırmak en iyi uygulamadır, böylece canlı siteyi tamamen mahvetme riskini almadan değişiklik yapabilirsiniz. Siteleriniz için bir WordPress geliştirme ortamı çalıştırmak, geliştirici olarak üretken ve güvenli bir iş akışı için çok önemlidir.
Bu yazıda, geliştirme ortamını kurmanın, WordPress'i yerel olarak kurmanın, veritabanını karıştırmanın, hata ayıklamanın ve aradaki birçok işlemin çeşitli yollarında size rehberlik edeceğim. Kapsanacak çok şey var, bu yüzden bu gönderi bir ton bilgi içerse de, daha derine inen diğer makalelere iyi bir bağlantı koleksiyonu da içeriyor.
WordPress 5.5'in bir site için ortam türünü ayarlamanın bir yolunu sunduğunu biliyor muydunuz? Geçmişte geliştiriciler, çevreyi ayarlamak için kendi yöntemlerini kullanmak zorundaydı. Daha önce kendi sabit kümemizi kullandık ve diğerleri WP_ENV ortam değişkenini kullandı.
Bu, kodu farklı ortamlarda koşullu olarak yüklemek için gereklidir. Örneğin, geliştirme sitemde Mailgun aracılığıyla e-posta göndermek yerine, Mailgun eklentisini devre dışı bırakmak ve e-postaları Mailtrap ile güvenli bir şekilde test etmek için koşullu olarak küçük bir mu-plugin yükleyeceğim (Mailtrap'ı daha sonra ayrıntılı olarak ele alacağım).
WordPress 5.5 sürümüyle, ortam türünü bir sabit kullanarak ayarlayabilirsiniz (genellikle wp-config.php dosyasında bulunur):
define( 'WP_ENVIRONMENT_TYPE', 'development' );
Daha sonra koşullu kodda yeni wp_get_environment_type() işlevini kullanabilirsiniz:
If ( 'development' === wp_get_environment_type() ) { // run some dev only code }
Tamam, öyleyse buna girelim. Başlamak için en iyi yer WordPress geliştirme ortamıdır. Yeni bir site kurarken ilk başladığım yer ve zamanımın çoğunu site geliştirmeye harcadığım yer.
WordPress Geliştirme Ortamı
Daha önce de belirttiğim gibi, bir WordPress geliştirme ortamına sahip olmak bir geliştiricinin araç setinin hayati bir parçasıdır, bu nedenle sitelerde çalışabilir ve doğrudan canlı sitede hata yapma endişesi duymadan değişiklik yapabilirler. Ayrıca, canlı siteye uygulamadan önce hiçbir şeyin bozuk olup olmadığını kontrol etmek için eklenti, tema ve temel WordPress güncellemelerini test etmek için harika bir yerdir. Bu test, WooCoommerce gibi bir e-ticaret eklentisini güncellerken önemli bir süreçtir.
Ancak, daha önce bir geliştirme ortamı kurmadıysanız, bu göz korkutucu bir görev gibi görünebilir. WordPress sitelerini çalıştırmak için kullanılabilecek bir ortam 3 bölümden oluşur: bir web sunucusu (genellikle nginx veya Apache), PHP ve bir veritabanı yönetim sistemi (tipik olarak MySQL).
WordPress Geliştirme Ortamı Nasıl Kurulur
İşletim sisteminizden bağımsız olarak bilgisayarınıza bir ortam yüklemek ve çalıştırmak için çok sayıda yazılım seçeneği mevcuttur. Etrafında Mac OS, Windows ve Linux üzerinde çalışan ortamlar vardır. Geçenlerde Twitter'da geliştiricilerin WordPress geliştirme ortamları için ne kullandığını sordum ve sonuçlar ilginçti. Görünüşe göre aynı şeyleri kullanan çok sayıda kullanıcı var ama aynı zamanda ısmarlama sistemleri kullanan çok sayıda insan var:
? Merhaba #WordPress geliştiricileri – geliştirme ortamınız için ne kullanıyorsunuz?
Lütfen ulaşmak için RT yapar mısınız? #webdev
— Iain Poulson (@polevaultweb) 11 Ağustos 2020
Sonuçları göstermek için tüm cevapları ve oyları oldukça bilimsel bir şekilde ayırdım:
Açıkçası, Local (önceden Local by Flywheel olarak biliniyordu) kullanan birçok geliştirici var. Kendi Pete Tasker'ımız, Local için özel bir eklenti oluşturma hakkında bile yazdı. Birkaç Windows kullanıcısı Laragon kullanıyor (Matt hakkında yazdı) ve birkaç kişi Devilbox'ı Jonesy ile aynı şekilde kullanıyor.
Doğru geliştirme ortamını seçmek önemlidir, bu nedenle oldukça azını incelemek için biraz zaman harcadık – MAMP, XAMPP, Local ve DesktopServer'ı karşılaştırdık, Docker ve Vagrant'ı kafa kafaya aldık ve Valet, VVV ve Chassis'in nasıl yığıldığını keşfettik yukarı.
Geliştirme siteleri için VPS kullandıklarını söyleyen bir avuç insan görmek de ilgimi çekti. Bu nedenle, makinelerinde yerel bir geliştirme ortamına sahip olmak yerine, uzak bir sunucuda bir geliştirme ortamına sahiptirler.
Kullandığım bir DigitalOcean damlacığı var. Yerel bir şeyden çok daha yavaş değil ve web kancalarını ve diğer şeyleri kabul etmek için siteye genellikle canlı bir etki alanında ihtiyacım var.
— Jason Coleman (@jason_coleman) 11 Ağustos 2020
SpinupWP müşterilerinden, aynı şeyi yapmak için kullandıklarını duyduk ve kendi geliştiricilerimiz bile, PHP ve MySQL'in en son sürümlerinde özellikleri test edebilmeleri için DigitalOcean sunucusunda yeni bir WordPress sitesi açmayı bazen daha hızlı buluyorlar. .
Site Oluşturma
WordPress geliştirme ortamınızı kurduktan sonra, WordPress'i yerel olarak yüklemeniz gerekir. Bu, sıfırdan başladığınız yepyeni bir site veya üzerinde değişiklik yapmanıza olanak tanıyan mevcut canlı bir sitenin kopyası olan bir site olabilir.
Her iki durumda da, WordPress siteleri oluşturmak için çeşitli seçenekler vardır. Kendi WordPress site kurulum komut dosyanızı yayınlayabilir, WP-CLI kullanabilir veya Besteci kullanabilirsiniz. Bu günlerde başlangıç noktası olarak SpinupWP için Besteci tabanlı kurulumu kullanıyorum.
Muhtemelen bir WordPress sitesinin en önemli kısmı veritabanıdır. Bununla birlikte, WordPress veritabanı, büyük ölçüde URL'leri ve dosya yollarını her şeyi göreceli tutmak yerine veritabanında sakladığından, farklı ortamlarda iyi oynamaz.
Bu, veritabanlarını ortamlar arasında taşımayı zorlaştırır. Ama seni koruduk.
Veritabanlarını Ortamlar Arasında Taşıma
Geliştirme ortamınızda yerel olarak sıfırdan bir site kuruyorsanız, büyük olasılıkla veritabanını yeniden kurmuş olursunuz ve siteyi canlı hale getirmek söz konusu olduğunda, bu veritabanını canlı sunucuya taşımanız gerekir.
WordPress veritabanlarını ortamlar arasında taşımanın, PhpMyAdmin aracılığıyla dışa aktarma ve ardından içe aktarma gibi manuel yolları vardır. Ancak, .sql dışa aktarma dosyasında URL'lerin ve yolların değiştirilmesi gerekir ve bunu bir bul ve değiştir ile yapmak serileştirilmiş veri dizilerini bozabilir.
Veritabanını bir ortamdan diğerine aktardıysanız ve içe aktardıysanız, birkaç yöntemi kullanarak URL'leri ve yolları güvenle değiştirebilirsiniz:
- WP-CLI arama-değiştir komutunu kullanma
- WP Migrate DB gibi bul ve değiştir özelliğine sahip bir eklenti kullanma
Manuel dışa aktarma ve içe aktarma adımlarını denklemden çıkarmak ve biraz zaman kazanmak için, veritabanlarınızı ortamlar arasında itip çekmenize izin verecek WP Migrate DB Pro gibi bir eklenti kullanmanızı öneririm.
Örneğin, yerel geliştirme ortamınızdaki bir siteye son rötuşları yaptınız ve onu canlı hale getirmek istiyorsunuz. Yerel veritabanınızı birkaç tıklamayla canlı siteye 'gönderebilirsiniz'.
Aynı şey, bir süredir çalışmakta olan canlı bir sitede değişiklik yapmanız gerektiğinde de geçerlidir. Canlı veritabanının en son sürümünü yerel sitenize indirin, böylece hataları izlemek veya yeni özellikler üzerinde çalışmak için harika olan tam bir kopya üzerinde çalışabilirsiniz.
Veritabanında yerel olarak değişiklik yapmak ve bunları canlı siteye geri taşımak tamamen farklı bir top oyunudur. Kısa versiyon – bundan kaçınmaya çalışın. Uzun versiyon – WordPress veritabanı birleştirmeyi nasıl ele aldığımızı okuyun.
Medya kütüphanesi
Veritabanlarını ortamlar arasında taşımaktan bahsetmiştik, peki ya medya kitaplığı? Sitenizin yüklemeler klasörünün içeriği, bir WordPress sitesinin eşit derecede önemli bir parçasıdır. Tasarım veya ön uç değişiklikleri yaparken bir sitenin yerel bir sürümünü resimler olmadan çalıştırmak yardımcı olmaz.
SFTP her zaman bir seçenektir – canlı sunucunuza bağlanın ve sitenin wp-content/uploads dizinini kopyalayın. Veya dosyaları rsync ile bağlamak ve senkronize etmek için SSH'yi bile kullanabilirsiniz. Bu muhtemelen bunu yapmanın en manuel yoludur. 2015'te bu soruna farklı yaklaşımlar hakkında yazdım ve htaccess ve add_filter yeniden yazmaları gibi bazı güzel hileler bugün hala geçerli. Ancak en sevdiğim yaklaşım, sitelerinizin medyasını veritabanıyla birlikte itmenize ve çekmenize izin veren WP Migrate DB Pro için Medya Dosyaları eklentisini kullanmaktır.
Yerel SSL
2017'de Chrome, tüm .dev alan adlarını yerel ana bilgisayar siteleri için bu TLD'yi kullanan çok sayıda geliştiriciyi etkileyen HTTPS'ye yönlendirmeye başladı. Firefox 2018'de de aynı şeyi yaptı. Geliştiricilerin aniden yerel siteleri için SSL sertifikaları oluşturmaları gerekti.
Ancak yerel olarak bir sertifikaya sahip olmanın tek nedeni bu değil. Sorunları tam olarak giderebildiğinizden emin olmak için üretim sitenizi olabildiğince yakın bir şekilde çoğaltmak iyi bir fikirdir. Örneğin, site SSL ile dağıtılana kadar karma içerik uyarıları belirgin olmayacaktır. Yerel SSL'nin başka bir nedeni, HTTPS gerektiren web kancaları veya oAuth entegrasyonları gibi üçüncü taraf hizmetlerle entegrasyondur.
Yerel bir SSL sertifikası almanın çeşitli yolları vardır ve bu, geliştirme ortamınız için ne kullanmayı seçtiğinize bağlı olabilir. Valet kullanıyorsanız, site için SSL'yi açmak için valet secure safe CLI komutunu kullanabilirsiniz. Local ve MAMP Pro, doğrudan kullanıcı arayüzünde ana bilgisayar için bir sertifika oluşturma ve kullanma yeteneğine sahiptir. Biraz daha bilgi sahibi olmak istiyorsanız, SSL sertifikaları oluşturma ve bir sertifika yetkilisi oluşturma kılavuzumuza göz atın.
hata ayıklama
Benim düşünceme göre, bir site için bir WordPress geliştirme ortamına sahip olmanın en büyük faydalarından biri, problemlerde hata ayıklamayı kolaylaştırmaktır. FTP erişimi ve error_log satırları ile donanmış canlı bir sitede bir sorunu çözmeye çalıştıysanız, bunun ne kadar sıkıcı ve zahmetli olabileceğini bilirsiniz.
Hata ayıklama için bir WordPress geliştiricileri araç kutusundaki temel araç WP_DEBUG'dur. Bunu yerel wp-config.php dosyanızda WP_DEBUG_LOG ile birlikte açmak, sitenin wp-content/debug.log debug.log dosyasına tüm PHP hatalarını, bildirimlerini ve uyarılarını yazacaktır:
define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); define('WP_DEBUG_DISPLAY', false);
WP_DEBUG varsayılan olarak kapalı olmasına ve genellikle canlı siteler için açık olmamasına rağmen, gerçekte meydana gelen hataları yakalamak için üretim sitelerinde aynı kodu kullanmanızı ve günlükleri daha iyi görebilmeniz için Papertrail gibi bir hizmet kullanmanızı öneririm. .
Canlı veritabanının yeni bir senkronizasyonu ve WP_DEBUG'ın açık olduğu yerel olarak çalışan bir siteye sahip olmak, hata ayıklama sürecini çok daha kolay ve daha güvenli hale getirir! Xdebug gibi bir hata ayıklama aracı kullanarak birleştiğinde, hataları yeniden oluşturmak ve izlemek için çok daha donanımlısınız.
Xdebug, belirli kod satırlarında kesme noktaları ayarlamanıza olanak tanır, böylece bu kod satırları bir istek tarafından yürütüldüğünde yürütme duraklatılır ve tüm değişkenler ve globaller hakkında bir fikir edinerek neyin olmadığını anlamanıza yardımcı olur. set, hangi dizinin aslında bir nesne olduğu veya hangi kod parçasının bozuk olduğu.
Diğer İpuçları
Bir WordPress geliştirme ortamı çalıştırırken göz önünde bulundurmanız gereken, iş akışınızı iyileştirecek birkaç şey daha vardır.
E-posta
Canlı siteler için, e-posta göndermeyi işlemek için işlemsel bir e-posta hizmeti eklentisi kullanmanızı öneririm, ancak bu hizmet aracılığıyla yerel sitenizden e-posta göndermek istemezsiniz. Kullanımınıza ek olarak maliyet artışının yanı sıra, yerel sitenizden yanlışlıkla bir e-posta gönderilirse, müşterilere yanlışlıkla e-posta göndermek istemezsiniz.
Geliştirme ve test siteleriniz için güvenli bir e-posta ortamı sağlayan Mailtrap'ın büyük bir hayranıyım. Kişisel projeler için ücretsiz bir planı vardır ve e-postalarınızı SMTP sunucuları aracılığıyla kendi korumalı e-posta gelen kutunuza göndermenize olanak tanır.
Tüm sitelerimde, işlemsel e-posta eklentisini devre dışı bırakmak ve site üretim dışı bir ortamda çalışırken WordPress'e Mailtrap aracılığıyla e-posta göndermesini söylemek için bu mu-eklentisini ekliyorum:
<?php If ( 'production' === wp_get_environment_type() ) { return; } add_filter( 'option_active_plugins', function ( $plugins ) { if ( ! is_array( $plugins ) || empty( $plugins ) ) { return $plugins; } foreach ( $plugins as $key => $plugin ) { if ( 'mailgun/mailgun.php' === $plugin ) { unset( $plugins[ $key ] ); } } return $plugins; } ); add_action( 'phpmailer_init', 'mailtrap' ); function mailtrap( $phpmailer ) { $phpmailer->isSMTP(); $phpmailer->Host = 'smtp.mailtrap.io'; $phpmailer->SMTPAuth = true; $phpmailer->Port = 2525; $phpmailer->Username = '{mailtrap_username}'; $phpmailer->Password = '{mailtrap_password}'; }
Eklentiler
Yerel WordPress sitelerime her zaman kuracağım birkaç WordPress eklentisi var:
- Query Monitor – yavaş WordPress sitelerinde hata ayıklamak, yavaş veya yinelenen SQL sorguları bulmak ve koddaki darboğazları araştırmak için vazgeçilmez eklentim.
- Hata Ayıklama Çubuğu – doğrudan yönetici çubuğundan istekler, önbellek ve diğer WordPress site bilgileri hakkında fikir edinmek için harika.
- WP Crontol – size WordPress cron zamanlama sistemi hakkında bilgi verir, böylece programlanmış olaylarla ilgili sorunları anlayabilirsiniz.
Sitelerim Composer (WordPress çekirdeği ve eklentileri) ile yönetildiğinden, canlı siteye girmemeleri için bunları geliştirici bağımlılıkları olarak yüklüyorum. Örneğin:
composer require --dev wpackagist-plugin/query-monitor
Ardından, WP Migrate DB Pro profillerimde “Active_plugins” ayarını etkinleştiriyorum, böylece canlı site veritabanını yerelime geri çektiğimde bu geliştirme eklentileri devre dışı bırakılmayacak.
WP-CLI
WP-CLI son derece kullanışlı bir araçtır. WordPress sitelerini komut satırından yönetmenize izin vererek hayatı kolaylaştırır. WordPress geliştirme ortamınızda kullanışlı olabilecek birkaç komut vardır:
- wp core install – WordPress'i tek komutta kurun
- wp site boş – gönderiyi, terimleri ve yorum tablolarını keser, ancak seçenekler tablosunu olduğu gibi bırakır
- wp db reset – veritabanındaki tüm tabloları bırakarak yeni bir kurulum yapmanızı sağlar
- wp sunucusu – belirli bir WordPress kurulumu için PHP'nin yerleşik web sunucusunu başlatın.
Git
Çalıştığım WordPress buluşmasında birçok serbest çalışanla konuşuyorum. Birçoğu, bir ekip yerine kendi başlarına çalıştıkları için Git'i öğrenmeleri ve kullanmaları gerekmediğine inanıyor. Sürüm kontrolünü yalnızca yararlı veya işbirliği için gerekli bir şey olarak görürler. Ancak, siteleriniz için git kullanmanın faydaları solo geliştiriciler için de geçerlidir.
Site projenizin sürümünü kontrol altında tutmak ve GitHub veya Bitbucket gibi dağıtılmış bir sistemde depolamak, kodunuzun yedeklerini alacağınız anlamına gelir. Geri almanız gereken canlı sitede bazı değişiklikler mi uyguladınız? Site yalnızca dosya sisteminizde yaşıyorsa, değişikliklerinizi geri almak için bu çok fazla CMD+Z'dir. Git ile kod sürümü kontrollü olarak, son taahhütlerinizi geri alabilir veya dosyalarınız için son değişikliklerin farkını kolayca görebilirsiniz.
WordPress'in bir geliştirme ortamı kurmak için önerdiği diğer bazı kaynaklara göz atın.
Toplama
Umarım bu, WordPress geliştirme ortamları ve WordPress'i yerel olarak çalıştırma konusunda kapsamlı bir rehber olmuştur. Hem hazırlama ortamını hem de üretim ortamını çalıştırmak için en iyi uygulamalara yönelik kılavuzlar üzerinde çalışacağım – bu nedenle bunlara dikkat edin.
Favori geliştirme ortamınız hangisi? Kaçırdığım yerel kalkınma için herhangi bir ipucu ve püf noktası var mı? Aşağıdaki yorumlarda bana bildirin.