LiteSpeed Hosting ve PHP Sürüm Yönetimi: AlexHost Kullanıcıları için Eksiksiz Teknik Kılavuz
Hosting ortamınız için doğru PHP sürümünü seçmek, web uygulaması dağıtımındaki en kritik kararlardan biridir. Yanlış sürüm performansı sessizce düşürebilir, güvenlik açıkları oluşturabilir veya framework uyumluluğunu tamamen bozabilir. AlexHost’un LiteSpeed destekli paylaşımlı hosting’i PHP 7.3, 7.4, 8.0 ve 8.1’i aynı anda destekler; cPanel’in MultiPHP Manager’ı aracılığıyla sunucu yapılandırma dosyalarına dokunmadan veya destek talebi açmadan her domain’e farklı PHP sürümleri atayabilirsiniz.
Bu kılavuz, her PHP sürümünün motor düzeyinde gerçekte ne sunduğunu, AlexHost altyapısında sürümlerin nasıl doğru şekilde değiştirileceğini ve sürüm değişikliğinden sonra uygulama hatalarına yol açan yaygın tuzaklardan nasıl kaçınılacağını ele almaktadır.
PHP Sürüm Seçiminin Çoğu Geliştiricinin Fark Ettiğinden Neden Daha Önemli Olduğu
PHP monolitik bir çalışma zamanı değildir. Her büyük ve küçük sürüm, Zend Engine davranışını değiştirir, fonksiyonları kullanımdan kaldırır, tür zorlama kurallarını değiştirir ve OPcache ile JIT derleyicisinin kodunuzla nasıl etkileşime girdiğini değiştirir. PHP 7.3 kodunu test etmeden PHP 8.1 üzerinde çalıştırmak güvenli bir yükseltme değildir — üretim ortamınızla kumar oynamaktır.
LiteSpeed Web Server, PHP yürütmesini LSAPI (LiteSpeed Server Application Programming Interface) aracılığıyla gerçekleştirir; bu, Apache’nin mod_php veya FastCGI’sinden mimari olarak farklıdır. LSAPI, kalıcı PHP worker süreçlerini koruyarak geleneksel kurulumları yavaşlatan istek başına süreç oluşturma yükünü ortadan kaldırır. Sonuç, ölçülebilir şekilde daha düşük ilk bayt süresi (TTFB) ve istek başına önemli ölçüde azaltılmış CPU döngüleridir — özellikle WordPress, Magento veya Laravel gibi PHP yoğun uygulamalar için önemlidir.
LiteSpeed’in LSAPI’sini cPanel’in MultiPHP Manager’ı ile birleştirdiğinizde, yalnızca yapılandırma düzeyinde değil, süreç düzeyinde domain başına PHP sürüm izolasyonu elde edersiniz. Bu, tek bir Paylaşımlı Web Hosting hesabında birden fazla müşteri sitesi barındıran ajanslar veya geliştiriciler için kritik bir ayrımdır.
PHP Sürüm Karşılaştırması: Özellik ve Güvenlik Matrisi
| Özellik / Nitelik | PHP 7.3 | PHP 7.4 | PHP 8.0 | PHP 8.1 |
|---|---|---|---|---|
| Resmi Güvenlik Desteği | Aralık 2021’de sona erdi | Kasım 2022’de sona erdi | Kasım 2023’te sona erdi | Kasım 2024’te sona erdi |
| JIT Derleyici | Hayır | Hayır | Evet (deneysel) | Evet (geliştirilmiş) |
| Typed Properties | Hayır | Evet | Evet | Evet |
| Arrow Functions | Hayır | Evet | Evet | Evet |
| Union Types | Hayır | Hayır | Evet | Evet |
| Named Arguments | Hayır | Hayır | Evet | Evet |
| Match Expression | Hayır | Hayır | Evet | Evet |
| Attributes (Annotations) | Hayır | Hayır | Evet | Evet |
| Enumerations (Enums) | Hayır | Hayır | Hayır | Evet |
| Fibers (Coroutines) | Hayır | Hayır | Hayır | Evet |
| Readonly Properties | Hayır | Hayır | Hayır | Evet |
| Intersection Types | Hayır | Hayır | Hayır | Evet |
| Nullsafe Operator | Hayır | Hayır | Evet | Evet |
| OPcache Preloading | Hayır | Evet | Evet | Evet |
| 7.3’e Göre Göreli Performans | Temel | +~%5-10 | +~%15-20 | +~%20-25 |
Bu tablodan çıkarılacak temel sonuç: PHP 7.3 ve 7.4, resmi kullanım ömrü sonu tarihlerini geçmiştir. Yalnızca eski bir uygulamanın çözülemeyen sabit bağımlılıkları olduğunda kullanılmalıdır — yeni dağıtımlar için varsayılan seçenek olarak değil.
PHP 7.3: Bilinen Sınırlamalarla Eski Kararlılık
PHP 7.3, array_key_first(), array_key_last(), esnek heredoc/nowdoc sözdizimi ve is_countable() fonksiyonunu tanıtan bakım odaklı bir sürümdü. Agresif yeniden yapılandırma gerektirmeden PHP 5.x üzerinde çalışan uygulamalar için bir geçiş yolu sunan kararlı bir platform temsil ediyordu.
Kritik operasyonel gerçek: PHP 7.3, Aralık 2021’de kullanım ömrünü tamamladı. PHP projesi tarafından güvenlik yamaları almamaktadır. Üretimde çalıştırmak, Zend Engine veya çekirdek uzantılarda yeni keşfedilen herhangi bir güvenlik açığının yamasız kalacağı anlamına gelir. Bugün AlexHost’ta PHP 7.3 kullanmanın tek meşru nedeni, PHP 8.x’e geçiş aktif olarak devam ederken eski bir uygulamayı sürdürmektir.
Yaygın kullanım durumu: Eski Joomla 3.x kurulumları, eski CodeIgniter 3 uygulamaları veya modern tür bildirimleri kullanacak şekilde güncellenmemiş özel PHP 5.6 dönemi kod tabanları.
PHP 7.4: 7.x Serisinin Sonu — Geçiş Dağıtımları için Kullanışlı
PHP 7.4, PHP 7 dalındaki son sürümdü ve PHP 8.0 ile gelen kırıcı değişiklikleri gerektirmeden kodu önemli ölçüde daha sürdürülebilir ve performanslı hale getiren çeşitli özellikler sundu.
Typed class properties, sınıf düzeyinde tür kısıtlamalarını uygulamanıza olanak tanır:
class User {
public int $id;
public string $email;
public ?DateTime $lastLogin;
}Bu, daha önce yalnızca belirli yürütme yollarında ortaya çıkan tüm bir çalışma zamanı hataları kategorisini ortadan kaldırır.
Arrow functions, özellikle dizi işlemlerinde kullanışlı olan kısa closure’ların ayrıntısını azaltır:
$multiplied = array_map(fn($n) => $n * 2, $numbers);OPcache preloading (7.4’te tanıtıldı) mimari açıdan önemlidir: PHP’nin sunucu başlangıcında bir dizi dosyayı paylaşılan belleğe yükleyip derlemesine olanak tanır ve bu dosyaları tekrarlanan derleme olmaksızın tüm worker süreçlerine kullanılabilir hale getirir. LSAPI ile LiteSpeed’de bu, kalıcı worker’ların zaten süreç oluşturma yükünü önlemesi nedeniyle performans avantajını katlar.
PHP 7.4, Kasım 2022’de kullanım ömrünü tamamladı. Bilinen PHP 8.x uyumsuzlukları olan eski eklentiler çalıştıran WordPress kurulumları veya hâlâ geçiş bekleyen Drupal 7 dağıtımları için uygundur.
PHP 8.0: Mimari Dönüm Noktası
PHP 8.0 artımlı bir sürüm değildi. PHP kodunun yazılma, yürütülme ve düşünülme biçimini temelden değiştiren değişiklikler getirdi. Uzun süredir devam eden çeşitli davranışlar değiştirildi veya kaldırıldı; bu da gevşek tür zorlamasına veya kullanımdan kaldırılmış fonksiyonlara dayanan kod tabanları için kırıcı bir yükseltme haline getirdi.
Just-In-Time Derleme
PHP 8.0’daki JIT derleyici, sık kullanılan kod yollarını çalışma zamanında yerel makine koduna derleyerek tekrarlanan yorumlamayı atlar. CPU yoğun iş yüklerinde — matematiksel hesaplamalar, görüntü işleme, veri dönüştürme ardışık düzenleri — JIT önemli hız artışları sağlayabilir. Ancak tipik I/O yoğun web uygulamaları için (veritabanı sorguları, dosya okuma, API çağrıları), darboğaz CPU yürütmesi değil harici kaynakları bekleme olduğundan JIT faydası genellikle marjinaldir.
Bu ayrımı anlamak, JIT’in otomatik olarak bir WordPress sitesini hızlandıracağını beklemenin yaygın hatasını önler. Olmayacaktır — site önemli ölçüde süreç içi hesaplama yapmıyorsa.
Union Types ve Named Arguments
Union types, bir fonksiyon parametresinin veya dönüş değerinin birden fazla türü açıkça kabul etmesine olanak tanır:
function processInput(int|string $input): int|false {
// ...
}Named arguments, argüman sırasını fonksiyon imzalarından ayırarak birden fazla isteğe bağlı parametreye sahip fonksiyonlarda okunabilirliği önemli ölçüde artırır:
array_slice(array: $data, offset: 2, length: 5, preserve_keys: true);Match Expression
match ifadesi, switch‘ı katı tür karşılaştırması, düşme davranışı olmadan ve ifade tabanlı döndürmelerle değiştirir:
$status = match($code) {
200, 201 => 'success',
404 => 'not found',
500 => 'server error',
default => 'unknown',
};switch‘ın aksine, match hiçbir kol eşleşmezse ve varsayılan sağlanmazsa UnhandledMatchError fırlatır — sessiz hataları imkânsız kılar.
Attributes (Yapılandırılmış Meta Veri)
PHP 8.0 Attributes, Doctrine ve Symfony gibi framework’ler tarafından kullanılan docblock annotation’larının yerini alır. Kullanıcı alanı regex’i tarafından değil, engine’in kendisi tarafından ayrıştırılır:
#[Route('/api/users', methods: ['GET'])]
public function listUsers(): Response { ... }Bu, framework performansı ve IDE araç doğruluğu açısından önemli sonuçlar doğurur.
PHP 8.1: Üretime Hazır Modern PHP
PHP 8.1, bu yazı itibarıyla çoğu yeni projenin hedeflemesi gereken sürümdür. PHP 8.0’ın temeli üzerine inşa edilmiş olup dilin tür sistemi ve eşzamanlılık modelindeki uzun süredir devam eden boşlukları gideren özellikler ekler.
Enumerations
Enums, PHP kod tabanlarını on yıllardır rahatsız eden “sihirli sabit” sorununu çözer:
enum Status: string {
case Active = 'active';
case Inactive = 'inactive';
case Pending = 'pending';
}Backed enum’lar veritabanlarında saklanabilir ve temiz bir şekilde serileştirilebilir. Pure enum’lar, sınıf sabitleri veya tamsayı bayraklarının kırılganlığı olmadan tür güvenli durum temsili sağlar.
Fibers: Kooperatif Çoklu Görev
Fibers, PHP’ye düşük seviyeli bir eşzamanlılık ilkeli tanıtır. Thread’lerin aksine, Fiber’lar kooperatiftir — kontrolü açıkça bırakırlar. Bu, async PHP framework’lerinin (ReactPHP ve Amp gibi) Swoole gibi uzantılar gerektirmeden engelleyici olmayan I/O uygulamak için kullandığı temeldir:
$fiber = new Fiber(function(): void {
$value = Fiber::suspend('first suspension');
echo "Resumed with: " . $value;
});
$value = $fiber->start();
$fiber->resume('hello');PHP çalışma zamanı üzerinde tam kontrole sahip VPS Hosting üzerinde çalışan uygulamalar için Fiber’lar, saf PHP’de olay döngüsü tabanlı uygulamalar oluşturmanın kapısını açar.
Readonly Properties
Readonly properties, başlatmadan sonra değişmezliği zorunlu kılar; bu, DDD (Domain-Driven Design) mimarilerinde değer nesneleri ve domain varlıkları için gereklidir:
class OrderId {
public function __construct(
public readonly string $value
) {}
}Constructor’da bir kez ayarlandıktan sonra $value değiştirilemez. Herhangi bir girişim Error fırlatır. Bu, tüm bir savunmacı programlama şablonu sınıfını ortadan kaldırır.
Intersection Types
Union types “bu VEYA şu” derken, intersection types “bu VE şu” der — bir değerin aynı anda birden fazla arayüzü uygulamasını gerektirir:
function processEntity(Serializable&Countable $entity): void { ... }Bu, özellikle servis konteyneri ve middleware ardışık düzen mimarilerinde değerlidir.
cPanel Aracılığıyla AlexHost LiteSpeed Hosting’de PHP Sürümleri Nasıl Değiştirilir
AlexHost’un cPanel ile VPS ve paylaşımlı hosting ortamları, cPanel’in MultiPHP Manager‘ı aracılığıyla PHP sürüm yönetimini sunar. İşte tam prosedür:
Adım 1: cPanel Kontrol Panelinize Erişin
AlexHost hesabınıza giriş yapın ve cPanel kimlik bilgilerinizi almak için Giriş Bilgileri bölümüne gidin. cPanel’i sağlanan URL aracılığıyla doğrudan açın (genellikle yourdomain.com:2083 veya port ile doğrudan IP).
Adım 2: MultiPHP Manager’a Gidin
cPanel içinde Yazılım bölümünü bulun. MultiPHP Manager‘a tıklayın. Bu arayüz, hesabınızla ilişkili tüm domain’leri ve subdomain’leri, her birinin şu anda atanmış PHP sürümüyle birlikte listeler.
Adım 3: Hedef Domain ve PHP Sürümünü Seçin
Değiştirmek istediğiniz domain veya subdomain’in yanındaki onay kutusunu işaretleyin. Hosting planı yapılandırmanıza bağlı olarak mevcut sürümlerden — PHP 7.3, 7.4, 8.0 veya 8.1 — seçmek için PHP Sürümü açılır menüsünü kullanın. Uygula‘ya tıklayın.
Adım 4: Değişikliği Doğrulayın
Uygulandıktan sonra değişiklik yeni istekler için hemen geçerli olur. Domain’in belge kök dizininde geçici bir phpinfo.php dosyası oluşturarak doğrulayın:
<?php phpinfo(); ?>Çıktıdaki PHP sürümünü onaylayın, ardından bu dosyayı hemen silin — üretimde phpinfo()‘ı açıkta bırakmak, sunucu yapılandırmanızı saldırganlara ifşa eden bir güvenlik açığıdır.
Adım 5: Uygulama İşlevselliğini Test Edin
Test etmeden PHP sürüm değişikliğinin güvenli olduğunu varsaymayın. Uyumsuzluğu gösteren kullanımdan kaldırma bildirimleri, ölümcül hatalar veya tanımsız fonksiyon çağrıları için uygulamanızın hata günlüğünü (/home/username/logs/ veya cPanel’in Hatalar aracı aracılığıyla) kontrol edin.
.htaccess Aracılığıyla Dizin Başına PHP Sürümü Geçersiz Kılma
Ayrıntılı kontrol için — örneğin, ana site PHP 8.1 üzerinde çalışırken eski bir alt dizini PHP 7.4 üzerinde çalıştırmak — .htaccess kullanarak dizin düzeyinde PHP sürümünü geçersiz kılabilirsiniz:
<FilesMatch ".php$">
SetHandler application/x-httpd-ea-php81
</FilesMatch>İşleyici adı formatı application/x-httpd-ea-phpXX‘dır; burada XX ondalık nokta olmadan sürüm numarasına karşılık gelir. Bu, cPanel ortamlarında kullanılan bir EasyApache 4 kuralıdır.
PHP Sürüm Seçimi Karar Matrisi
| Senaryo | Önerilen PHP Sürümü | Gerekçe |
|---|---|---|
| Yeni Laravel 10+ veya Symfony 6+ projesi | PHP 8.1 | Minimum PHP 8.1 gerektirir; tam özellik desteği |
| WordPress 6.x (tüm eklentiler güncellenmiş) | PHP 8.1 | Resmi öneri; performans kazanımları |
| Eski eklentilerle WordPress (2022 öncesi) | PHP 7.4 veya 8.0 | Yükseltmeden önce uyumluluğu test edin |
| Magento 2.4.6+ | PHP 8.1 | Resmi destek matrisi 8.1 gerektirir |
| Drupal 10 | PHP 8.1 | Minimum gereksinim |
| Eski Joomla 3.x | PHP 7.3 veya 7.4 | Joomla 3.x, PHP 8.x ile tam uyumlu değil |
| Özel eski uygulama (2018 öncesi) | PHP 7.3 | Mümkün olan en kısa sürede geçiş yapın |
| Yeni API mikro servisi veya CLI aracı | PHP 8.1 | Enum’lar, Fiber’lar, readonly properties mevcut |
Kullanım Ömrü Sona Ermiş PHP Sürümlerini Çalıştırmanın Güvenlik Sonuçları
Bu nokta açık bir vurguyu hak ediyor. Kullanım ömrü sona erme tarihini geçmiş PHP sürümleri, PHP projesi tarafından güvenlik yamaları almaz. Bu şu anlama gelir:
- EOL sonrası keşfedilen CVE’ler etkilenen sürüm dalında yamalanmaz.
- Paylaşımlı hosting ortamları, izolasyon yapılandırmasına bağlı olarak güvenliği ihlal edilmiş bir PHP sürecinin komşu hesapları potansiyel olarak etkileyebileceğinden özellikle risk altındadır.
- PCI DSS uyumluluğu, satıcı destekli kullanım ömrü sona erme tarihini geçmiş yazılım çalıştırmayı açıkça yasaklar. Ödeme işliyorsanız, PHP 7.3 veya 7.4 çalıştırmak bir uyumluluk ihlalidir.
- Web Application Firewall’lar (WAF) bazı riskleri azaltabilir, ancak engine düzeyindeki güvenlik açıklarını yamalayamazlar.
PHP ortamınız, güvenlik yamalama kadansı ve özel PHP uzantıları derleme yeteneği üzerinde tam kontrole ihtiyaç duyuyorsanız, bir Dedicated Server, paylaşımlı ortamların sağlayamayacağı izolasyon ve yönetimsel erişimi sunar.
LiteSpeed’e Özgü PHP Performans Değerlendirmeleri
Birkaç LiteSpeed davranışı, PHP sürüm seçimiyle belirgin olmayan şekillerde etkileşime girer:
LiteSpeed Cache (LSCache): WordPress için LSCache eklentisi, PHP düzeyinde değil web sunucusu düzeyinde çalışır. Ancak PHP 8.x’in geliştirilmiş OPcache isabet oranları, önbellek isabetsizliklerinin daha hızlı sunulduğu anlamına gelir ve önbelleğe alınmamış isteklerin performans cezasını azaltır.
LSAPI worker kalıcılığı: LiteSpeed, PHP worker’larını istekler arasında canlı tutar. Bu, PHP 8.1’in JIT derleyicisinin, her isteğin soğuk bir süreç başlattığı geleneksel CGI kurulumuna kıyasla sık kullanılan kod yollarını ısınmak ve optimize etmek için daha fazla fırsata sahip olduğu anlamına gelir.
PHP-FPM ve LSAPI: Yığını kendiniz yapılandırdığınız VPS Kontrol Panelleri‘nde PHP-FPM ile LSAPI arasında seçim yapabilirsiniz. LSAPI, FastCGI’nin genel arayüzü yerine amaca özel bir iletişim protokolü kullandığından LiteSpeed ortamları için kıyaslamalarda PHP-FPM’yi sürekli olarak geride bırakır.
Bellek sınırları ve worker sayısı: PHP 8.x, JIT ve tür sistemi için ek çalışma zamanı yapıları nedeniyle PHP 7.x’e göre biraz daha yüksek temel bellek ayak izine sahiptir. Bellek kısıtlı bir ortam çalıştırıyorsanız, yükseltmeden sonra memory_limit ayarlarını izleyin.
Pratik Temel Çıkarım Kontrol Listesi
AlexHost LiteSpeed hosting’inizde bir PHP sürümünü değiştirmeden veya seçmeden önce bu kontrol listesini gözden geçirin:
- Uygulamanızın resmi PHP uyumluluk matrisini kontrol edin — tahmin etmeyin. Laravel, WordPress, Magento ve Drupal’ın tümü minimum ve maksimum desteklenen PHP sürümlerini yayınlar.
- Yüklü eklentileri ve uzantıları denetleyin — üçüncü taraf kod, PHP 8.x uyumsuzluğunun en yaygın kaynağıdır. Composer kullanıyorsanız
composer check-platform-reqsçalıştırın. - Değişikliği önce hazırlama ortamında yapın — PHP sürüm değişikliğini üretime uygulamadan önce test etmek için bir subdomain veya hazırlama ortamı kullanın.
- Geçiş yaptıktan hemen sonra hata günlüklerini inceleyin — bozuk uyumluluğu gösteren
E_DEPRECATED,E_NOTICEveE_FATALgirişlerini arayın. - Doğrulama sırasında oluşturulan
phpinfo()dosyalarını silin. - Üretimde EOL PHP sürümleri çalıştırmayın — belgelenmiş, zaman sınırlı bir geçiş planınız ve telafi edici güvenlik kontrolleriniz olmadıkça.
- MultiPHP INI Editor’ı kullanın (ayrıca cPanel’in Yazılım bölümünde) — sürüm değişikliğinden sonra
memory_limit,upload_max_filesizevemax_execution_timegibi domain başına PHP direktiflerini ayarlamak için — varsayılanlar sürümler arasında farklılık gösterir. - Uygulamanız PHP 8.2 veya 8.3 gerektiriyorsa, tam yazılım yığınını kontrol ettiğiniz ve Remi veya ondrej/php gibi depolar aracılığıyla herhangi bir PHP sürümü yükleyebileceğiniz bir VPS planına yükseltmeyi düşünün.
Sıkça Sorulan Sorular
Aynı AlexHost paylaşımlı hosting hesabındaki farklı domain’lerde farklı PHP sürümleri çalıştırabilir miyim?
Evet. cPanel’in MultiPHP Manager’ı, PHP sürüm ayarlarını domain başına uygular. Hesabınızdaki her domain veya subdomain, diğer domain’leri etkilemeden aynı arayüz aracılığıyla yönetilen farklı bir PHP sürümünü bağımsız olarak çalıştırabilir.
MultiPHP Manager’da PHP sürümlerini değiştirmek sunucu yeniden başlatması gerektirir mi veya kesintiye neden olur mu?
Hayır. Değişiklik, yeni gelen istekler için hemen geçerli olur. Mevcut uzun süreli PHP süreçleri tamamlanana kadar eski sürümde devam edebilir, ancak tipik web istekleri için bu geçiş sorunsuz olup ölçülebilir bir kesintiye neden olmaz.
PHP 8.1’in JIT derleyicisi WordPress sitemizi otomatik olarak hızlandırır mı?
Standart WordPress dağıtımları için önemli ölçüde değil. JIT, CPU yoğun iş yüklerine fayda sağlar. WordPress performansı öncelikle veritabanı sorgu süresi ve I/O işlemleriyle kısıtlanır; JIT bunları hızlandırmaz. WordPress için daha etkili PHP 8.x iyileştirmeleri, daha iyi OPcache verimliliği ve azaltılmış fonksiyon çağrısı yüküdür.
cPanel’de MultiPHP Manager ile MultiPHP INI Editor arasındaki fark nedir?
MultiPHP Manager, her domain’e hangi PHP sürümünün atandığını kontrol eder. MultiPHP INI Editor, her domain ve PHP sürümü kombinasyonu için PHP yapılandırma direktiflerini (php.ini ayarları) kontrol eder. Her iki araç da eksiksiz PHP ortam yönetimi için gereklidir — sürüm seçimi tek başına bellek sınırlarını, yürütme zaman aşımlarını veya uzantı yüklemeyi yapılandırmaz.
PHP 8.x’e yükselttikten sonra uygulamam bozulursa ne yapmalıyım?
Önce hizmeti geri yüklemek için MultiPHP Manager’da önceki PHP sürümüne geri dönün. Ardından belirli hata mesajları için hata günlüklerini inceleyin. Yaygın sorunlar arasında kaldırılmış fonksiyonlar (each(), create_function()), değiştirilmiş tür zorlama davranışı ve kullanımdan kaldırılmış constructor tarzı sınıf yöntemleri yer alır. Yükseltmeyi tekrar denemeden önce her sorunu bir hazırlama ortamında ele alın. Uygulama bir CMS veya framework ise, PHP 8.x’i resmi olarak destekleyen güncellenmiş bir sürümün mevcut olup olmadığını kontrol edin.
