Öne Çıkanlar
- WHMCS modülleri satıştan faturaya ve bildirimlere kadar otomasyonu sağlar; doğru modül mimarisi insan hatasını azaltır.
- Az ve güvenilir modül, gereksiz modüllerden daha değerlidir — kaynak kullanımı ve güvenlik yüzeyi azalır.
- Kaynak yönetimi, cron ve log takibi performans için kritik; staging ortamında PHP/WHMCS/modül uyumluluğu test edilmelidir.
- Güvenlik için port ve IP sınırlandırması, SFTP/FTPS tercihleri ve lisanslı, güncellenebilir modüller önemlidir.
WHMCS Modül Kurulumu ve Özelleştirme Hakkında Bilmeniz Gerekenler
WHMCS modül kurulumu ve özelleştirme denince, çoğu kişinin aklına sadece “dosyayı modules klasörüne at, aktif et, bitti” geliyor. Keşke o kadar basit olsa. Aslında modül, WHMCS ile dış dünyadaki bir sistemi (cPanel, VDS paneli, ödeme altyapısı, SMS servisi vb.) konuşturan çevirmen. Yani sen WHMCS’te “Hesap Oluştur” dediğinde, panelin API’sine gidip gerçekten o hesabı açan şey modülün ta kendisi.
İhtiyaç nereden doğuyor? Tam olarak şu dertten: “Her yeni hosting satışında panele girip manuel hesap açmak istemiyorum, ödemesi gecikeni otomatik askıya al, yenileyeni otomatik aç.” Bir adım ötesi; “VDS, alan adı, SSL, kurumsal e-posta, hepsi tek panelden yönetilsin.” İşte burada modül mimarisi oyuna giriyor.
Sektördeki yaygın efsaneyi de aradan çıkaralım: “Ne kadar çok modül kurarsan o kadar iyi.” Hayır, tam tersi. Gereksiz her modül, sistemine ekstra yük ve potansiyel güvenlik yüzeyi ekler. Özellikle test etmediğin, kaynağını bilmediğin üçüncü parti modüller, ileride PHP versiyonu güncellediğinde patlayan ilk yer olur. İşin püf noktası şu: Az modül, doğru yapılandırma, kontrollü özelleştirme.
| Özellik | Değer |
|---|---|
| Hizmet Türü | Web Hosting / VDS / Cloud / Otomasyon |
| Hedef Kitle | Geliştirici, Hosting Firmaları, Ajanslar |
| Zorluk Seviyesi | Orta |
| Öne Çıkan Özellik | Otomasyon ve Entegrasyon Esnekliği |
Yapılandırma ve Yönetim: Adım Adım
Kaynak Yönetimi – Limitleri Zorlamayın
WHMCS, sonuçta bir PHP uygulaması. Yani arka planda çalışan cron işleri, modüllerin API istekleri, PDF fatura oluşturma, rapor sorguları… Hepsi CPU, RAM ve disk I/O tüketiyor. Özellikle çok modüllü, yoğun sipariş alan sistemlerde “Sunucu niye yavaşladı?” sorusu sık geliyor. Şöyle düşünün: Tüm modüller aynı anda dış sistemlere istek atıyor, cevapları işliyor, log tutuyor; bu da hem PHP-FPM havuzunu hem MySQL’i zorlar.
Aşırı kaynak kullanımı uyarısı gördüğünüzde panik yapmadan bakmanız gereken ilk yer genelde activity.log ve cron log’larıdır. Bir modül arka planda sürekli hata verip yeniden deniyor olabilir. Özellikle başarısız API çağrıları, saniyede onlarca kez tekrarlandığında CPU’yu tokatlar. İşte burada cron görevlerinin aralıklarını, modül ayarlarını ve hata tekrar limitlerini gözden geçirmek gerekir.
Basit ama etkili bir yöntem: En yoğun saatte, kısa bir süreliğine otomatik görevleri durdurup (cron disable) kaynak kullanımını gözlemleyin. Ani düşüş oluyorsa, sorun büyük ihtimalle modül bazlı otomasyon işlerinde.
Güvenlik Duvarı ve Port Ayarları
WHMCS modül kurulumu ve özelleştirme yaparken en çok atlanan konu güvenlik duvarı. Dış dünyaya açık her port, aslında açık bir pencere. Modüllerin çalışabilmesi için genelde belli portlara ihtiyaç var: Örneğin cPanel/WHM için 2087, bazı VDS panelleri için 8080/8443, özel kontrol panelleri için custom portlar.
İşin püf noktası şurada: Bu portların internetin tamamına açık olması gerekmiyor çoğu zaman. Kaynağı belli lokasyonlarla sınırlayıp, mümkünse sadece WHMCS’in bulunduğu IP’ye izin vermek çok daha sağlıklı. SSH için klasik 22 portunu kullanmak yerine, farklı bir porta almak ve sadece belirli IP’lere izin vermek, modül entegrasyonlarını bozmaz ama saldırı yüzeyini ciddi azaltır.
FTP tarafında ise, dürüst olmak gerekirse, artık klasik FTP’yi tamamen kapatmak en mantıklısı. SFTP/FTPS kullanımı hem daha güvenli hem de firewall tarafında yönetmesi daha öngörülebilir. Eğer bir modülün çalışması için ekstra port açmanız gerektiğinde, “Açalım gitsin” demeden önce, hangi IP’den, hangi protokolle kullanılacağını netleştirin.
Yazılım Uyumluluğu ve PHP/Veritabanı Seçimi
En güncel PHP sürümü her zaman en iyisi mi? Sadece kağıt üzerinde. Güvenlik ve performans açısından evet, ama modül uyumluluğu işin dengeleri değiştiriyor. Özellikle eski ama hala kullanılan ödeme modülleri veya yıllar önce yazılmış custom provisioning modülleri, PHP 8.x ile anında beyaz ekrana geçebiliyor.
Bu yüzden üretim ortamında yükseltme yapmadan önce, staging bir ortamda WHMCS sürümünüzü, modüllerinizi ve PHP sürümünü birlikte test etmek şart. Aslında durum tam olarak şöyle: WHMCS’in desteklediği resmi PHP aralığı neyse, önce ona bakın, ardından kullandığınız modüllerin dokümantasyonundaki minimum/maksimum sürüm notlarını kontrol edin.
Veritabanı tarafında altın kural şu: “İndeks yoksa performans yoktur.” Özelleştirme yaparken kendi tablolarınızı oluşturan bir modül yazıyorsanız, en çok sorgu çekeceğiniz alanlara mutlaka uygun index ekleyin. Ayrıca cron ve rapor ekranlarında ağırlaşma yaşıyorsanız, tblactivitylog, tblgatewaylog gibi log tablolarını düzenli arşivlemek veya temizlemek, fark edilir derecede rahatlatır.
Uygulama: Kurulum ve Yayına Alma
WHMCS modül kurulumu ve özelleştirme sürecini anlatırken “Terminali açın, şu komutu girin” gibi bir liste vermek yerine, mantığı oturtmak daha kalıcı oluyor. Genel akış şöyle ilerler:
- Önce bağımlılıkları kontrol et: WHMCS sürümü, PHP versiyonu, gerekli PHP eklentileri (curl, json, mbstring, ionCube vb.). Modül geliştiricisinin dokümantasyonunda zaten yazar.
- Ardından dosya yapısını doğrula:
modules/servers,modules/gateways,modules/addonsgibi klasörler doğru konumdaysa, admin panelden modülü görürsün. Görmüyorsan, %90 ihtimalle yanlış dizine atmışsındır. - Config tarafında kritik kısım: Sunucu veya gateway eklerken API kullanıcı adı, şifre, token, endpoint URL gibi alanlara gerçekten çalışan bilgileri gir. Genelde kullanıcılarımızdan duyduğumuz en büyük şikayet şu oluyor: “Her şeyi yaptım ama çalışmıyor.” Log’a bakıyoruz, staging API’ye bağlanmaya çalışıyor. Yani canlı ortamda test credentials unutulmuş.
- Test siparişi olmadan asla yayına alma: Sıfır ücretli bir test paketi aç, kendine sipariş ver, ödeme akışını, aktivasyonu, askıya almayı, iptali ve iade senaryolarını sırayla dene.
Çoğu kurulum, gerçekten düzgün bir hazırlık yaptıysan 5–10 dakikada biter. Asıl vakit alan kısım, özelleştirme: Ek alan tanımları, ürün bazlı modül ayarları, müşteri panelinde hangi butonun görüneceği gibi ince ayarlar. Burada küçük bir tavsiye: Tüm değişiklikleri tek seferde değil, parça parça yap. Her adımda çalıştığını doğrula ki, geriye dönerken hangi dokunuşun sistemi bozduğunu kolay bul.
Bu arada, performansınızı artırmak için Yazılım & Otomasyon sayfamızdaki diğer çözümlere de bakabilirsiniz. Özellikle yoğun otomasyon senaryolarında, arka plandaki süreçleri sadeleştirmek ciddi performans kazandırıyor.
Sık Karşılaşılan Sorunlar ve Pratik Çözümler
| Sorun | Muhtemel Neden | Çözüm |
|---|---|---|
| Modül Aktif Ama Çalışmıyor | Hatalı API bilgisi, eksik yetkiler veya yanlış endpoint | Activity log ve gateway/server log’larını inceleyin, API kullanıcı yetkilerini ve URL’yi doğrulayın |
| Siparişler Otomatik Aktive Olmuyor | Cron çalışmıyor veya modül için otomatik provizyon kapalı | WHMCS cron zamanlayıcısını ve ürün ayarlarında “Module Settings > Auto Setup” seçimini kontrol edin |
| Site Yavaş Açılıyor | Zayıf önbellekleme veya yüksek sorgu sayısı | Redis/Litespeed Cache kurulumu yapın |
| Bağlantı Zaman Aşımı | Firewall engeli veya hatalı DNS | Port izinlerini kontrol edin |
Sıkça Sorulan Sorular
WHMCS modül kurulumu ve özelleştirme güvenli mi?
Doğru kaynaktan alınmış modüller, güncel WHMCS ve PHP sürümleriyle kullanıldığında güvenli. Risk genelde nereden geliyor? Lisanssız veya kaynağı belirsiz modüllerden. Koduna bakamadığın, düzenli güncelleme almayan hiçbir modülü canlı ortamda tutmamak en sağlıklısı. Üzerine bir de panel ve sunucu tarafında güçlü bir firewall, zorunlu SSL ve iki faktörlü doğrulama koyarsan, saldırı yüzeyini ciddi azaltırsın. SSL tarafında hazır yeri gelmişken, ticari projelerde güveni artırmak için SSL sertifikası seçeneklerini inceleyebilirsin.
Fiyat/Performans dengesini nasıl kurarım?
Şöyle düşünün: Sadece WHMCS’in ucuz lisansına odaklanırsan, zayıf veya yetersiz bir sunucuda yazılımı boğarsın. Tıpkı bir araba motoru gibi, sunucular da yüksek trafikte doğru soğutmaya (kaynağa) ihtiyaç duyar. Ortalama bir hosting satış otomasyonu için, orta seviye bir VDS veya iyi yapılandırılmış bir cloud sunucu genelde fazlasıyla yeterli. Asıl tasarrufu, doğru modül seçimi ve gereksiz eklentilerden kaçınarak yaparsın.
Taşıma (Migration) işlemi zor mu?
Zor olan kısım genelde teknik kısımlar değil, plansızlık. WHMCS’i başka bir sunucuya veya yeni bir panele taşırken, en kritik noktalar: Veritabanı, configuration.php ayarları, custom modüller ve cron. Modüllerini tek tek yeni sistemde test ederek ilerlersen, taşımada sürpriz yaşamazsın. Bilhost tarafında ise, özellikle web hosting veya WordPress hosting hizmetlerine geçen kullanıcılar için migration sürecini oldukça sadeleştirdik; DNS ayarlarından e-posta taşımasına kadar adım adım destek veriyoruz. Yani “Taşısam bir şey bozulur mu?” korkusunu yaşayanlar için süreç, sanıldığı kadar çetrefilli değil.
Sonuç
İşin özü şu: WHMCS modül kurulumu ve özelleştirme, doğru ele alındığında seni manuel iş yükünden, unutulan yenilemelerden ve insan hatasından kurtarır. Teknoloji ne kadar karmaşık görünürse görünsün, modülleri bilinçli seçip sade bir mimari kurduğunda hayat gerçekten kolaylaşıyor. Bir yerlerde hata alıyorsan da moral bozma; log’lar, test ortamı ve adım adım ilerleme, her zaman en iyi üçlüdür. Eğer bir noktada tıkanırsan biz buradayız, yorumlarda sorularını bekliyorum.
