WordPress mu Özel Yazılım mı: Hangisini Seçmelisiniz

Yazar:komut.io ekibi
0 Yorum

Yıllar önce bir müşterimiz beni aradı. “Hocam, biz bu siteyi özel yazdırdık, 80 bin lira verdik, ama şu an hiçbir şey çalışmıyor ve geliştirici kayıp” dedi. Tam karşı örnekle de karşılaştım: Başka bir müşteri WordPress kurmuş, eklenti üstüne eklenti yüklemiş, site 8 saniyede açılıyor, her güncellemede bir şeyler bozuluyor. İki senaryo da acı verici. Bu yazıda sizi bu acılardan kurtarmak için elimden geleni yapacağım.

Önce Gerçekten Ne Seçtiğinizi Anlayalım

WordPress veya özel yazılım seçimi aslında teknik bir karar değil, öncelikle bir iş kararıdır. Ama bu kararı verirken sistem yöneticisi ve DevOps perspektifinden bakılması gereken çok şey var. Çünkü sonunda o sistemi kuran, bakımını yapan, gece 2’de uyandığında müdahale eden kişi sizsiniz.

WordPress, dünya genelinde web sitelerinin yaklaşık %43’ünü çalıştıran bir CMS. Bu rakam hem gücünü hem de zayıflığını anlatıyor. Bu kadar yaygın olduğu için hem inanılmaz bir ekosistem var, hem de her hacker grubu önce WordPress açıklarını tarıyor.

Özel yazılım ise tamamen sizin ihtiyaçlarınıza göre yazılmış, genellikle bir framework üzerinde (Laravel, Django, Node.js, Spring Boot vb.) geliştirilen sistem demek. Daha fazla kontrol, daha fazla sorumluluk.

WordPress: Gerçek Güçlü Yönler

WordPress’i hafife almak büyük hata. Doğru kurulup doğru yönetildiğinde son derece sağlam bir platform.

Deployment Hızı ve Maliyet

Bir şirkete danışmanlık yaparken şunu fark ettim: Pazarlama ekibi her hafta yeni bir landing page istiyor. Özel geliştirici bu işi 3-5 iş günü alıyor ve her seferinde para ödüyorsunuz. WordPress’te Elementor veya Gutenberg ile bu iş bir pazarlama uzmanının elinde yarım saate iniyor.

Altyapı tarafından da bakarsak, basit bir WordPress kurulumu için ihtiyacınız olan şey:

# Minimal WordPress sunucu kurulumu (Ubuntu 22.04)
apt update && apt upgrade -y
apt install -y nginx php8.2-fpm php8.2-mysql php8.2-xml 
    php8.2-gd php8.2-curl php8.2-mbstring php8.2-zip mariadb-server

# WordPress indirme ve kurulum
cd /var/www/html
wget https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
chown -R www-data:www-data wordpress/
chmod -R 755 wordpress/

Bu kadar. 15 dakika içinde çalışır hale getirebilirsiniz. Özel bir Django veya Laravel projesini aynı sürede production’a almak neredeyse imkansız.

WP-CLI: Sistem Yöneticisinin En İyi Dostu

WordPress’e tepeden bakan birçok sysadmin WP-CLI’ı bilmiyor ya da kullanmıyor. Bu büyük kayıp. WP-CLI olmadan WordPress yönetmek, GUI olmadan Windows yönetmeye çalışmak gibi.

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

# Tüm eklentileri güncelle
wp plugin update --all --path=/var/www/html/wordpress

# Veritabanı optimizasyonu
wp db optimize --path=/var/www/html/wordpress

# Tüm kullanıcıları listele (güvenlik denetimi için)
wp user list --path=/var/www/html/wordpress

# Çekirdek dosyaları kontrol et (zararlı yazılım tespiti için)
wp core verify-checksums --path=/var/www/html/wordpress

Bu komutları cron’a bağladığınızda otomatik güncelleme, veritabanı bakımı ve güvenlik denetimi sisteminiz hazır demektir.

Yedekleme Otomasyonu

WordPress siteleri için üretim ortamında kullandığım basit bir yedekleme scripti:

#!/bin/bash
# /usr/local/bin/wp-backup.sh

