Eğitimler

WordPress'i Terminalden Yönetmek için Temel WP-CLI Komutları

WP-CLI ile güncelleme, arama-değiştirme ve şifre sıfırlamayı saniyeler içinde yapın. Site yöneticileri için gerçek komutlar, yaygın hatalar ve pratik çözümler.

Eğitimler

WordPress Panonuz Zamanınızı Yediğinde

Saat sabah 3 ve siteniz "Veritabanı bağlantısı kurulamadı" hatasıyla çöktü. Sorunu çözmek için bir eklentiyi devre dışı bırakmanız gerekiyor, ancak panele giriş sayfası bile açılmıyor. Ya da 200 makaleniz var ve hepsinde alan adını example.com'dan example.ir'ye değiştirmeniz gerekiyor. Panelden bu işlem 200 kez manuel düzenleme demek. WP-CLI ile her iki iş de bir dakikadan kısa sürede tamamlanır.

WP-CLI, WordPress panelinde yaptığınız hemen her şeyi — ve panelden yapamayacağınız birçok işi — terminalden yapmanızı sağlayan bir komut satırı aracıdır. Bu makale, şu anda bu sorunlardan biriyle boğuşan bir yönetici içindir, "genel bir bilgi" edinmek isteyenler için değil.

WP-CLI Kurulumu ve Sağlık Kontrolü

Günümüzde çoğu Linux hosting sağlayıcısı WP-CLI'yi önceden yüklenmiş olarak sunar. Önce kontrol edin:

wp --info

Çıktı PHP sürümünü ve WordPress kurulum yolunu içeriyorsa hazırsınız. Değilse, kurun:

curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp

Kurulumdan sonra sürümü kontrol edin:

wp --version

Çıktı WP-CLI 2.11.0 gibi bir şey olmalıdır. Sürüm 2.8'den eskiyse yükseltin; eski sürümler PHP 8.2 ve üzeriyle sorun yaşar.

Önemli bir not: WP-CLI, WordPress dosyalarının sahibi olan kullanıcıyla çalıştırılmalıdır. Root ile çalıştırırsanız, oluşturulan dosyaların sahibi root olur ve daha sonra panelden yükleme veya düzenleme sırasında "permission denied" hatasıyla karşılaşırsınız. İşte burada hata yapıyorlar: Siteyi www-data kullanıcısıyla çalıştırıyorlar ama WP-CLI'yı root ile çağırıyorlar. Sonuç? Bir gün sonra güncellenmesi gereken bir eklenti güncellenemiyor ve kimse nedenini anlamıyor.

Komut Satırından Çekirdek, Eklenti ve Tema Güncelleme

Gerçek trafik alan bir sitede panelden güncelleme yapmak risklidir: sayfa işlem ortasında yenilenir, bağlantı kopar ve iş yarım kalır. Terminalden önce yedek alın, sonra güncelleyin.

Her şeyi güncellemek için — çekirdek, eklentiler, temalar ve çeviri dosyaları — tek bir komut yeterlidir:

wp core update
wp plugin update --all
wp theme update --all
wp language core update

Sadece hangi güncellemelerin olduğunu görmek istiyorsanız, hiçbir şeyi değiştirmeden:

wp plugin list --update=available

Çıktı, hangi eklentilerin yeni sürüme sahip olduğunu ve her birinin mevcut sürümünü gösteren bir tablo sunar. Büyük bir güncellemeden önce bu komutu çalıştırarak güncellenecek eklentinin PHP sürümünüzle uyumlu olduğundan emin olun.

Çoğu kişinin bilmediği bir not: Siteniz yönetilen WordPress hosting kullanıyorsa, güncelleme otomatik olarak hosting tarafından yapılabilir ve manuel wp core update komutu "Another update is already in progress" hatası verebilir. Bu durumda hosting işleminin bitmesini bekleyin, sonra komutu çalıştırın.

Veritabanında Arama ve Değiştirme

Alan adı değişikliği, HTTP'den HTTPS'ye geçiş veya siteyi geliştirme ortamından ana sunucuya taşıma — hepsinin ortak bir ihtiyacı vardır: veritabanındaki tüm tablolarda bir metni değiştirmek. Panelden bu ya imkansızdır ya da ağır eklentiler gerektirir.

