WordPress Yerel Geliştirme Ortamı Kurulumu: Local ile Çalışmaya Başlayın

Yıllardır WordPress geliştirme yapan biri olarak şunu net söyleyebilirim: doğru local geliştirme ortamı kurmadan ciddi bir eklenti veya tema geliştirme süreci yönetmek, kör uçuş yapmaya benziyor. Bir müşteri sitesinde “hızlıca test edeyim” diye denediğiniz kod, production ortamını çökertebilir. Bu yazıda, WordPress local geliştirme ortamını nasıl kurduğumu, hangi araçları tercih ettiğimi ve neden bu konfigürasyonları seçtiğimi aktaracağım.

Neden Local Geliştirme Ortamı Şart?

Production sunucusunda geliştirme yapmanın acısını çekmiş herkes anlıyor bu soruyu. WooCommerce eklentisi geliştirirken bir syntax hatası tüm checkout akışını bozabilir. Müşteri siparişleri duruyor, telefon çalıyor, panikle FTP’ye bağlanıp dosyayı geri alıyorsunuz. Bu senaryo kulağa tanıdık geliyor mu?

Local ortamın avantajları:

  • Hız: Dosya değişiklikleri anında görünür, CDN veya cache katmanı yok
  • Güvenlik: Yarım kalmış özellikler, debug logları, test verileri dışarıya sızmaz
  • Özgürlük: PHP versiyonunu değiştirin, farklı MySQL sürümleri deneyin, istediğiniz eklentiyi kurun
  • Versiyon kontrolü: Git workflow’unu rahatça uygulayın, her şeyi commit’leyin
  • Çoklu proje: 10 farklı WordPress kurulumunu aynı anda çalıştırın

Araç Seçimi: Ne Kullanmalı?

Piyasada birçok seçenek var. XAMPP, WAMP, MAMP, Local by Flywheel, Laragon, Docker tabanlı çözümler… Her birinin güçlü ve zayıf yanları var.

Docker tabanlı geliştirme en esnek çözüm, ancak WordPress eklenti geliştirmeye yeni başlayanlar için öğrenme eğrisi dikik. Onu ayrı bir yazıya bırakalım.

Local by Flywheel (artık sadece “Local” olarak biliniyor) Windows ve macOS için kullanışlı bir GUI sunuyor, ancak kurumsal ortamlarda lisans sorunları çıkabiliyor ve arka planda ne döndüğünü tam göremiyorsunuz.

Laragon Windows için gerçekten harika bir seçenek. Hafif, hızlı, ve PHP/MySQL sürümlerini kolayca değiştirebiliyorsunuz. Türkiye’deki birçok ajans bu aracı kullanıyor.

Ben bu yazıda iki yaklaşımı ele alacağım: Laragon ile hızlı başlangıç ve Docker Compose ile kontrollü ortam. İkisini de aktif kullanıyorum, projeye göre seçim yapıyorum.

Laragon ile WordPress Kurulumu

Laragon Kurulumu ve Temel Ayarlar