WP_PATH="/var/www/html/wordpress"
BACKUP_DIR="/backups/wordpress"
DATE=$(date +%Y%m%d_%H%M%S)
DB_NAME="wordpress_db"
DB_USER="wp_user"
DB_PASS="guclu_sifre_buraya"

mkdir -p $BACKUP_DIR

# Veritabanı yedeği
mysqldump -u$DB_USER -p$DB_PASS $DB_NAME | gzip > $BACKUP_DIR/db_$DATE.sql.gz

# Dosya yedeği (uploads ve wp-content)
tar -czf $BACKUP_DIR/files_$DATE.tar.gz 
    $WP_PATH/wp-content/uploads 
    $WP_PATH/wp-content/themes 
    $WP_PATH/wp-content/plugins

# 30 günden eski yedekleri temizle
find $BACKUP_DIR -name "*.gz" -mtime +30 -delete

echo "Yedekleme tamamlandi: $DATE"
# Cron'a ekle - her gece saat 02:00'de
echo "0 2 * * * root /usr/local/bin/wp-backup.sh >> /var/log/wp-backup.log 2>&1" 
    > /etc/cron.d/wordpress-backup

WordPress: Gerçek Sorunlar

Artık güzel kısım bitti, gerçeklere bakalım.

Güvenlik Yüzey Alanı

WordPress’in en büyük sorunu eklenti ekosistemi. Bir site kuruyorsunuz, 30-40 eklenti yüklüyorsunuz, bunların her biri potansiyel bir güvenlik açığı. Wordfence gibi araçlar bu durumu biraz yönetilebilir hale getiriyor ama asla tam güvende olduğunuzu düşünmeyin.

# Zararlı dosya taraması - basit bir kontrol
find /var/www/html/wordpress -name "*.php" -newer /var/www/html/wordpress/wp-config.php 
    -not -path "*/uploads/*" | head -20

# wp-config.php izinlerini kontrol et
stat /var/www/html/wordpress/wp-config.php

# Şüpheli PHP dosyası varlığını ara
find /var/www/html/wordpress/wp-content/uploads -name "*.php" -type f

# Dosya izinlerini düzelt
find /var/www/html/wordpress -type d -exec chmod 755 {} ;
find /var/www/html/wordpress -type f -exec chmod 644 {} ;
chmod 600 /var/www/html/wordpress/wp-config.php

Performans Sorunları

Varsayılan WordPress kurulumu performans açısından felakettir. Her sayfa yüklemesinde onlarca veritabanı sorgusu, optimize edilmemiş görseller, render-blocking JavaScript… Bunları çözmeniz gerekiyor.

# Nginx FastCGI cache konfigürasyonu
# /etc/nginx/conf.d/fastcgi-cache.conf

fastcgi_cache_path /tmp/nginx-cache levels=1:2 
    keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

Redis object cache entegrasyonu da şart:

# Redis kurulumu
apt install -y redis-server php8.2-redis

# Redis'i WordPress ile bağla (wp-config.php'ye eklenecek)
wp config set WP_CACHE true --path=/var/www/html/wordpress
wp config set WP_REDIS_HOST 127.0.0.1 --path=/var/www/html/wordpress
wp config set WP_REDIS_PORT 6379 --path=/var/www/html/wordpress

# Redis Object Cache eklentisini kur ve aktif et
wp plugin install redis-cache --activate --path=/var/www/html/wordpress
wp redis enable --path=/var/www/html/wordpress

Bu optimizasyonlarla ortalama bir WordPress sitesinin yüklenme süresini 6-8 saniyeden 1-2 saniyeye çekmek mümkün. Ama bunları bilmeden kurulmuş, bakımsız bir site her zaman problem çıkarır.

Özel Yazılım: Ne Zaman Gerçekten Gerekli

Şimdi öbür tarafa geçelim. Özel yazılım seçmek için gerçekten güçlü nedenleriniz olmalı, yoksa hem paranızı hem zamanınızı boşa harcarsınız.

Karmaşık İş Mantığı

E-ticaret sitesi kuracaksanız ve “kullanıcının sipariş geçmişine göre dinamik fiyatlandırma yap, ama sadece bu kategorideki ürünlere, ama sadece kurumsal müşterilere” gibi gereksinimleriniz varsa, WooCommerce ile bunu yapmak başlı başına bir kabusa dönüşür. Özel yazılım bu noktada çok daha temiz bir çözüm sunar.