Ana komut şudur:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --precise

--all-tables bayrağı, yalnızca varsayılan WordPress tablolarını değil, tüm tabloları ifade eder. --precise bayrağı, değiştirmenin yalnızca tam metinlerde yapılmasını sağlar, alt metinlerde değil. Bu bayrak olmadan, metniniz example.com ise ve veritabanında www.example.com da varsa, sonuç bozulur.

Gerçek çalıştırmadan önce --dry-run bayrağıyla test edin:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' --all-tables --dry-run

Bu komut hiçbir şeyi değiştirmeden yalnızca bulunan eşleşme sayısını raporlar. Gördüğünüz sayı beklentinizle uyumlu olmalıdır. Sıfırsa, metni yanlış yazdınız veya doğru alan adını değiştiriyorsunuz.

Ciddi bir uyarı: Siteniz Object Cache kullanıyorsa — örneğin Redis — search-replace'ten sonra önbelleği temizlemelisiniz. Aksi takdirde site eski içeriği önbellekten sunar ve komutun çalışmadığını düşünürsünüz. WP-CLI ile önbellek temizleme komutu:

wp cache flush

search-replace'te Yaygın Hata

Gördüğüm en yaygın hata, birinin wp search-replace komutunu canlı bir sitenin veritabanında yedek almadan çalıştırması ve ardından değiştirdiği metnin, değiştirilmemesi gereken makale içeriklerinde de bulunduğunu fark etmesidir. Örneğin, example.com yerine example.ir koymak, "example.com ve example.org arasındaki fark" hakkında yazılmış bir makalenin metninde de değişiklik yapabilir. Çözüm: Her zaman önce yedek alın, sonra --dry-run ile test edin ve şüpheye düşerseniz yalnızca post_content gibi belirli sütunları değiştirmek için --include-columns bayrağını kullanın.

Terminalden Kullanıcı Şifresini Sıfırlama

Bir kullanıcı şifresini unuttu ve kurtarma e-postası spam kutusuna düştü. Ya da yönetici hesabı hacklendi ve şifreyi hızlıca değiştirmeniz gerekiyor. Panelden giriş yapamazsınız. WP-CLI bunu tek satırda yapar:

wp user update 1 --user_pass='YourNewStrongPassword'

1 sayısı yönetici kullanıcı kimliğidir. Kimliğin kime ait olduğunu bilmiyorsanız, önce kullanıcı listesini görün:

wp user list --fields=ID,user_login,roles

Bu komut, hangi kullanıcının hangi role sahip olduğunu gösteren bir tablo sunar. Sıfırlamadan sonra kullanıcıya, giriş sayfasındaki "Lost your password?" seçeneğini kullanarak kendi yeni şifresini seçmesini söyleyin. Sizin belirlediğiniz şifre yalnızca ilk giriş içindir.

Yönetici rolüyle yeni bir kullanıcı oluşturmak istiyorsanız:

wp user create john john@example.com --role=administrator --user_pass='TempPass123'

Oluşturduktan sonra kullanıcıdan şifreyi değiştirmesini isteyin. Sunucu terminal geçmişinde kalan geçici bir şifreyle asla bırakmayın.

Siteyi Çökerten Eklentiyi Devre Dışı Bırakma

Site ölümcül hata (WSOD) verdi ve sayfa beyaz. Panelden giriş imkansız. WP-CLI ile tüm eklentileri tek seferde devre dışı bırakabilirsiniz:

wp plugin deactivate --all

Site geri döner. Şimdi suçluyu bulmak için tek tek etkinleştirin:

wp plugin activate woocommerce

Her etkinleştirmeden sonra siteyi kontrol edin. Hata geri gelirse, suçlu o eklentidir. Bu teşhis yöntemi, özellikle hata günlüklerde kaydedilmiyorsa, günlüklere bakmaktan çok daha hızlıdır.

Yalnızca belirli bir eklentiyi devre dışı bırakmak istiyorsanız:

