Drupal 8.9.x sürümünde denenmiştir. modulname_update_8900 bir kez çalışacaktır. Sonraki kullanımda modulname_update_8901… (+1) olarak güncellemeniz gerekmektedir.
function modulename_update_8900() {
$database = \Drupal::database();
$entityType = 'node';
$fieldName = 'field_yourfield';
$table = $entityType . '__' . $fieldName;
$currentRows = NULL;
$newFieldsList = [];
$fieldStorage = FieldStorageConfig::loadByName($entityType, $fieldName);
if (is_null($fieldStorage)) {
return;
}
// Get all current data from DB.
if ($database->schema()->tableExists($table)) {
// The table data to restore after the update is completed.
$currentRows = $database->select($table, 'n')
->fields('n')
->execute()
->fetchAll();
}
// Use existing field config for new field.
foreach ($fieldStorage->getBundles() as $bundle => $label) {
$field = FieldConfig::loadByName($entityType, $bundle, $fieldName);
$newField = $field->toArray();
$newField['field_type'] = 'text_long';
$newField['settings'] = [];
$newFieldsList[] = $newField;
}
$newFieldStorage = $fieldStorage->toArray();
$newFieldStorage['type'] = 'text_long';
$newFieldStorage['settings'] = [];
// Deleting field storage which will also delete bundles(fields).
$fieldStorage->delete();
// Purge field data now to allow new field and field_storage with same name
// to be created.
field_purge_batch(40);
// Create new field storage.
$newFieldStorage = FieldStorageConfig::create($newFieldStorage);
$newFieldStorage->save();
// Create new fields.
foreach ($newFieldsList as $nfield) {
$nfieldConfig = FieldConfig::create($nfield);
$nfieldConfig->save();
}
// Restore existing data in new table.
if (!is_null($currentRows)) {
foreach ($currentRows as $row) {
$database->insert($table)
->fields((array) $row)
->execute();
}
}
}
Drupal 9’a ait core gereksinimleri composer.json dosyasına eklendikten sonra güncellemeyi başlatabiliriz:
composer update
Güncelleme sonrasında ilk iş olarak önbellek rebuild edilmelidir. Bu esnada, giderilmesi gereken deprecated hataları gözlemlenir.
drush cr
admin/reports/status ekranından INCOMPATIBLE MODULES (Drupal 9 ile uyumsuz olan modüller) görüntülenir. Modüller Drupal 9 ile uyumlu hale getirilmelidir.
Hata mesajı alınan modüle ait config (yaml) dosyası içerisindeki default_value_callback değeri: default_value_callback: ‘Drupal\node\Entity\Node::getCurrentUserId’ yerine, default_value_callback: ‘Drupal\node\Entity\Node::getDefaultEntityOwner’olarak değiştirilmelidir.
php 7.3 üzerinde Drupal 9 uyumsuzluk çözümü
Drupal 9, en düşük PHP sürümü olarak 8 ve üzerini önermektedir. 7.3 ile birlikte kullanımında, bazı paketlerin downgrade edilmesi gerekmektedir. Bu durum stabiliteyi bozmaktadır. Mecbur kalınması durumunda geçici olarak bu yöntem kullanılabilir.
Ayrıntılı sistem hatalarını ekranda göstermek için settings.php dosyanızın sonuna ekleyin.
//append to settings.php
$config['system.logging']['error_level'] = 'verbose';
Sadece notice, warning ve deprecated hataları dışındakilerin gösterilmesini isterseniz, ekrana basılacak uyarıları filtreleyebilirsiniz. Yine settings.php dosyanızın sonuna aşağıdaki satırı ekleyin.
SQL sorguları, Drupal 8 ve 9 yapısına uygun olarak hazırlanmıştır. Views ya da modül oluşturmadan, sorgulardan hızlıca yararlanabiliriz.
İçerik Tipleri (Content Types)
İçerik Tiplerinin Listelenmesi:
select distinct type from node_field_data;
İçerik Tipine Göre Toplam İçerik Sayısı:
select count (nid) from node_field_data where type = 'content_type_name';
İçerik Tipine Göre İçeriklerin Listelenmesi:
select title from node_field_data where type = 'content_type_name';
Toplam İçerik Sayısı:
select count (nid) from node_field_data;
Tablo Birleştirme
select n.title as title,
sd.field_start_date_value as start_date,
ed.field_end_date_value as end_date,
from node_field_data n
left join node__field_start_date sd on sd.entity_id = n.nid
left join node__field_end_date ed on ed.entity_id = n.nid
where type = 'content_type';
Kullanıcılar
Kullanıcıların Listelenmesi:
select uid, name, mail,login from users_field_data;
Kullanıcıya Ait İçeriklerin Listelenmesi:
select * from node_field_data n
left join users_field_data u ON u.uid = n.uid
where u.name = 'username';
Flood Tablosu
5 kez hatalı login-attemp sebebiyle kullanıcılar 6 saatliğine bloklanarak flood tablosuna eklenmektedir.
Flood tablosunu boşaltmak için:
delete from flood;
Tablo index değerini sıfırlayarak flood tablosunu boşaltmak için:
truncate flood;
Watchdog Sorguları
Watchdog Tablolarının Kapladığı Alanları MB Cinsinden Gösteren Sorgu:
SELECT
table_schema as `Database`,
table_name AS `Table`,
round(((data_length + index_length) / 1024 / 1024), 2) `Size in MB`
FROM information_schema.TABLES
where TABLE_NAME = 'watchdog'
ORDER BY (data_length + index_length) DESC;
Database Logging modülü, CMS’teki etkinlikleri veritabanına kaydeder. Watchdog ismi ile de tanınmaktadır. Verilerin kaydedildiği tablonun adı da watchdog’dur. Drupal’in core modüllerinden biri olup kurulumda aktif olarak gelmektedir.
Watchdog Kayıt Türleri
Kullanıcı eylemlerini (giriş, çıkış, yeni kullanıcı vs)
Node (içerik, dosya) ekleme, silme ve değişik bilgilerini (kullanıcı bilgisiyle)
Hata ve uyarıları (php, form, image not found, access denied, modül ekleme)
Cron gibi operasyonel bilgileri
Modül spesifik ve custom modül loglarını kaydetmektedir.
Log sayısı FIFO yapısında rotate olmaktadır. İlk kayıttan sona doğru kayıtlar silinmektedir. Silme işlemi dblog_cron tarafından yapılır ve her cron çalıştığında gerçekleşir.
Drupal Cron Logları
Drupal cron çalıştığında, tüm drupal core cronları ve custom modüller içerisinde yer alan cron hookları çalıştırılmaktadır. Her cron fonksiyonu için watchdog tablosuna kayıt eklenir. Bu, hangi cronların çalıştığını görmek açısından yararlı olabilir ancak db’de ekstra yer kaplayacaktır.
Detaylı cron loglamayı kapatmak için /admin/config/system/cron ekranından gereken ayarlamayı yapabilirsiniz. Bu sayede tüm cronların bilgisini tek satırlık kayda düşürebilirsiniz.
Drupal Cron, her 3 saatte bir kez çalışır. Bu görevi 6 saat, 12 saat, 1 gün, 1 hafta gibi daha geniş bir zamana yayabilirsiniz. Bu işlem sayesinde otomatik bakım daha az sıklıkla yapılacak ve cron logları veritabanını daha uzun sürede dolduracaktır.
Boyutlar (Yaklaşık)
Log kayıtları sınırsız (All) yapılmamalıdır. Bu şekilde unutulursa, diskte, bizden habersiz onlarca GB yer tutabilir.
1000 kayıt ~3 ile 5 MB,
3000 kayıt ~10-15 MB,
10000 kayıt ~25-50 MB,
30000 kayıt ~200-250 MB
100000 kayıt ~1 GB yer kaplamaktadır.
Her üç saatte bir cron çalışan bir sistemde; *Günde ortalama 10 kullanıcı giriş çıkış yaparsa 20 satır kayıt oluşur. *Günde ortalama 10 içerik eklenir ya da güncellenirsa 10 satır kayıt oluşur. *Detaylı cron açıksa günde 8 kez çalışır ve 96 satır kayıt oluşur. Toplamda günlük ortalama 130-150 kayıt gözlemlenebilir ve 1000’lik döngü 1 hafta içerisinde yenilenir.
Diğer hata ve uyarılar, custom modüllere özel loglar hesaplama dışında tutulmuştur.
DBlog vs SysLog
DBlog, hemen hemen tüm olayları db’ye yazdığı için yüksek trafikli sistemlerde, sistemi yavaşlatabilir. Bu durumda, DBlog modülü inaktif duruma getirip Syslog modülünü kurarak, sistem olaylarını sunucunuzun işletim sisteminde loglayabilirsiniz.
Drupal, varsayılan olarak Internal Page Cache ve Internal Dynamic Page Cache isimlerinde iki adet cache modülü ile gelmektedir.
Drupal önbelleği, metadata olarak veritabanında ve _cache prefix’ine sahip tablolarda saklanmaktadır. Cache mekanizmasının dışına çıkılarak, önbelleğin manuel olarak temizlenmesi gerektiği durumlarda:
Drupal arayüzünden “Flush All Caches”
Komut satırı arayüzünden “drush cr”
yapılarak önbellek anlık olarak sıfırlanabilir.
Internal Page Cache
Internal Page Cache, sayfaları anonim ziyaretçiler için önbellekte saklar. Başka bir deyişle, siteyi ziyaret eden kullanıcı, oturum açmamışsa dahi tüm sayfa bilgileri saklanır.
Gelecekteki anonim ziyaretçiler, sayfa sıfırdan oluşturulmadığı için aynı içeriğin son derece hızlı yüklendiğini göreceklerdir.
* Düzenli olarak güncellenen bir site için kullanılması tavsiye edilmez. Genellikle statik verilere sahip, one-page sitelerde tercih edilmesi uygundur.
Internal Dynamic Page Cache
Oturum açmış ya da açmamış olsun, tüm kullanıcılar için her sayfanın küçük bölümlerini önbelleğe almak için tasarlanmıştır. Sayfanın her nesnesi meta veriler içerir ve bu meta veri parçası, Internal Dynamic Page Cache modülüne sayfayı önbelleğe alması gerekip gerekmediğini söyler.
Cache API (Önbelleklenebilir Metadata)
Önbelleğe alınabilir meta verileri üç özellikten oluşur:
Cache Tags
Cache Context
Cache Max-Age
Cache Tags
Entities ve configurations gibi Drupal tarafından yönetilen nesnelere olan bağımlılıktır. Başka bir deyişle, önbelleğin hangi nesneye bağımlı olduğunu tanımlar.
Drupal; node’lar, block’lar, yapılandırma (configuration) ayarları, menüler gibi; her türlü önbellek senaryosunu açıklamak için birden çok cache tag içerir.
Cache Tags, sitedeki bir şey değiştirildiğinde cache girdilerini otomatik olarak geçersiz kılar. Süreye bağlı değildir. Örneğin; Node:5 cache tag’i, id’si 5 olan içeriğin her değiştirilmesinde kendisine ait önbelleğin geçersiz kılınacağını bildirir.
Cache Context
Context’ler, Tag’lerden oldukça farklıdır. Cache context’leri, cache girdilerinin yanında, içeriğin koşullara göre değişecek şekilde önbelleğe alınmasını sağlar.
Örneğin, birkaç farklı rolde kullanıcılarınız var ve rol için içeriğin farklı şekilde önbelleğe alınması gerekiyor… Bu durumda, Cache Tags tek başına yeterli olmayacaktır. “User Permissions” bağlamına sahip cache context tanımlanmalıdır.
Önbelleği ne kadar süre ile geçerli kılmak istediğinizi ayarlayabilirsiniz. max-age: 3600 olarak ayarlarsanız, cache 1 saate kadar geçerli olur. Süre dolduğunda önbellek geçersiz olur. Bir sonraki kişi sayfayı ziyaret ettiğinde önbellek güncellenerek, yeniden 1 saat süreyle geçerli hale gelir. Hiç önbelleğe almak istemiyorsak max-age: 0 olmalıdır.
Tüm özellikleri (Cache Tags, Cache Context, Cache Max-Age) içeren örnek bir kullanım:
Drupal REST Views API cache’leri ilk kez oluşturulurken, gelen request parametresi hatalı ise hatalı dönen response önbelleğe alınır.
Caching yöntemi TAG-BASED ise ilgili içerik güncellenene kadar cache invalidate olmaz. (Hatalı ise hatalı olarak kalır.) Caching yöntemi TIME-BASED ise geçerlilik süresince cache invalidate olmaz. (Hatalı ise süre bitene kadar hatalı olarak kalır.)
Hatalı önbellek durumlarında “Flush All Caches” yapılarak cache rebuild edilmelidir. Caching yöntemleri, REST Export ekranındaki ADVANCED alanında belirlenmektedir.
Hata Oluşmasının Önüne Geçmek
Gelen isteklerin, request parametrelerinin hatalı olmamasına dikkat edilmelidir. Hatalı istekler Reports > Recent log messages ekranında filtrelenebilir. Örnek: Illegal choice zh-Hant in locale element. (zh-hant olmalı) TIME-BASED caching yöntemine geçilerek cache’lerin süreye bağlı olarak invalidate edilmesi tercih edilirse gözden kaçan hatalar kendiliğinden düzeltilebilir.
Drupal Cache ve Memcache Birlikte Kullanımı
Drupal Cache, veritabanında saklanırken; Memcache kullanarak, RAM aracılığı ile daha performanslı bir cache sistemi sunabiliriz. İkisi de farklı katmanlardadır ve birlikte kullanılabilir.
Birlikte kullanım senaryolarında, Drupal cache invalidate ve Memcache lifetime vade süreleri iyi kurgulanmalıdır.
Memcache Kurulumu
Sunucuya Memcache kurulmalıdır.
Memcach contrib modülü CMS’e eklenmeli ve aktif hale getirilmelidir.
settings.php içerisinde memcache konfigürasyonu yapılmalıdır:
Drupal 8.9.x sürümünde denenmiştir. modulname_update_8900 bir kez çalışacaktır. Sonraki kullanımda modulname_update_8901… (+1) olarak güncellemeniz gerekmektedir.
Drupal 8.9.x sürümünde denenmiştir. modulname_update_8900 bir kez çalışacaktır. Sonraki kullanımda modulname_update_8901… (+1) olarak güncellemeniz gerekmektedir.
<?php
function modulname_update_8900()
{
$ozellikler = array(
'type' => 'varchar',
'description' => "Yeni alana ait açıklama",
'length' => 20,
'not null' => FALSE,
);
\Drupal::database()->schema()
->addField('tablo_adi', 'yeni_alan_adi', $ozellikler);
}
Modüller; core, custom, contrib olarak birbirlerinden ayrılır. Core modüller, drupal içerisinde gelen modüllerdir. Contrib modüller; topluluk tarafından katkıda bulunmak amacıyla yayımlanmış, sisteme dışarıdan dahil edilen modüllerdir. Custom modüller ise kendi geliştirdiğimiz modüllerdir.
pm: package manager
pm:list – Geçerli composer paketlerini (modüller ve temalar) listeler.
drush pm:list
drush pm:list --help
pm:enable – Bir veya daha fazla modülü aktif hale getirir.