Yüksek Trafik ve Ölçeklenebilirlik

WordPress milyonlarca sayfayı olan büyük sitelerde de kullanılıyor (WordPress.com, TechCrunch vb.) ama bu kurulumlar muazzam mühendislik altyapısı gerektiriyor. Eğer ciddi bir ölçekte çalışacaksanız ve özel bir mühendislik ekibiniz yoksa, mimarisi başından beri ölçeklenebilirlik düşünülerek tasarlanmış bir sistem çok daha akılcı.

Veri Güvenliği ve Uyumluluk

KVKK, PCI-DSS, HIPAA gibi uyumluluk gereksinimleri olan projelerde özel yazılımın avantajları belirgin. Tam olarak neyin nerede saklandığını, nasıl işlendiğini kontrol edebilmek değer biçilemez.

Özel Yazılımın Gizli Maliyetleri

Müşterilerin genellikle anlamadığı kısım burası. Özel yazılım seçince sadece geliştirme maliyeti ödemiyorsunuz.

Geliştirici Bağımlılığı: Uygulamayı yazan geliştirici olmadan kimse bir şey yapamıyorsa, bu ciddi bir operasyonel risk. Bunu sözleşmede netleştirin, dokümantasyon şartı koyun.

Altyapı Karmaşıklığı: Modern bir özel web uygulaması deployment pipeline’ı nasıl görünüyor?

# Basit bir CI/CD pipeline örneği (GitLab CI)
# .gitlab-ci.yml

stages:
  - test
  - build
  - deploy

test:
  stage: test
  script:
    - composer install
    - php artisan test
  only:
    - merge_requests

build:
  stage: build
  script:
    - docker build -t myapp:$CI_COMMIT_SHA .
    - docker push registry.example.com/myapp:$CI_COMMIT_SHA

deploy_production:
  stage: deploy
  script:
    - ssh deploy@prod-server "docker pull registry.example.com/myapp:$CI_COMMIT_SHA"
    - ssh deploy@prod-server "docker-compose up -d --no-deps app"
  only:
    - main
  when: manual

Bu pipeline’ı kurmak, test etmek, bakımını yapmak iş demek. WordPress güncellemesi yapmak kadar basit değil.

Monitoring ve Observability: WordPress için Wordfence ve birkaç monitoring aracı yeterken, özel bir uygulama için çok daha fazlasına ihtiyaç var:

# Uygulama loglarını izleme - basit örnek
tail -f /var/log/myapp/app.log | grep -E "ERROR|CRITICAL|WARNING"

# Prometheus metrics endpoint kontrolü
curl -s http://localhost:9090/metrics | grep -E "^(http_requests|db_query)"

# Systemd servis durumu
systemctl status myapp.service
journalctl -u myapp.service -f --since "1 hour ago"

Karar Verme Çerçevesi

Yıllarca bu kararları verirken oluşturduğum bir çerçeve var. Şu soruları sorun:

İçerik mi, uygulama mı? Sitenizin temel amacı içerik yayınlamak, blog yazmak, ürün tanıtmak mı? O zaman WordPress. Eğer amacınız kullanıcıların bir şeyler yapmasını sağlamak (rezervasyon, sipariş, işlem, hesaplama) mı? Özel yazılım değerlendirin.

Ekibinizin teknik kapasitesi nedir? Elinizde DevOps ekibi yoksa ve bakım yapacak tek kişi varsa, WordPress çok daha yönetilebilir. Özel bir uygulamanın deployment’ı, monitoring’i, scaling’i için gerçek mühendislik kapasitesi gerekiyor.

Bütçe ve zaman kısıtlaması nedir? Proje 3 ayda production’a çıkmalıysa ve bütçe sınırlıysa, özel yazılım neredeyse imkansız. WordPress veya benzer bir platform ile hızlı bir MVP çıkarıp sonra değerlendirin.

Kaç yıl bakımı yapılacak? 2-3 yıl içinde tamamen yeniden yapılacak geçici bir proje için özel yazılım yazımı büyük israf. Uzun vadeli, kurumun DNA’sına işlenecek bir sistem içinse özel yazılım çok daha savunulabilir.

