WordPress Sitenizi Git ve Composer ile Yönetme Bölüm 4 – WordPress'i Bir Alt Dizine Kurma

Bu dizinin 1. bölümünde, WordPress sitenizi Git'te nasıl depolayacağınızı ve yöneteceğinizi inceledik. 2. ve 3. bölümlerde, WordPress sitenizdeki temaları ve eklentileri yönetmek için Composer ve Git Alt Modüllerini kullanmaya baktık. Serinin bu son bölümünde, 1. bölümde yaptıklarımızı nasıl iyileştirebileceğimize bakacağız ve WordPress'in kendisini Composer veya Git Alt Modülü kullanarak bir alt dizinde saklayacağız.

Bir Bağımlılık Olarak WordPress

WordPress'i bir alt dizinde depolamanın avantajları nelerdir? Pekala, WordPress'in kendisine bir bağımlılık gibi davranarak Git deponuzun yapısını daha modüler ve temiz hale getirebilirsiniz. WordPress'i Git deponuzun dışında tutarak, kodu çoğaltmanız gerekmez ve iş akışınızın bir parçası olarak WordPress'te güncellemeler yapmanız gerekmediğinden güncellemeler çok daha kolay hale gelir.

Iain, WP-CLI veya Composer kullanarak bir alt dizine WordPress çekirdeğinin nasıl kurulacağını ayrıntılı olarak anlattığında, yazısında bazı avantajlardan bahsetti. Bu yazıda onun Composer örneğini geliştireceğiz ve Git Alt Modüllerini kullanarak nasıl yapılacağına da göz atacağız.

WordPress'i Yeniden Yapılandırma

WordPress'i bir alt dizine kurarken hangi yönü seçerseniz seçin, çalışması için yapılması gereken belirli bir miktarda yeniden yapılandırma vardır. Temelde üç şeyin değişmesi gerekiyor:

1. WordPress'in bir index.php dosyası kullanılarak yeni konumundan önyüklenmesi gerekiyor
2. wp-content klasörünün WordPress kurulum alt dizininin dışına taşınması gerekiyor
3. Tüm ortam/yapılandırma dosyalarının (örn. .htaccess / wp-config.php ) de yeni konuma taşınması gerekir.

Pek çok modern web uygulaması, herhangi bir hassas yapılandırma bilgisini bir URL aracılığıyla doğrudan erişilemeyecek şekilde "genel" dizinin üzerine taşımanın en iyi uygulama olduğunu düşünür. Bunu burada da yapacağız. Yani dizin yapımız şimdi şöyle görünmelidir:

 / | |-- public/ | |-- wp-content/ | |-- wp/ <-- Our subdirectory install location for WordPress (not stored in Git repo) | |-- .htaccess | |-- index.php | `-- wp-config.php | |-- .gitignore |-- composer.json <-- If using Composer `-- local-config.sample.php

1. Önyükleme indeksi.php

Bu kısım nispeten basittir. WordPress'i public/wp alt dizinine kuracağız, bu yüzden web sunucumuza WordPress'i nerede bulacağını söylememiz gerekiyor. Her şey ana index.php dosyası üzerinden yönlendirildiği için (bkz. .htaccess ) aşağıdaki içeriğe sahip bir önyükleme index.php dosyası oluşturabiliriz:

 <?php // WordPress bootstrap define( 'WP_USE_THEMES', true ); require( './wp/wp-blog-header.php' );

2. wp içeriğini taşıyın

Bunu wp-content dizinini public/wp-content content dizinine taşıyarak başarıyoruz. WordPress, bu yeni wp-içerik konumunu kullanmasını istediğimizi bilmeyecek, bu yüzden yeni public/wp-config.php dosyamızda WP_CONTENT_DIR ve WP_CONTENT_URL ayarlayarak bunu söylememiz gerekiyor (aşağıya bakın).

3. Ortam yapılandırması

Yukarıdaki kök dizinde local-config.sample.php dosyasını fark edeceksiniz. Bu teknik olarak gerekli olmasa da, ortama özgü yapılandırma bilgilerini (veritabanı kimlik bilgileri ve gizli anahtarlar gibi) public/wp-config.php içinde depolanan "genel" yapılandırma bilgilerinden (tablo öneki ve wp-içerik konumu).

Buradaki fikir, public/wp-config.php dosyasının herhangi bir "genel" yapılandırma bilgisini tutması ve ardından gerektiği gibi doğru "ortam" yapılandırma dosyasını yüklemesidir. Bu nedenle, üretim siteniz için varsa public/wp-config.php tarafından yüklenebilen bir production-config.php dosyasını dağıtabilirsiniz (Güvenlik amacıyla Git deposunda saklamıyoruz) ve production-config.php mevcut değil, yerel bir geliştirme ortamında çalıştığınızı varsayan local-config.php geri dönün.