Laragon’u [laragon.org](https://laragon.org) adresinden indirin. Full versiyonu tercih edin, Apache, Nginx, MySQL, PHP ve birçok ek araç geliyor.

Kurulumdan sonra ilk yapmanız gereken PHP sürümünü ayarlamak. WordPress 6.x için PHP 8.1 veya 8.2 öneriyorum. Laragon’da sağ tıklayıp PHP sürümünü değiştirebilirsiniz, ancak eğer sisteminizde birden fazla proje varsa ve her biri farklı PHP versiyonu gerektiriyorsa bu önemli.

# Laragon terminal üzerinden PHP versiyonunu kontrol edin
php -v

# Hangi php.ini dosyasının kullanıldığını görmek için
php --ini

Laragon’un C:laragonetcphpphp8.1.xphp.ini dosyasını açın ve şu değerleri geliştirme ortamı için optimize edin:

; Geliştirme ortamı php.ini ayarları
error_reporting = E_ALL
display_errors = On
display_startup_errors = On
log_errors = On
error_log = "C:/laragon/logs/php_error.log"

; Upload limitleri - WooCommerce için önemli
upload_max_filesize = 64M
post_max_size = 64M
max_execution_time = 300
memory_limit = 256M

; OPcache - geliştirmede kapatmak mantıklı olabilir
opcache.enable = 0

WordPress Kurulumu

Laragon’un güzel özelliği, C:laragonwww altına bir klasör oluşturduğunuzda otomatik olarak virtual host oluşturması. Yani myproject klasörü oluşturursanız, myproject.test adresi otomatik erişilebilir oluyor.

# Laragon terminal üzerinden WP-CLI ile WordPress kurulumu
# WP-CLI'yı önce indirin: https://wp-cli.org

cd C:laragonwww
mkdir myproject
cd myproject

# WordPress dosyalarını indir
wp core download --locale=tr_TR

# wp-config.php oluştur
wp config create --dbname=myproject --dbuser=root --dbpass="" --dbhost=localhost

# Veritabanını oluştur
wp db create

# WordPress'i kur
wp core install --url="http://myproject.test" --title="My Project" --admin_user="admin" --admin_password="guclu_sifre_123" --admin_email="[email protected]"

WP-CLI olmadan yaşayamazsınız artık. Bunu söylüyorum çünkü yıllarca phpMyAdmin ve admin paneli üzerinden yaptığım şeyleri WP-CLI ile dakikalar içinde hallettim.

Docker Compose ile Profesyonel Kurulum

Birden fazla projeyi yönetiyorsanız veya takım halinde çalışıyorsanız Docker daha iyi bir seçim. Aşağıdaki yapılandırma, eklenti geliştirme için optimize edilmiş bir ortam sunuyor.

# docker-compose.yml
version: '3.8'

services:
  db:
    image: mysql:8.0
    volumes:
      - db_data:/var/lib/mysql
    restart: always
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: wordpress
      MYSQL_USER: wpuser
      MYSQL_PASSWORD: wppassword
    ports:
      - "3306:3306"

  wordpress:
    depends_on:
      - db
    image: wordpress:php8.2-apache
    ports:
      - "8080:80"
    restart: always
    volumes:
      - ./wp-content:/var/www/html/wp-content
      - ./config/php.ini:/usr/local/etc/php/conf.d/custom.ini
    environment:
      WORDPRESS_DB_HOST: db:3306
      WORDPRESS_DB_USER: wpuser
      WORDPRESS_DB_PASSWORD: wppassword
      WORDPRESS_DB_NAME: wordpress
      WORDPRESS_DEBUG: 1
      WORDPRESS_CONFIG_EXTRA: |
        define('WP_DEBUG_LOG', true);
        define('WP_DEBUG_DISPLAY', false);
        define('SCRIPT_DEBUG', true);
        define('WP_ENVIRONMENT_TYPE', 'local');

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db
      PMA_USER: root
      PMA_PASSWORD: rootpassword

volumes:
  db_data:

Bu yapılandırmada dikkat edilmesi gereken detay: ./wp-content:/var/www/html/wp-content volume mount’u. Sadece wp-content klasörünü mount ediyoruz, bu sayede WordPress core dosyalarına dokunmuyoruz ama eklentilerimiz, temalarımız ve upload’larımız local dosya sisteminizde kalıyor. Git’e sadece bu klasörü eklemek yeterli.

# Docker ortamını başlat
docker-compose up -d

# Log'ları takip et
docker-compose logs -f wordpress

# WordPress container'ına gir
docker-compose exec wordpress bash

# WP-CLI ile container içinde çalış
docker-compose exec wordpress wp --info --allow-root

wp-config.php Geliştirme Ayarları

Local geliştirme ortamında wp-config.php dosyası kritik. Şu sabah bir iş arkadaşım “debug logunu neden göremiyorum” diye sordu, baktım debug ayarları kapalıydı. Bu temel yapılandırma şablonunu kullanın:

<?php
// Geliştirme ortamı wp-config.php ayarları

// Veritabanı ayarları
define('DB_NAME', 'myproject');
define('DB_USER', 'root');
define('DB_PASSWORD', '');
define('DB_HOST', 'localhost');
define('DB_CHARSET', 'utf8mb4');
define('DB_COLLATE', '');

// Debug ayarları - PRODUCTION'da KAPATMAYI UNUTMAYIN
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);        // /wp-content/debug.log'a yazar
define('WP_DEBUG_DISPLAY', false);   // Ekranda göstermez, log'a yazar
define('SCRIPT_DEBUG', true);        // Minify edilmemiş JS/CSS kullanır
define('SAVEQUERIES', true);         // Veritabanı sorgularını kaydeder

// Geliştirme kolaylıkları
define('WP_ENVIRONMENT_TYPE', 'local');
define('DISALLOW_FILE_EDIT', false);  // Dashboard'dan dosya düzenlemeye izin ver
define('WP_MEMORY_LIMIT', '256M');
define('WP_MAX_MEMORY_LIMIT', '512M');

