How to Disable strict_trans_tables on MariaDB Running with AlmaLinux and D

[Aior]

MariaDB 10.4 ve üzeri sürümler varsayılan olarak STRICT_TRANS_TABLES modunda çalışır. Bu mod, sıfır tarihleri (0000-00-00), boş string'in sayısal alana yazılması veya boyutu taşan değerlerin kabulü gibi geleneksel uygulamaların alıştığı esnek davranışları reddeder. Eski WHMCS, vBulletin, IPB veya bazı yerli CMS'ler bu hatalar nedeniyle "Incorrect integer value" veya "Data truncated" mesajları üretir. AlmaLinux + DirectAdmin sunucularda bu modu kontrollü biçimde kapatmak güvenli ve geri alınabilir bir işlemdir.

1) Mevcut durumu kontrol edin
SSH'da MySQL/MariaDB sürümünü ve sql_mode değerini doğrulayın:

mysql -e "SELECT @@version, @@sql_mode;"

Çıktıda STRICT_TRANS_TABLES geçiyorsa devre dışı bırakılması gereken kısım budur. Aynı modda ERROR_FOR_DIVISION_BY_ZERO veya NO_ZERO_DATE da bulunabilir; uygulamanın gereksinimine göre listeyi düzenleyin.

2) Geçici (runtime) değişiklik
Hızlı bir test için tek seferlik olarak sql_mode'u boşaltabilirsiniz:

mysql -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"

Bu, çalışan bağlantıları etkilemez; yeni bağlantılar yeni mode'u alır. Servis yeniden başlatıldığında değer my.cnf'tan tekrar yüklenir, dolayısıyla bu değişiklik kalıcı değildir. Üretim sunucusunda kalıcı yapmak için bir sonraki adıma geçin.

3) Kalıcı yapılandırma — DirectAdmin için doğru dosya
DirectAdmin'in standart konumu /etc/my.cnf.d/server.cnf veya doğrudan /etc/my.cnf'dir. [mysqld] bölümüne aşağıdaki satırı ekleyin:

[mysqld]
sql_mode="NO_ENGINE_SUBSTITUTION"

Eğer mevcut bir sql_mode satırı varsa, içindeki STRICT_TRANS_TABLES, NO_ZERO_DATE ve ERROR_FOR_DIVISION_BY_ZERO değerlerini silmeniz yeterlidir. NO_ENGINE_SUBSTITUTION makul bir varsayılan olarak kalmalıdır.

4) Servisi yeniden başlatın

systemctl restart mariadb

Komut hata vermezse durumu yeniden doğrulayın:

mysql -e "SELECT @@sql_mode;"

Çıktı sadece NO_ENGINE_SUBSTITUTION içeriyorsa değişiklik aktiftir. DirectAdmin paneli zaten mevcut bağlantıları yenileyecektir; PHP-FPM havuzlarınız çoklu kalıcı bağlantı kullanıyorsa /sbin/service php-fpm restart iyi bir tamamlayıcı adımdır.

5) Veri tutarlılığı uyarısı
strict_trans_tables'ı kapatmak, hatalı uygulamaların boş veya geçersiz değerleri sessizce yazmasına izin verir. İdeal yaklaşım uygulamayı düzeltmek, sql_mode'u olduğu gibi bırakmaktır. Ancak eski sistemlerde uygulamayı düzeltmek imkânsız olduğunda bu modu kapatmak geçerli bir geçici çözümdür. Yeni geliştirmelerde aynı yola gitmeyin.

6) Uygulamaya özel notlar

• WHMCS 8.x: STRICT_TRANS_TABLES + ONLY_FULL_GROUP_BY birlikte sorun çıkarır. Önerilen: sql_mode="NO_ENGINE_SUBSTITUTION".
• vBulletin 4.x: NO_ZERO_DATE ve STRICT_TRANS_TABLES kapalı olmalı.
• XenForo 2.x: STRICT_TRANS_TABLES ile sorunsuz çalışır; bu addonu kapatmak XenForo için gerekmez.

7) Geri alma
my.cnf içindeki satırı silip yeniden başlatın. Veritabanı korunmuş veriyle birlikte tekrar STRICT moduna döner. Bu güvenli bir geri alma rotasıdır.

Bu yapılandırma değişikliği, DirectAdmin altındaki çoklu siteleri etkileyen MariaDB davranışını uyumlu hâle getirir ve yıllarca güncellenmemiş PHP uygulamalarının çalışmasını sağlar.

MariaDB 10.4 and later enable STRICT_TRANS_TABLES by default. The mode rejects legacy behaviour that older PHP applications expect — zero dates like 0000-00-00, an empty string written to an integer column, or a value that exceeds the declared column size. WHMCS 7.x, vBulletin 4.x and a handful of older Turkish CMSes throw "Incorrect integer value" or "Data truncated for column" errors as a result. On a DirectAdmin/AlmaLinux server this can be controlled with a small, reversible config change.

1) Inspect the current state
From SSH check the MariaDB version and sql_mode:

mysql -e "SELECT @@version, @@sql_mode;"

If STRICT_TRANS_TABLES appears, that is the offending flag. ERROR_FOR_DIVISION_BY_ZERO and NO_ZERO_DATE often appear alongside it; treat them as a package depending on what the application needs.

2) Runtime change for testing
For a quick test, run:

mysql -e "SET GLOBAL sql_mode = 'NO_ENGINE_SUBSTITUTION';"

Existing connections keep their old mode; new ones pick up the new one. The change is wiped on service restart because my.cnf is reloaded, so for production it is only a probe to confirm "yes, this fixes the application before I make it permanent."

3) Persistent configuration on DirectAdmin
DirectAdmin's standard MariaDB config is at /etc/my.cnf.d/server.cnf or directly in /etc/my.cnf. Inside the [mysqld] section add:

[mysqld]
sql_mode="NO_ENGINE_SUBSTITUTION"

If a sql_mode line already exists, strip out STRICT_TRANS_TABLES, NO_ZERO_DATE and ERROR_FOR_DIVISION_BY_ZERO. Leave NO_ENGINE_SUBSTITUTION as a sensible baseline.

4) Restart the service

systemctl restart mariadb

Verify the new state:

mysql -e "SELECT @@sql_mode;"

If the output now reads NO_ENGINE_SUBSTITUTION the change is live. Restarting PHP-FPM with systemctl restart php-fpm is a nice complement if your stack reuses persistent connections.

5) Data integrity caveat
Disabling strict mode lets misbehaving applications quietly insert invalid values. The best long-term solution is to fix the application; flipping the database mode is a pragmatic workaround for systems that are too old to fix. Do not adopt this as a default for new code.

6) Application-specific notes

• WHMCS 8.x: STRICT_TRANS_TABLES combined with ONLY_FULL_GROUP_BY breaks several pages. Use sql_mode="NO_ENGINE_SUBSTITUTION".
• vBulletin 4.x: Disable NO_ZERO_DATE alongside STRICT_TRANS_TABLES.
• XenForo 2.x: Works fine with STRICT_TRANS_TABLES on; do not disable for XenForo's sake.

7) Rollback
Remove or comment the new line and restart MariaDB. Data already written stays as-is; the engine simply becomes strict again going forward. This is a safe revert path that doesn't require any data migration.

The end result is a MariaDB configuration that hosts legacy PHP applications under DirectAdmin without spamming the user with "Incorrect integer value" errors, while leaving the rest of the engine semantics intact.