Yeni public/wp-config.php dosyamızın içeriği şöyle görünmelidir:

 <?php ini_set( 'display_errors', 0 ); // =================================================== // Load database info and local development parameters // =================================================== if ( file_exists( dirname( __FILE__ ) . '/../production-config.php' ) ) { define( 'WP_LOCAL_DEV', false ); include( dirname( __FILE__ ) . '/../production-config.php' ); } else { define( 'WP_LOCAL_DEV', true ); include( dirname( __FILE__ ) . '/../local-config.php' ); } // ======================== // Custom Content Directory // ======================== define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' ); define( 'WP_CONTENT_URL', 'http://' . $_SERVER['HTTP_HOST'] . '/wp-content' ); // ================================================ // You almost certainly do not want to change these // ================================================ define( 'DB_CHARSET', 'utf8' ); define( 'DB_COLLATE', '' ); // ================================ // Language // Leave blank for American English // ================================ define( 'WPLANG', '' ); // ====================== // Hide errors by default // ====================== define( 'WP_DEBUG_DISPLAY', false ); define( 'WP_DEBUG', false ); // ========================= // Disable automatic updates // ========================= define( 'AUTOMATIC_UPDATER_DISABLED', false ); // ======================= // Load WordPress Settings // ======================= $table_prefix = 'wp_'; if ( ! defined( 'ABSPATH' ) ) { define( 'ABSPATH', dirname( __FILE__ ) . '/wp/' ); } require_once( ABSPATH . 'wp-settings.php' );

Kullanmak için local local-config.sample.php local-config.php olarak yeniden adlandırmamız gerekiyor. Bunun gibi bir şeye benzemeli:

 <?php define( 'DB_NAME', 'wordpress' ); define( 'DB_USER', 'exampleuser' ); define( 'DB_PASSWORD', 'examplepassword' ); define( 'DB_HOST', 'localhost' ); ini_set( 'display_errors', E_ALL ); define( 'WP_DEBUG_DISPLAY', true ); define( 'WP_DEBUG', true ); define('AUTH_KEY', ',7jxG`)ZYM/m1OB6G/&z)gL=oW={,B1-&xcGuySKE.vQh_-fI)j$y^222Hs8cR&W'); define('SECURE_AUTH_KEY', '=3/+qt|eD2>(|[email protected]|vp&8T*n6;ZKZ1[91m`a^-PbV+wzbiK ,gyNe&iTpHI(+1'); define('LOGGED_IN_KEY', '[email protected]=lv&j!.~IMD_D;%gzG>NSYfNG-K [email protected]]cp2|jYCgHV;>dSe[. u|[email protected]]'); define('NONCE_KEY', '=d#!`FCws;6W-z%j%:[email protected]~U|k[PoA8Lb+.r4yf_fi*1bJXMQm2bu{[email protected]'); define('AUTH_SALT', '|~mjb|}FFR~b=jcF--;6.`KEO|wP>f&|+2s-#4]6QzY7o4#^y2&9mabHT..DR<O-'); define('SECURE_AUTH_SALT', '+YmVlzrBIw!kMkq(j3p&5+IU17>+ea[E9ZNdH-*k)(cCc74N^7CVd|ol(*^i]do!'); define('LOGGED_IN_SALT', 'rG9_QAj+~/q2UA*5Fk(Q](/NY&IG}[Z8&uf+Q{;YB/uA0Q.iFU:UW *OCN;|FUi1'); define('NONCE_SALT', 'uBW!%ut#F]]5Etl3MwAi|;9 82#qY9(x:])4BU*y{4BrSHk^hT&E6>m<`)zwsaIs');

Yapmak istediğimiz son bir şey, .gitignore dosyamızdaki doğru dosya ve klasörleri yok saydığımızdan emin olmaktır, böylece Git depomuzda yalnızca gerekli dosya ve klasörler saklanır. /vendor klasörü, bestecinin bağımlılıklarını depolayacağı yerdir, bu yüzden onu da yok saymak istiyoruz.

 /public/wp /vendor production-config.php local-config.php

Artık yapımızı oluşturduğumuza göre, devam edip WordPress'i kurabiliriz.

Composer kullanarak WordPress'i yükleyin