wp plugin deactivate akismet

Cron Yönetimi ve Otomatik Temizlik

WordPress, zamanlanmış görevleri kendi cron sistemi üzerinden çalıştırır. Site yoğun olduğunda bu cron'lar çalışmayabilir veya birden çok kez çalışabilir. WP-CLI ile kuyrukta hangi olayların olduğunu görebilirsiniz:

wp cron event list

Takılıp sürekli çalışan bir olay varsa, onu silin:

wp cron event delete event_name

Bekleyen tüm olayları manuel olarak çalıştırmak için:

wp cron event run --due-now

Bu komut özellikle siteyi yeni bir sunucuya taşıdıktan sonra kullanışlıdır, çünkü eski cron'lar eski alan adına işaret ediyor olabilir.

Burada Hata Yapıyorlar: WP-CLI'yı Yanlış Dizinde Çalıştırma

WP-CLI ile pratik çalışmada gördüğüm en büyük hata, yöneticinin komutu WordPress kök dizini dışında bir klasörden çalıştırmasıdır. Örneğin, /home/user dizininden wp plugin list komutunu çalıştırır ve "Error: This does not seem to be a WordPress installation" hatasını alır. Çözüm basit: WordPress klasörüne gidin (cd /var/www/html) veya --path bayrağını kullanın:

wp plugin list --path=/var/www/html

Siteniz bir alt dizine kuruluysa — örneğin example.com/blog — ve kökten komut çalıştırmak istiyorsanız, --path bayrağını alt dizin yoluna verdiğinizden emin olun. Aksi takdirde WP-CLI, site kökünün bulunduğunuz yer olduğunu düşünür ve hata verir.

Tehlikeli İşlemlerden Önce Hızlı Yedek

Her search-replace veya büyük güncellemeden önce veritabanının yedeğini alın. WP-CLI ile bu tek satırdır:

wp db export /backup/site-$(date +%Y%m%d).sql

Bu komut, SQL dosyasını adında tarihle kaydeder. Bir şey bozulursa, geri yükleyin:

wp db import /backup/site-20250615.sql

Dosya yedekleri de önemlidir, ancak WP-CLI yalnızca veritabanını yönetir. Dosyalar için rsync veya benzeri araçlar kullanın. İyi bir alışkanlık: Her çekirdek güncellemesinden önce hem veritabanını hem de wp-content dosyalarını yedekleyin. Güncellemeden sonra bir hata görürseniz, geri yükleyin ve sorunu test ortamında çözün.

Paylaşımlı Hosting'de WP-CLI

Paylaşımlı hosting kullanıyorsanız ve WP-CLI önceden kurulu değilse, phar dosyasını kendi klasörünüzde tutabilir ve PHP ile çalıştırabilirsiniz:

php wp-cli.phar plugin list

Bu yöntem biraz daha yavaştır ancak çalışır. Paylaşımlı hosting'in ana sınırlaması, wp core download gibi bazı komutların bellek veya zaman aşımı kısıtlamaları nedeniyle çalışamamasıdır. Bu durumda, hosting sağlayıcınıza WP-CLI kurmasını isteyin veya ağır işleri özel Linux hosting üzerinde yapın. Siteyi yeni taşımayı düşünüyorsanız, ServerNet'in dokümantasyon ve bilgi tabanına göz atın.

WP-CLI ile Otomasyon

Komutları öğrendikten sonraki adım otomasyondur. Her hafta çalışan ve güncellemeleri uygulayan basit bir bash betiği:

#!/bin/bash
cd /var/www/html
wp db export /backup/weekly-$(date +%Y%m%d).sql
wp plugin update --all
wp theme update --all
wp core update

Bu betiği cron ile çalıştırın. Ancak önce önemli bir not: Otomatik eklenti güncellemeleri, bir eklenti yeni PHP veya WordPress sürümüyle uyumsuzsa siteyi bozabilir. Önerim: Çekirdek güncellemelerini otomatikleştirin, ancak eklentileri haftada bir manuel olarak kontrol edin. Ödeme ağ geçidi gibi kritik bir eklentiniz varsa, onu asla otomatik güncellemeye dahil etmeyin.