// Otomatik güncelleme - local'de kapatıyorum
define('AUTOMATIC_UPDATER_DISABLED', true);
define('WP_AUTO_UPDATE_CORE', false);

$table_prefix = 'wp_';

if (!defined('ABSPATH')) {
    define('ABSPATH', __DIR__ . '/');
}

require_once ABSPATH . 'wp-settings.php';

Eklenti Geliştirme için Klasör Yapısı

WordPress eklenti geliştirirken dosya organizasyonu başlangıçta önemsiz görünüyor, zamanla kurtarıcınız oluyor. Şu yapıyı benimsedim:

# Eklenti klasörünü oluştur
mkdir wp-content/plugins/my-awesome-plugin
cd wp-content/plugins/my-awesome-plugin

# Temel dosya yapısı
touch my-awesome-plugin.php
mkdir -p {includes,admin,public,languages,assets/{css,js,images}}
touch readme.txt
touch .gitignore

Ana eklenti dosyasının başlangıç şablonu:

<?php
/**
 * Plugin Name: My Awesome Plugin
 * Plugin URI: https://example.com
 * Description: Örnek eklenti açıklaması
 * Version: 1.0.0
 * Requires at least: 6.0
 * Requires PHP: 8.1
 * Author: Adınız
 * Author URI: https://example.com
 * License: GPL v2 or later
 * Text Domain: my-awesome-plugin
 * Domain Path: /languages
 *
 * @package MyAwesomePlugin
 */

if (!defined('ABSPATH')) {
    exit; // Direkt erişimi engelle
}

// Eklenti sabitleri
define('MAP_VERSION', '1.0.0');
define('MAP_PLUGIN_DIR', plugin_dir_path(__FILE__));
define('MAP_PLUGIN_URL', plugin_dir_url(__FILE__));
define('MAP_PLUGIN_FILE', __FILE__);