Bölüm 2'de incelediğimiz gibi Composer, PHP uygulamanızdaki paketleri yönetmenin harika bir yoludur ve aynı şey WordPress'i bir bağımlılık olarak kullanmak istiyorsanız da geçerlidir. Bölüm 2'de olduğu gibi, temalarımız ve eklentilerimiz için WP Packagist kullanacağız (bu örnekte onları hariç tutmama rağmen), ancak bu sefer aynı zamanda Composer uyumlu bir kopyası olan johnpbloch/wordpress paketini de ekleyeceğiz. WordPress deposu. composer.json dosyamız şöyle görünmelidir:

 { "repositories": [ { "type": "composer", "url": "http://wpackagist.org" } ], "require": { "php": ">=5.4", "composer/installers": "1.*", "johnpbloch/wordpress": "4.3.*" }, "extra": { "wordpress-install-dir": "public/wp", "installer-paths": { "public/wp-content/mu-plugins/{$name}/": ["type:wordpress-muplugin"], "public/wp-content/plugins/{$name}/": ["type:wordpress-plugin"], "public/wp-content/themes/{$name}/": ["type:wordpress-theme"] } } }

Burada dikkat edilmesi gereken üç şey var:

1. WordPress'in 4.3.* sürümünü yüklüyoruz. Bu, Composer'ın WordPress 4.3.x'in en son sürümünü yükleyeceği, ancak 4.4 ve sonraki sürümleri (yayınlandıktan sonra) yüklemeyeceği anlamına gelir. Bu, Composer'ın yanlışlıkla yapılan değişiklikleri yüklemesini önlemek içindir. composer update kullanırken WordPress'in her zaman en son sürüme güncellemesini istiyorsanız, bunu * olarak değiştirin.
2. "Ekstra" ayarların içinde, Composer'a "wordpress-install-dir" aracılığıyla public/wp yeni alt dizin konumumuza WordPress'i kurmasını söylüyoruz.
3. Ayrıca Composer'a wp-content dizinimizin konumunun public/wp-content olarak değiştiğini ve temalarımızı ve eklentilerimizi buraya yüklemesi gerektiğini söylemek için “installer-paths” yönergesini kullanıyoruz.

Çok fazla iş yapmış gibi görünebiliriz ama böyle bir kurulumun avantajını burada görmeye başlıyoruz. Şimdi WordPress'i composer install veya WordPress'i güncellemek için composer update çalıştırmamız gerekiyor. Dağıtım stratejileri bu makalenin kapsamı dışındadır ancak umarım bu tür kurulumun dağıtımları ne kadar güçlü ve kolay hale getirdiğini görebilirsiniz.

Git Alt Modüllerini kullanarak WordPress'i yükleyin

Besteci senin işin değilse Git Alt Modüllerini kullanarak aynı sonucu elde edebiliriz. Bir composer.json dosyası kullanmak yerine, WordPress'i bir alt dizine kurmak için WordPress'i Git Alt Modülü olarak ekleyebiliriz (3. bölümde temalar ve eklentiler için yaptığımız gibi).

WordPress'i bir alt modül olarak eklemek için projenin kökünden aşağıdaki komutu çalıştırın:

 git submodule add https://github.com/WordPress/WordPress public/wp

Kararlılık nedenleriyle, WordPress'in kararlı bir sürümünü yüklememiz önerilir. Bunu belirli bir etiketi kontrol ederek yapabiliriz:

 cd public/wp git checkout tags/4.3.1 cd ../..

Alt modüllerde yaptığımız değişiklikleri taahhüt etmemiz gerektiğini unutmayın:

 git commit -am "Install WordPress 4.3.1 as a submodule"

WordPress'i güncellemek benzer bir iş akışıdır:

 cd public/wp git fetch -a git checkout tags/4.3.2 cd ../.. git commit -am "Update WordPress to 4.3.2"

İşte bu şekilde WordPress'i Git Alt Modülü olarak kurabiliyor ve yönetebiliyoruz.

Bu noktada, yukarıdaki yöntemlerin her ikisinde de kullandığım bazı kavramların Mark Jaquith'in Skeleton deposuna dayandığını belirtmekte fayda var, bu tür kurulumlara biraz daha yakından bakmak istiyorsanız kesinlikle kontrol etmeye değer.

Umarım WordPress sitenizi Git ve Composer ile yönetmeye yönelik bu diziden keyif almışsınızdır ve bu iş akışının bir kısmını veya tamamını alıp kendi WordPress sitelerinize uygulayabilirsiniz.

Bu dizide ele aldıklarımızın Git'te WordPress'i yönetmenin mutlaka "doğru" yolu olmadığını, Git ve WordPress'i birlikte kullanmanın yalnızca bir yolu olduğunu unutmayın. İşinize yarayan parçaları alın ve kendi iş akışınızı yaratın ve gerisini yok sayın veya bu iş akışını iyileştirin. O size kalmış.

Bu seride ele almadığım herhangi bir ipucu veya öneriniz var mı? Yorumlarda bana bildirin.