Güncellemelerden sonra site sağlığını izlemek için, uptime izleme araçları bir site çökerse size uyarı gönderebilir. Yanlış alarmlar olmadan kesinti uyarıları ayarlamak için site uptime izleme rehberine bakın.

WP-CLI ile Sorun Giderme

Site hata verdiğinde ancak günlükler hiçbir şey göstermediğinde, WP-CLI ayrıntılı bilgi verebilir:

wp db check

Bu komut veritabanı sağlığını kontrol eder. Bozuk bir tablo varsa raporlar. PHP ayarlarını kontrol etmek için:

wp eval 'echo ini_get("memory_limit");'

Bu komut memory_limit değerini gösterir. Site "Allowed memory size exhausted" hatası veriyorsa bu sayıyı kontrol edin. Modern WordPress için önerilen değer en az 256M'dir.

PHP hata günlüklerini canlı olarak görmek için:

wp debug

Bu komut son günlükleri gösterir ve dosyalarda aramaktan çok daha hızlı sorunu bulabilir.

Pratik Özet

WP-CLI, ustalaştığınızda yönetim işleri için artık paneli kullanmayacağınız bir araçtır. Güncelleme, search-replace, şifre sıfırlama, bozuk eklentiyi devre dışı bırakma — hepsi terminalden saniyeler içinde. Maliyeti? Bir gün öğrenme ve komut satırına alışma. Daha önce terminalle çalışmadıysanız, öğrenme eğrisi biraz vardır, ancak buna değer.

Yapmanız gereken ilk şey: Ana site değil, bir test sitesinde wp plugin list komutunu çalıştırın ve çıktıyı görün. Sonra wp db export deneyin ve SQL dosyasını açın. Bu iki komutla rahatladığınızda, gerisi kolaydır.

Siteniz SSH'si olmayan bir hostingdeyse veya WP-CLI kurulu değilse, hosting sağlayıcınızdan kurmasını isteyin. Kurmuyorlarsa, hosting değiştirme zamanı gelmiştir. Günlük işinizi bir saatten bir dakikaya indiren bir araç sizin hakkınızdır, bir ayrıcalık değil.

Sıkça Sorulan Sorular

WP-CLI nedir ve ne işe yarar?

WP-CLI, WordPress'i yönetmek için bir komut satırı aracıdır. Tarayıcıya ihtiyaç duymadan güncelleme, yedekleme, kullanıcı yönetimi, veritabanında arama ve değiştirme ve daha birçok işlemi yapabilirsiniz.

WP-CLI paylaşımlı hostingde çalışır mı?

Hosting sağlayıcısına bağlıdır. Bazı paylaşımlı hostingler WP-CLI'yi önceden kurulu sunar. Kurulu değilse, phar dosyasını indirip PHP ile çalıştırabilirsiniz, ancak bazı ağır komutlar kaynak kısıtlamalarıyla karşılaşabilir.

WP-CLI ile yönetici şifresini nasıl değiştiririm?

WordPress kök klasöründen wp user update 1 --user_pass='NewPassword' komutunu çalıştırın. 1 sayısı yönetici kullanıcı kimliğidir. Kimliğin kime ait olduğunu bilmiyorsanız, önce wp user list çalıştırın.

WP-CLI siteye zarar verir mi?

WP-CLI'nin kendisi siteye zarar vermez, ancak search-replace gibi komutlar yedek ve test olmadan çalıştırılırsa verileri bozabilir. Tehlikeli işlemlerden önce her zaman yedek alın ve --dry-run bayrağıyla test edin.

ServerNet Destek

ServerNet mühendislik ve yayın ekibi — altyapı, ağ ve web barındırma uzmanları.

WordPress Hosting
Paylaş:

Yorumlar 0

Henüz yorum yok — ilk siz olun!

Yorum bırakın

İlgili hizmet

WordPress Hosting

LiteSpeed Enterprise ve NVMe üzerinde WordPress'e özel altyapı — otomatik kurulum, güvenli güncelleme, staging ve sizi Google'da üstte tutan önbellek.