// Autoloader
spl_autoload_register(function ($class) {
    $prefix = 'MyAwesomePlugin\';
    $base_dir = MAP_PLUGIN_DIR . 'includes/';

    $len = strlen($prefix);
    if (strncmp($prefix, $class, $len) !== 0) {
        return;
    }

    $relative_class = substr($class, $len);
    $file = $base_dir . str_replace('\', '/', $relative_class) . '.php';

    if (file_exists($file)) {
        require $file;
    }
});

// Eklentiyi başlat
function map_init() {
    // Ana sınıfı başlat
}
add_action('plugins_loaded', 'map_init');

Xdebug Kurulumu ve VS Code Entegrasyonu

Debug etmeden eklenti geliştirmek, karanlıkta iş yapmak gibi. var_dump ve error_log ile idare etmek bir noktaya kadar yeterli, ancak Xdebug ile breakpoint koyup değişkenleri inceleyebilmek farklı bir dünya.

Laragon için Xdebug kurulumu:

# php.ini dosyasına Xdebug ayarlarını ekle
# C:laragonetcphpphp8.2.xphp.ini

[xdebug]
zend_extension=xdebug
xdebug.mode=debug
xdebug.start_with_request=yes
xdebug.client_host=127.0.0.1
xdebug.client_port=9003
xdebug.idekey=VSCODE
xdebug.log_level=0

VS Code için .vscode/launch.json dosyası:

{
    "version": "0.2.0",
    "configurations": [
        {
            "name": "Listen for Xdebug",
            "type": "php",
            "request": "launch",
            "port": 9003,
            "pathMappings": {
                "/var/www/html/wp-content/plugins/my-awesome-plugin": "${workspaceFolder}"
            },
            "ignore": [
                "**/vendor/**/*.php"
            ]
        }
    ]
}

Docker ortamında Xdebug için pathMappings önemli. Container içindeki yol ile local yolu eşleştirmeniz gerekiyor, aksi halde breakpoint’ler çalışmıyor.

WP-CLI ile Geliştirme Sürecini Hızlandırma

WP-CLI’ı ne kadar kullandığınız, ne kadar hızlı geliştirdiğinizi doğrudan etkiliyor. Günlük kullandığım komutlar:

# Eklenti aktivasyon/deaktivasyon
wp plugin activate my-awesome-plugin
wp plugin deactivate my-awesome-plugin

# Cache temizleme (her değişiklikten sonra alışkanlık edinin)
wp cache flush
wp rewrite flush

# Test verisi oluşturma - gerçek dünya senaryolarını simüle etmek için
wp post generate --count=50 --post_type=post
wp user generate --count=10 --role=customer

# Veritabanı export/import - müşteri verisini local'e almak için
wp db export backup_$(date +%Y%m%d).sql
wp db import backup_20240115.sql

# Option ayarları
wp option get siteurl
wp option update blogname "Test Site"

# Aktif tema ve eklentileri listele
wp plugin list --status=active --format=table
wp theme list

Müşteri sitesinden local’e veri çekmek istediğinizde, özellikle WooCommerce siparişleri ve müşteri verileri varsa dikkatli olun. KVKK kapsamında bu verileri anonymize etmeniz gerekiyor:

# Kullanıcı e-postalarını anonymize et
wp user list --format=ids | xargs -I % wp user update % --user_email=%@example.local

# Ya da daha kapsamlı bir SQL ile
wp db query "UPDATE wp_users SET user_email = CONCAT(ID, '@test.local'), user_pass = MD5('testpassword')"

Sık Karşılaşılan Sorunlar ve Çözümleri

Problem: “Too many redirects” hatası

Local kurulumda siteurl veya home ayarları yanlış set edilmişse bu hata çıkıyor. Çözüm:

wp option update siteurl "http://myproject.test"
wp option update home "http://myproject.test"

Problem: Upload klasörü izin hataları

Linux/macOS’ta Docker ortamında sık görülüyor:

# Docker container içinde
docker-compose exec wordpress bash
chown -R www-data:www-data /var/www/html/wp-content/uploads
chmod -R 755 /var/www/html/wp-content/uploads

Problem: Veritabanı bağlantı hatası Docker’da

MySQL container hazır olmadan WordPress başlamaya çalışıyor. docker-compose.yml‘e healthcheck ekleyin:

db:
  image: mysql:8.0
  healthcheck:
    test: ["CMD", "mysqladmin", "ping", "-h", "localhost"]
    timeout: 20s
    retries: 10

Problem: PHP memory limit hatası büyük eklentilerde

# WP-CLI ile kontrol
wp eval 'echo WP_MEMORY_LIMIT;'

# php.ini veya wp-config.php üzerinden artırın
# wp-config.php
define('WP_MEMORY_LIMIT', '512M');

Git Workflow ve .gitignore

Eklenti geliştirmede Git kullanmak zorunluluk, tercih değil. Şu .gitignore şablonunu kullanıyorum:

# WordPress core - bunu asla commit'leme
/wp-admin/
/wp-includes/
/wp-content/uploads/
/wp-content/cache/
/wp-content/upgrade/

# Hassas dosyalar
wp-config.php
.env
*.log

# Bağımlılıklar
/wp-content/plugins/my-awesome-plugin/vendor/
/wp-content/plugins/my-awesome-plugin/node_modules/

# OS dosyaları
.DS_Store
Thumbs.db
desktop.ini

# IDE dosyaları
.idea/
*.swp
*.swo

Commit stratejisi olarak şunu öneririm: her özellik için ayrı branch, anlamlı commit mesajları ve PR’da kod review. Tek geliştirici olsanız bile bu disiplini koruyun, ileride hayat kurtarıyor.

Sonuç

Local WordPress geliştirme ortamı kurmak bir kerelik iş, ancak doğru kurulmazsa sürekli sizi yavaşlatır. Laragon Windows’ta gündelik eklenti geliştirme için yeterince güçlü ve hızlı. Docker ise takım ortamı, CI/CD entegrasyonu veya farklı PHP/MySQL kombinasyonlarını test etmek istediğinizde tercih edilmeli.

En kritik noktaları tekrar vurgulayayım: WP-CLI olmadan çalışmayın, Xdebug kurun ve var_dump bağımlılığından kurtulun, debug loglarını aktif tutun, ve müşteri verisini local’e çekerken KVKK uyumunu gözetin.

Bu kurulumu bir kez düzgün yaparsanız, her yeni WordPress projesinde dakikalar içinde çalışır hale gelirsiniz. Özellikle WooCommerce eklenti geliştiriyorsanız, test siparişleri oluşturmak, farklı ödeme senaryolarını test etmek ve webhook’ları debug etmek için local ortam gerçekten vazgeçilmez oluyor.

Sorularınız veya farklı kurulum deneyimleriniz varsa yorumlarda paylaşın, özellikle farklı hosting ortamlarıyla uyumluluk konusunda konuşmak isterim.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir