DLE 21.0'a güncelleme: neler bozuluyor, 16 sürümde denedik

DLE 15.0'dan 20.0'a kadar tüm test sitelerimizin kopyalarını ve windows-1251 kodlamalı temiz bir 12.0 kurulumunu 21.0'a yükselttik. PHP 8.0 ve üzerinde ne sitede ne de yönetim panelinde tek bir PHP hatası çıktı. Bozulan başka yerler oldu: PHP 7.4'te dosyaları yükledikten sonra beyaz ekran geliyor, 21.0 arşivi de sizin .htaccess ve robots.txt dosyalarınızın üzerine sessizce yazıyor. Forumda şikâyet edilen, imzalardaki kaybolan bağlantılar ise aslında 18.0'dan kalma: 17.x'ten doğrudan 21.0'a geçen bunu ilk kez görüyor ve suçu 21.0'a atıyor.

Kısaca#

• 21.0 dosyalarından önce intl eklentili PHP 8.0+ gerekiyor.
• Veritabanı saniyeler içinde güncelleniyor: 15.1'den 10 sn, 20.0'dan bir saniye. 100 bin haberlik bir kopyada 20.0 → 21.0 adımı tek bir HTTP isteğinde 28 saniye sürdü; zaman aşımı kısa olan bir hostingde bu istek yarıda kesilebilir.
• 21.0 arşivinde .htaccess ve robots.txt var. "Şablonlar hariç her şeyi" yüklerseniz yönlendirmeleriniz ve robots dosyanız ezilir.
• windows-1251 kodlamalı 12.0'dan 21.0'a tek seferde ulaştık: 25 adım ve UTF-8'e dönüştürme.

Nasıl test ettik#

Toplam 16 başlangıç sürümü: 15.0'dan 20.0'a kadar 15 test sitesi ve ayrıca kurulan bir DLE 12.0. Hedef sürüm olan 21.0 bu sayıya dahil değil. Test sitelerine dokunmadık: her biri için kendi veritabanı kopyasıyla birlikte bir alt klasöre kopya çıkardık. Güncellemeyi 21.0 belgelerindeki betik güncelleme bölümüne göre yaptık. upload/ içindeki dosyaları templates/ hariç mevcut dosyaların üzerine yükledik. Veritabanı adımlarını, admin.php?mod=upgrade sihirbazındaki «devam et» düğmesinin gönderdiği isteklerin aynısıyla çalıştırdık; yalnızca 16 kopyayı art arda geçebilmek için bir betikle. Ardından ana sayfayı, yorumlu bir haberi, aramayı, profili, kaydı, RSS'i ve yönetim panelinin beş bölümünü açtık, sonra PHP hata günlüğüne baktık.

Dağıtım paketi 19 Eylül 2026 tarihli dle21_0.zip. Aynı sürüm numarasını taşıyan ama yönetim paneli dosyaları farklı olan 17 Eylül tarihli bir derleme de var. Hangisinin sizde olduğunu public/adminpanel/javascripts/application.js boyutundan anlayabilirsiniz: 19.09 derlemesinde 275 314 bayt, 17.09 derlemesinde 275 677 bayt.

Hangi sürümden 21.0'a: ne gördük#

Test sitelerinde veri az: yaklaşık 20 haber, 15 yorum ve 13 kullanıcı. Tablodaki PHP, test sitesinin çalıştığı sürüm. 15.1 ve 15.2'de sadece adım sayısı fazla, 10 saniye de oradan geliyor.

Her yerde en uzun süren adım 19.1 → 20.0 oldu, 4,7 saniyeye kadar. Ara sürümlerin dağıtım paketlerine gerek kalmadı: 21.0 arşivinde 7.0 sürümünden itibaren veritabanı güncelleme betikleri var (engine/inc/upgrade/*.php), sihirbaz bunları sırayla çalıştırıyor.

PHP 7.4: beyaz ekran#

15.0 test sitesi PHP 7.4 üzerinde çalışıyor. 21.0 dosyalarını doğrudan oraya yükledik; ana sayfa da admin.php de 500 ve boş sayfa döndürmeye başladı. Apache günlüğünde:

PHP Parse error:  syntax error, unexpected '=>' (T_DOUBLE_ARROW) in …/engine/init.php on line 146
PHP Fatal error:  Uncaught Error: Call to undefined function str_ends_with() in …/engine/inc/include/functions.inc.php:2993

engine/init.php dosyasının 145. satırında bir match ifadesi başlıyor, PHP 8.0 öncesinde ise bu ifade yok. 21.0'ın sistem gereksinimleri de bunu söylüyor: PHP 8.0 ve üzeri, gerekli eklentiler arasında intl. Aynı 15.0 kopyası PHP 8.0 olan bir sunucuda 15 adımda, PHP hatası olmadan güncellendi.

Bu yüzden 15.x veya 16.x üzerindeki bir siteyi önce PHP 8.0+'a taşıyın ve her şeyin çalışıp çalışmadığına bakın (15.1 ve 15.2 bizde 8.0'da çalışıyor). 21.0 dosyalarını ayrı bir adımda yükleyin. PHP değişirken size özgü bir şey bozulabilir, kendi yazdığınız eklemeler ya da eski eklentiler; bunun eski motorda olması daha iyi, çünkü PHP'yi geri almak daha kolay. intl'i sitenin kendisinde phpinfo() ile kontrol edin. Konsoldaki php -m çoğu zaman sitenin kullandığından farklı bir PHP'yi gösterir. 12.x sitelerinde ne yapılacağı aşağıda ayrı bir bölümde.

21.0 sitesini 8.3'ten yeni bir PHP'de çalıştırmadık. Yalnızca sözdizimini kontrol ettik: PHP 8.4 ve 8.5'te php -l, dağıtım paketindeki 329 PHP dosyasının hiçbirinde hata bulmadı.

21.0 güncelleme sırasında neleri siliyor#

İndekslerin yanı sıra 20.0 → 21.0 veritabanı adımı (engine/inc/upgrade/20.0.php) dosya ve ayar da siliyor:

Bir değişikliği yalnızca kodu okuyarak bulduk. 21.0'ın engine/modules/functions.php dosyasında http_get_contents fonksiyonu, bağlandığı sunucunun SSL sertifikasını doğruluyor (CURLOPT_SSL_VERIFYPEER açık, 20.0'da kapalıydı). Sosyal ağlarla giriş (engine/classes/social.class.php), DLE ve eklenti güncelleme kontrolü bu fonksiyondan geçiyor. Kök sertifika seti eski olan bir hostingde bu işlevler yanıt vermez hale gelebilir. Biz buna rastlamadık. Kabaca, sunucudan curl -I https://dle-news.ru/ komutuyla kontrol edebilirsiniz: sertifika hatası çıkarsa hostinge ca-certificates paketini güncellemesini söyleyin. Yalnız PHP kendi sertifika setini kullanıyor olabilir (php.ini'de curl.cainfo, openssl.cafile); o zaman konsol, sitenin gördüğünden farklı bir sonuç gösterir.

21.0 arşivinde şablonlar templates/default_templates.zip içinde duruyor ve set farklı: Air, Chronicle, Cover, Default_Images, Flow, Hub, Overview. 20.0'da Default, Green, Red ve smartphone vardı. Elle güncellemede templates/ klasörü yüklenmez, dolayısıyla site kendi şablonunda kalır. Tüm kopyalarda eski şablonlar hatasız açıldı. 21.0'ın yeni etiketleri bunlara kendiliğinden eklenmez; DLE değişiklik listesini dle-news.ru/templates-changelog.html adresinde tutuyor.

Büyük veritabanı: ne kadar beklenir, 504'te ne yapılır#

Küçük test sitelerinde 20.0 → 21.0 adımı yaklaşık bir saniye sürüyor. Canlı bir site hacminde denemek için bir 20.0 kopyasını 100 480 habere ve 511 440 yoruma kadar şişirdik; bu, indekslerle birlikte 1 095 MB veri demek. Sunucu: 4 çekirdek, 5 GB bellek, MariaDB 11.4, üstüne olağan çalışma yükü.

Adım 28 saniye sürdü ve bunun tamamı, sihirbazın yanıtını beklediği tek bir ajax isteği. max_execution_time sınırını DLE kendisi kaldırıyor, ama web sunucusunun zaman aşımı yerinde kalıyor. Hosting yanıtı yeniden oluşturma bitmeden keserse sihirbaz yanıt koduyla birlikte "HTTP Error:" gösterir, genellikle 504 veya 502. Kendi sunucunuzda güncelleme süresince zaman aşımını yükseltin: nginx'te fastcgi_read_timeout veya proxy_read_timeout, Apache'de Timeout. Paylaşımlı hostingde destekten isteyin ya da güncellemeyi gece yapın. dle-news.ru da sürüm notlarında aynısını öneriyor: sakin saatler ve kaldırılmış sınırlar. İki kat büyük bir veritabanını denemedik; tahminimiz bir dakika civarı.

504 yine de geldiyse, koda göre adım tekrarlanabilir. upgrade/20.0.php içinde sürüm numarası config.php dosyasına veritabanı sorgularından sonra yazılıyor; bu yüzden yarıda kesilen adım sürümü 20.0'da bırakır ve sihirbaz aynı adımı yeniden önerir. İndekslerden yalnızca eksik olanları, SHOW INDEX ile karşılaştırarak ekliyor. Kesintiyi bilerek oluşturmadık, bu kodu okuyarak vardığımız sonuç. Tekrar işe yaramazsa yedeği geri yükleyin (aşağıdaki sıranın 1. adımı).

Forumdaki şikâyetler: neleri tekrarladık#

dle-news.ru forumundaki eylül ayına ait üç konuyu test sitelerinde tekrarladık.

İmzadaki bağlantılar kayboluyor, 18.0'dan beri#

Konu: "DLE 21.0'a güncellemeden sonra kullanıcı imzasındaki bağlantılar kaydedilmiyor" (Rusça). İmzayı sitedeki profil formundan yönetici hesabıyla kaydettik ve dle_users.signature alanına ne yazıldığına baktık.

18.0'dan önce kaydedilmiş imzalar veritabanında hazır <a> etiketiyle duruyor ve güncellemeden sonra da bağlantılı görünüyor. Onları bozan, profilin ilk kez kaydedilmesi. 18.0+ sürümlerde form eski imzayı HTML kodu olarak gösteriyor ve kaydederken <a> kesilip atılıyor. 17.3'te aynı form [url=…] BB kodunu koyardı, bağlantı da yeniden kaydetmeden sağ çıkardı.

Sizde bu tür kaç imza olduğunu öğrenmek için:

SELECT COUNT(*) FROM dle_users WHERE signature LIKE '%<a %';

İmzaya bağlantıyı standart yolla geri getirmek mümkün değil: 18.0+ sürümlerde profil formu (engine/modules/profile.php) ve yönetim panelinde kullanıcı düzenleme (engine/inc/editusers.php) imzayı tüm HTML'i silen bir filtreden geçiriyor, [url] ise artık işlenmiyor. Eklentiyle mümkün.

signature-links.xml dosyasını hazırladık: dört değişiklik, ikisi profil formu, ikisi yönetim paneli için. Eklenti, DLE'nin olağan işleminden sonra [url=https://…]metin[/url] ifadesini bağlantıya çeviriyor (17.3'ün sakladığı biçimin aynısı), düzenleme formunda ise onu yeniden [url=…] olarak gösteriyor; böylece tekrar kaydetmek bağlantıyı artık silmiyor. İşin özü tek satır:

$signature = preg_replace_callback( '#\[url=(https?://[^\]\s\\\\<>]+)\](.+?)\[/url\]#i', function ( $m ) {
	return '<a href=\"' . $m[1] . '\" target=\"_blank\" rel=\"noopener external noreferrer\">' . $m[2] . '</a>';
}, $signature );

Yalnızca http:// veya https:// ile başlayan, boşluk, tırnak ve açılı ayraç içermeyen adresler geçiyor. 21.0'a güncellenmiş bir kopyada denedik: normal bağlantı kaydediliyor ve tekrar kaydetmede kalıyor; [url=javascript:…] ve tırnak ile onmouseover içeren adres düz metin olarak kalıyor; elle yazılmış <a> ve <script> eklentisiz olduğu gibi siliniyor; <a> içeren eski imza kaydedildikten sonra bağlantısını koruyor; yönetim panelinden kullanıcı düzenleme de çalışıyor. Eklentinin koşulu DLE 20.0 ve üstü, ama biz yalnızca 21.0'da çalıştırdık.

"Eski yorumlardaki bağlantılar ana sayfaya gidiyor": bizde tekrarlanmadı#

Konu: "DLE 21.0'a güncellemeden sonra eski yorumlardaki iç bağlantılar ana sayfaya yönlendiriyor" (Rusça). Bir 20.0 kopyasında farklı biçimlerde iç bağlantılar içeren yorumlar bıraktık: haberin tam adresi, göreli /…/158-….html, https yerine http://, index.php?newsid=158 ve engine/go.php ile eski leech biçimi. Bir kısmını ziyaretçilerin kullandığı formdan, bir kısmını doğrudan veritabanına ekledik. 21.0'a güncellemeden sonra bağlantıların HTML'i bayt bayt aynı çıktı, her iç bağlantı kendi haberine gidiyordu. «Geçersiz SEO URL'lerini işle» ayarı açıkken yanlış kategori, haberin eski adı ve ?newsid haberin doğru adresine 301 veriyordu. Leech biçimini sonuna kadar kontrol edemedik: engine/go.php bizim sunucuda nginx tarafından kapalı.

Sizde yine de ana sayfaya gidiyorlarsa, SEO URL'lerini değiştiren eklentilere ya da .htaccess/nginx kurallarına bakın; dosya yüklerken üzerine yazılan .htaccess dahil.

PRISM kapatılabilir mi#

Konu: «DLE 21.0'da PRISM kapatılabilir mi?» (Rusça). Ayarlardan olmaz, eklentiyle olur ve iş beş satır.

PRISM kod renklendiricidir: public/prism/prism.js, 52 440 bayt. 21.0'ın engine/inc/options.php dosyasında bunun için bir anahtar yok. Betik, sayfada <pre geçtiği anda kendiliğinden eklenir: engine/modules/main.php içinde (21.0'da satır 410, 20.0'da 402), ajax ile gelen yorumlar ve özel mesajlar için de engine/ajax/ altındaki dört dosyada: addcomments.php, comments.php, editcomments.php, pm.php.

Beş koşulun hepsini if (false) { ile değiştiren bir eklenti hazırladık: disable-prism.xml. Her eklenti gibi kurulur: «Eklenti yönetimi» → dosyayı yükle. Motor dosyalarına dokunmaz, eklentiyi silince her şey eski haline döner. 21.0'a güncellenmiş bir site kopyasında denedik: eklenti yokken <pre> içeren sayfada prism.js yükleniyor, eklentiyle yüklenmiyor; <pre> bloğu yerinde kalıyor, sadece renklendirme olmuyor. Beş değişikliğin hepsi uygulandı, eklentinin hata günlüğü boş. Eklentideki koşul DLE 20.0 ve üstü: bu satırlar 20.0'da da aynı, ama eklentinin kendisini yalnızca 21.0'da çalıştırdık.

Eklentideki bir işlem şöyle görünüyor (diğer dördü kendi dosyaları için aynısı):

<file name="engine/modules/main.php">
	<operation action="replace">
		<searchcode><![CDATA[if (strpos($tpl->result['main'], "<pre") !== false) {]]></searchcode>
		<replacecode><![CDATA[if (false) {]]></replacecode>
	</operation>
</file>

12.x'ten doğrudan 21.0'a#

Forumdaki "12.1'den 20'ye doğru güncelleme" (Rusça) türünden soruları, windows-1251 kodlamalı ve üç demo haberli temiz bir DLE 12.0 üzerinde denedik: PHP 7.4'e kurduk, Kiril harfli bir yorum ekledik ve PHP 8.0'da 21.0'a kadar getirdik. 13.x ve 14.x sürümlerini denemedik.

İlk engel PHP oldu. 12.0 sürümü 8.0'da açılmıyor:

PHP Fatal error:  Uncaught TypeError: count(): Argument #1 ($value) must be of type Countable|array, null given in …/engine/init.php:86

21.0 ise 7.4'te açılmıyor. İki sürüm için ortak bir PHP yok: 8.0'ı denedik, 12.0 orada zaten çöküyor. Bu yüzden PHP'yi 8.x'e geçirmek ve 21.0 dosyalarını yüklemek aynı bakım penceresinde yapılır, hemen ardından yönetim paneline girilir. Bu sürede site çalışmaz; tam yedek almadan başlamayın.

Veritabanı adımlarının kendisi sorunsuz geçti. Sihirbaz 12.0'dan 21.0'a 25 adım gösterdi (12.1'den 24 olurdu) ve bunları 7,8 saniyede tamamladı. Ardından yönetim paneli kendiliğinden UTF-8'e dönüştürmeye yönlendirdi. Dönüştürmeden önce panelde «Yöneticiler» grup adının yerinde soru işaretli baklavalar görünüyor.

Sihirbaz tabloları tek tek, ardından şablonları dönüştürüyor ve en sonda engine/data/dbconfig.php dosyasına utf8mb4 yazıyor. 59 tablo 8,5 saniye sürdü. Haberlerdeki ve yorumlardaki Kiril metinler sağlam.

Tuzağı kendi hatamız sayesinde bulduk: betiğimizde dbconfig.php adımı tablolardan önce çalıştı. Bundan sonra sihirbaz rahatça «Veritabanı dönüştürmesi gerekmiyor. Tüm tablolar güncel kodlamada.» yanıtını verdi, oysa 59 tablonun hepsi cp1251'de kalmıştı. Sihirbaz dbconfig.php içindeki satıra güveniyor, tabloları kontrol etmiyor. Sizde bu durum yarıda kesilmiş bir sihirbazdan ya da dosyanın elle düzenlenmesinden sonra ortaya çıkar. Kontrol:

SELECT table_collation, COUNT(*)
FROM information_schema.tables
WHERE table_schema = 'veritabani_adi'
GROUP BY 1;

cp1251_general_ci görürseniz dbconfig.php içine define ("COLLATE", "cp1251"); satırını geri koyun ve dönüştürmeyi baştan yapın.

Kendimiz uygulayacağımız güncelleme sırası#

1. Site çalışırken dosyaların ve veritabanının tam yedeğini alın. Komutlar public_html klasörünün bir üst dizininden:
   ТерминалKopyala

   tar czf site-before-21.tgz public_html
   mysqldump --single-transaction -u KULLANICI -p VERITABANI_ADI > db-before-21.sql
   

   Bir şeyler ters giderse geri almak, ikisini de (değiştirdiyseniz PHP sürümünü de) geri yüklemek demek:
   ТерминалKopyala

   rm -rf public_html && tar xzf site-before-21.tgz
   mysql -u KULLANICI -p VERITABANI_ADI < db-before-21.sql
   

2. PHP'yi ve intl'i kontrol edin. DLE 15.x–20.0 ve 8.0'dan eski PHP varsa 8.0+'a önceden, ayrı bir adımda geçin. 12.x sitesinde PHP ve 21.0 dosyaları aynı bakım penceresinde değişir.
3. Kendi .htaccess ve robots.txt dosyalarınızı saklayın: 21.0'ın upload/ klasöründe kendi dosyaları var ve yükleme sizinkilerin üzerine yazar. 21.0'daki bu iki dosya 20.0 dağıtım paketindekilerle aynı, yani motor onlardan yeni bir şey beklemiyor. Arşivdeki engine/data/ boş, config.php ve dbconfig.php dosyalarına dokunulmaz.
4. İmkânınız varsa her şeyi önce bir kopya üzerinde deneyin: alt klasör veya alt alan adı, veritabanı kopyası, engine/data/config.php içinde http_home_url, dbconfig.php içinde veritabanı adı düzeltilir.
5. Siteyi kapatın: «Sistem ayarları» → «Siteyi kapat». «Yöneticiler» grubu kapalı siteyi görür, yönetim paneline girebilirsiniz. Sonra 21.0 arşivindeki upload/ içeriğini, templates/ ve 3. adımdaki iki dosya hariç, mevcut dosyaların üzerine yükleyin ve install.php dosyasını silin. SSH ile, public_html klasörünün bir üst dizininden ve root olarak değil site kullanıcısı olarak çalıştırın; aksi halde yeni dosyaların sahibi başkası olur ve sihirbaz izinlere takılır:
   ТерминалKopyala

   rsync -a --exclude '/templates/' --exclude '/.htaccess' --exclude '/robots.txt' upload/ public_html/
   rm public_html/install.php
   

   FTP ya da hostingin dosya yöneticisiyle de aynısı: upload/ içeriği, templates klasörü ve bu iki dosya hariç, değiştirilerek üzerine yazılır. Bu 1 318 dosya demek, FTP ile yükleme dakikalar sürer.
6. admin.php adresine girin. Yönetim paneli «DataLife Engine güncelleme sihirbazı» ekranını kendisi açar; «devam et» düğmesine basın ve sekmeyi kapatmayın. Sihirbaz «Yazma erişimi olmadığı tespit edildi» yazıp /engine/cache/system/ klasörünü gösteriyorsa, klasör yoktur ya da sahibi yanlış kullanıcıdır. Biz buna önbelleği root olarak sildiğimizde takıldık: klasörü oluşturun ve PHP'nin çalıştığı kullanıcıya verin. Adımlardan sonra önbelleği sihirbaz kendisi temizler. windows-1251 kodlamalı bir site, veritabanı adımlarından sonra UTF-8'e dönüştürme ekranına düşer.
7. Sürümün gerçekten değiştiğinden emin olun: engine/data/config.php içinde 'version_id' => '21.0' olmalı.
8. Siteyi gezin: ana sayfa, yorumlu bir haber, arama, profil, kayıt, RSS, hostingin PHP hata günlüğü.

Test ortamı: DLE 12.0, 15.0–20.0 → 21.0 (19.09.2026 derlemesi), PHP 7.4, 8.0, 8.1, 8.2, 8.3 (8.4 ve 8.5 yalnızca sözdizimi), MariaDB 11.4; dlemod.com test sitelerinin kopyaları, 27.09.2026.

Test edildi: DLE 12.0, 15.0–20.0 → 21.0, PHP 7.4–8.3 — 27.09.2026