Hibrit Yaklaşım: Her Zaman Göz Ardı Edilen Seçenek

Kimsenin konuşmadığı ama sıklıkla en doğru çözüm olan şey: ikisini birden kullanmak. Headless WordPress buna güzel bir örnek.

WordPress’i sadece içerik yönetim sistemi olarak kullanıyorsunuz, ön yüzü ise React, Next.js veya Nuxt.js ile özel geliştiriyorsunuz. WordPress REST API veya GraphQL üzerinden veriyi çekiyorsunuz.

# WordPress REST API'yi test et
curl -s "https://siteniz.com/wp-json/wp/v2/posts?per_page=5" | 
    python3 -m json.tool | head -50

# GraphQL sorgusu (WPGraphQL eklentisi ile)
curl -s -X POST https://siteniz.com/graphql 
    -H "Content-Type: application/json" 
    -d '{"query": "{ posts { nodes { title date excerpt } } }"}' | 
    python3 -m json.tool

Bu yaklaşımla hem içerik yönetiminin kolaylığından yararlanıyorsunuz hem de ön yüzde tam kontrol sahibi oluyorsunuz. Performans üstün, güvenlik yüzey alanı küçülüyor (WordPress admin paneline doğrudan dışarıdan ulaşılamıyor).

Geçiş Stratejileri

Diyelim ki WordPress siteniz var ve artık özel yazılıma geçmek istiyorsunuz, ya da tam tersi. Bu geçişleri yönetmek başlı başına bir uzmanlık.

WordPress’ten özel yazılıma geçerken en önemli şey veri migrasyonu:

# WordPress veritabanını incele
mysql -u root -p wordpress_db -e "SHOW TABLES;"

# İçerikleri JSON'a aktar (daha sonra işlemek için)
wp post list --post_type=post --format=json 
    --fields=ID,post_title,post_content,post_date,post_status 
    --path=/var/www/html/wordpress > /tmp/wp_posts_export.json

# Medya dosyalarını listele
wp media list --format=csv --path=/var/www/html/wordpress > /tmp/wp_media.csv

# URL yapısını kaydet (301 redirect haritası için)
wp post list --post_type=post --format=csv 
    --fields=ID,post_name,post_status 
    --path=/var/www/html/wordpress > /tmp/wp_slugs.csv

301 redirect haritasını oluşturmadan geçiş yapmak SEO açısından intihar. Bunu asla atlamamalısınız.

Sonuç

Doğru cevap “duruma göre değişir” demek kolay ama size daha somut bir şey bırakmak istiyorum.

WordPress seçin eğer: Siteniz öncelikle içerik odaklıysa, ekibinizde sürekli geliştirici bulunduramıyorsanız, hızlı lansmanın kritik olduğu durumlarda, bütçe kısıtınız varsa veya işin gidişatına göre çok sık değişiklik yapmanız gerekiyorsa. Ama WordPress seçtikten sonra bunu ciddiye alın. WP-CLI öğrenin, güvenlik konfigürasyonunu yapın, yedekleme ve monitoring sistemi kurun. Yarım iş olmasın.

Özel yazılım seçin eğer: Gerçekten karmaşık iş mantığınız varsa, ölçeklenebilirlik ve performans birincil önceliğinizse, uyumluluk gereksinimleri sizi zorluyorsa, uzun vadeli ürününüz bu sistem olacaksa ve bunu destekleyecek teknik ekibiniz mevcutsa. Ve özel yazılım seçtikten sonra dokümantasyonu, deployment pipeline’ını ve monitoring sistemini başından kurun. Sonradan bu şeyleri yamayarak eklemek acı veriyor.

Headless hibrit yaklaşımı değerlendirin eğer içerik yönetimi gerekliliğiniz var ama ön yüzde tam kontrol istiyorsanız.

Son olarak şunu söyleyeyim: Bu seçimi yaparken “hangisi daha iyi” diye sormayın. “Hangi araç bu problemi daha iyi çözer ve biz bunu gerçekten yönetebilir miyiz?” diye sorun. Elinizdeki kaynakları, ekibinizin kapasitesini ve projenin gerçek gereksinimlerini göz ardı ederek verilen kararlar, beni gece 2’de arayan müşterilere dönüşüyor.

Bir yanıt yazın

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