SPIP’te veritabanları

Minimal kurulum

Öncelikle tek bir veritabanı ile yapılabilen tüm kurulumları görelim.

Kurulum esnasında SPIP PHP’nin yapılandırmasını test eder ve eğer mümkünse hepsi aynı işlevlere sahip bir çok SQL hizmet birimi arasından bir tanesini seçmenizi ister (şu anda MySQL, PostgreSQL veya SQLite). O anda SQL hizmet biriminin adresi, kullanıcı adı ve şifresi verilmelidir. Bu bilgiler genellikle kurulum dormuna girilir. SPIP çekirdeğinin ortak kullanımı’nı gerçekleştirmek istediğinizde mes_options.php isimli yapılandırma dosyasında bu değerlerden bir veya bir kaçını bildirebilirsiniz. Bu durumda SPIP bu bilgileri istemeyecek ve siz de bu kurulumu kullanacak kişilere bu şifreleri vermek zorunda kalmazsınız. Bu değerleri tanımlamak için kullanılacak sabitlerin isimleri şöyledir:

Bu durumda SPIP belirtilen bilgilerle hizmet birimine bağlanır. Bağlanmada başarılı olursa, kullanıcının veritabanı oluşturma yetkisinin olup olmadığını test eder veya sadece mevcut veritabanlarını görüp bunlardan birini görme yetkisini test eder ya da kendi kullanıcı ismiyle aynı olan bir veritabanını kullanma yetkisi olup olmadığını kontrol eder. Tabii ki önceden mes_options.php dosyasında şu PHP sabitini tanımlayarak kullanılacak veritabanını bildirebilirsiniz :

SPIP SQL tablolarını oluşturarak kurulumu devam ettirir (veya yeniden kurulum yapılıyorsa mevcut tabloların kullanılabilir olup olmadığını test eder). Bu tabloların hepsi (varsayılan değer olarak spip_ olan) bir tablo ön-eki ile başlar ve mes_options.php dosyasında iki şekilde bildirilebilir:

Bu tablo ön-eki şunun gibi kısaltılmış döngüler yazmaya olanak tanır:

<BOUCLE1(ARTICLES)....

halbuki tablonun SQL ismi aslında spip_articles’dir.

SPIP daha sonra bir kullanıcı ismi ve şifre isteyerek sitenin ilk kullanıcısını oluşturur veya bu işlemi bir LDAP hizmet birimine delege etmeyi önerir. Bu tanımlamadan sonra minimal kurulum prosedürü sona erer ve redaksiyon alanına geçiş sayfası görülür : bu sayfada girilmiş olan kimlik tanımlayıcılar istenir. Bu tanımlayıcılar varsayılan olarak config/connect.php ismini alan bir dosyaya kaydedilmiştir.

Kuruluma ek

Bu ana kadar, SPIP’in aynı hizmet birimindeki veya farklı hizmet birimlerindeki veya farklı makinelerdeki bir çok veritabanını nasıl kullanacağını gördük.

Site kurulduğunda,özel alanın üstünden yapılandırma menüsünden site bakımı alt-menüsünü seçin. Bu menü üç sekmeli bir sayfa sunar; sağdakine, ismi başka bir veritabanı tanımlayın olan sekmeye tıklayın. Kurulum formuna benzeyen bir forma ulaşırsınız: bir SQL hizmet birimi tipi belirtmenizi ve internet adresini, bir kullanıcı ismi ve şifresini ister. Bağlantı başarılı olursa SPIP eğer yapabilirse mevcut olanları listeleyerek bir veritabanı ismi ister. Eğer bu veritabanı mevcutsa ek bir bağlantı dosyası oluşturur bu dosya varsayılan olarak config dizinindedir ve belirtilen veritabanının ismini taşır.

Bu da tamamlandığında SPIP aynı forma geri döner ve mevcut bağlantı dosyalarını listeler yani erişilebilir veritabanlarını görüntüler. SPIP yeniden bir ek veritabanı tanımlamanızı ister : tanımlanabilir veritabanı sayısında herhangi bir sınır yoktur.

Bu tanımlamaların yararı bu ek veritabanlarına sayfa düzeni iskeletlerinin notasyonunu uygulayabilmesidir. Eğer ismi B.php olan ve T isimli bir tabloyu sorgulamaya olanak tanıyan bir bağlantı dosyası varsa o zaman şu iskelet

<BOUCLE1(B:T)></BOUCLE1>#TOTAL_BOUCLE<//B1>

bu tablonun satur sayısını verecektir. AYrıca, SPIP SQL hizmet biriminden kendisine bu tabloyu tanımlamasını ister ve alanlarını ve birincil anahtarını öğrenir. Eğer T döngüsü id isimli bir birincil anahtar ve nom isimli bir alan içeriyorsa o zaman şu iskelet:

<BOUCLE1(B:T){id}>#NOM</BOUCLE1>

bağlam tarafından verilen id’ye eşit olan nom alanını verecektir.

Sonuçta, sayfanın URL’sine veritabanının ismini connect parametresiyle vererek döngülerinin varsayılan veritabanından farklı bir veritabanı kullanmasını isteyen bir iskelet uygulanabilir. Örneğin http://benim_sitem?connect=baska_site monsite sitesinin standart sommaire iskeletini config/baska_site.php benim_sitem kurulum dizinindeki bağlantı dosyasının belirttiği veritabanına uygulayacaktır.

Bir döngüde veya connect ile parametre olarak kullanıldığında bağlantı dosyasının isminde büyük/küçük harfe dikkat edilmelidir : SPIP küçük/büyük harflerde hiçbir dönüştürme yapmaz (ama bazı dosya sistemleri bunu yapar).

Uyarı: Ek veritabanlarına erişim özellikle sadece okuma modundadır; özellikle eğer bir veritabanı örneğin bir forumsa (SPIP’le yönetilen veya yönetilmeyen) orijinal sitesi dışından buraya mesaj göndermek olanaksızdır. Bu kısıtlamanın kaldırılması inclenmektedir.

Çapraz kurulum

Burada şunu vurgulamalıyız : yukarıdaki iskelet, B.php isimli bir bağlantı dosyasının mevcudiyetine bağlıdır. Önemli olan ana bağlantı dosyası ve ek veritabanlarının bağlantı dosyaları aynı formatta olmasıdır, bu da SPIP’e has bir durumdur : bir başka SPIP sitesinin bağlantı dosyasını direkt olarak tabloları işlemek için kullanabilmektedir. Bunun için, B sitesinin connect.php dosyası B.php A sitesinin config dizinine kopyalamaktır.

Daha zekice bir yöntem, aynı kurulumu paylaşan SPIP sitelerinin hepsi için tek bir config dizini bulundurmak ve connect.php dosyasına A sitesi için A.php, B sitesi için B.php biçiminde isim vermektir. Böylece SPIP kurulan bir site diğer siteler tarafından bu ortak kurulumu kullanan ek veritabanı olarak tanınacaktır ve bu site de diğer siteleri kendisiyle aynı config dizinini kullanan diğer ek veritabanları olarak görecektir. Bu yapıyı optimum kullanabilmek için _DIR_CONFIG ve _FILE_CONNECT_INS sabitlerini büyük bir özenle tanımlamak gerekir. Aşağıda bu işlevi sunan bir "mutuallisation" örneği bulabilirsiniz.

Uzak bir SQL hizmet birimine kurulmuş bir site için bağlantı dosyasını yerel siteye kopyalamak teoride yeterli olabilir. Ama barındırma firmalarının çoğu SQL hizmet birimlerinin kendi yerel ağları dışındaki uzak makineler tarafından sorgulanmasını kabûl etmezler. Burada ayrıca şuna da dikkat etmek gerekir : kurulumda SQL hizmet birimi için verilen isim hizmet birimine bağıl olarak tanımlanmış olan localhost’tur ama burada mutlak bir adres verilmelidir. Kısaca, SPIP bu mimarî yapıda çalışabilir ama en azından biraz bilgi sahibi olmaktan mükemmel şekilde müdahale edebilmeye kadar konuyu bilmek kaçınılmazdır.

SPIP’te ek veritabanları

Bir bağlantı dosyası bir diğer SPIP sitesinin altındaysa (çapraz kurulum ile orijinal dosya veya kopyası olabilir) bu bize sitenin SPIP içerdiğini gösterir (spip_connect_version global değişkeni atanmıştır). Bu durumda, ana sitenin iskeletleri özel bir davranış biçimiyle uygulanacaktır:

-  kısaltılmış isimli döngüler ek veritabanlarında da kısaltılmış olarak yorumlanacaktır; bir başka deyişle, <BOUCLE1(B:ARTICLES)... (veya connect=B.) içeren bir URL ile <BOUCLE1(B:ARTICLES)...) B veritabanında spip_articles’e referans verecektir, daha net biçimde söylemek gerekirse prefixearticles tablosu, bu tabloda prefixe B sitesi tarafından kullanılandır (bu ön-ek bağlantı dosyasında belirtilmiştir);

-  bir döngünün içinde #URL_ komutları (bkz article 4115) uzak sitenin değil ana sitenin $type_urls kodunu kullanacaktır ve üretilen URL ana siteyi işaret edecektir ama connect=site_distant URL değişkenini ilave edecektir; bu strateji, ama sitenin iskeletlerini kullanmaya devam ederek uzak sitenin veritabanında gezinmeye olanak tanıyacaktır; bir başka deyişle bu iskelet takımının görüntüsünü test edecek ve kurulumu değiştirmeden veya bir kopyası üzerinde çalışmak yerine $type_urls’sini uzak sitede deneyecektir.

-  SPIP kısayolları için hatırlatma sayfası uzak veritabanının alanlarında görülebilecek #URL komutları da bu şekilde yorumlanabilir: [->art3681] uzak sitenin 3681 no’lu makalesine işaret edecek ama bu işi ana sitenin iskeletleri tarafından sunulan sayfa düzenini sunan bir URL ile gerçekleştirecektir.

Bu işletim biçimi sayfa düzeni iskeletleri yazmaya gerek olmadan başka SPIP veritabanlarını sunma olanağı tanımaktadır çünkü veritabanının alan isimleri uzak siteninkilerle aynıdır. Çünkü SPIP altında olmayan bir veritabanı sayfa düzeni iskeletlerine gereksinim duyar ve diğer veritabanının hem tablolarını hem de alanlarını belirtmek zorundadır. Bu ihtiyaca cevap vermek üzere, site yöneticileri özel bir işlemden yararlanır : gezginlerine URL’sini takiben ?page=table:table (table burada veritabanının bir tablosudur) kodunu verdiklerinde SPIP otomatik olarak bu tabloya özel, gayet ergonomik bir içerik incelemesi sunan bir iskelet oluşturacaktır. Üretilen iskelet, sayfanın altındaki squelette bağlantısı aracılığı ile görüntülenebilir. Böylece bu iskeleti fare ile kopyalamak (satırların numaralanmasını sklamak için sütunun sol üstüne tıklayınız) ve uygun bir editör programıyla geliştirmek mümkündür.

Bu otomatik üretim ile SPIP’in hiçbir ön iskelet olmadan çalışabileceğine dikkat edin.

Yedekleme ve Birleştirme

SPIP site bakımı alt-menüsü ile en başından itibaren yerel veritabanı için iki yedekleme ve geri alma gerecine erişim sağlamaktadır (bkz Verilerinizi yedeklemek). SPIP 2.0’dan itibaren eski bir siteden gelen bir yedekleme yeni bir sürüme kurulabilir, ancak bu yöntem çok fazla belek alanı ister ve biz daima orijinal siteyi güncellemenizi, sonra yedek almanızı ve sonra yeni siteye okutmanızı öneririz.

Diğer yandan, 1.8 sürümüne kadar yedekleme ve geri yükleme tamamını etkilerdi. Kısıtlı yönetici statüsünde yapılan birkaç uygunsuz addedilen denemeden sonra SPIP 2.0 yeni ve daha uyumlu bir kısmî yedekleme ve kaynaştırma ile geri alma işlevlerini sunuyor.

Yedekleme formu yedeklemeyi belirli bir bölümle sınırlamayı öneriyor. Üretilen dosya makaleleri, siteleri, kısa haberleri ve alt-bölümleri içerir ve tüm bunların içerdiği anahtar-söcüklerle birlikte anahtar-sözcük gruplarını içerir. Yedeğin ismi varsayılan değer olarak bölümün ismi olacaktır ama değiştirilebilir. Yedek dosyalarının oluşturulması öyle uzun sürebilir ki HTTP hizmet birimi etkin olmadığınız için bağlantınızı kesebilir. Sadece sayfayı tekrar yükleyin : SPIP kaldığı yeri bulu ve işine devam eder. tmp dizininin bir alt-dizininde göreceğiniz çok sayıda geçici dosya gayet normaldir çünkü bu bağlantı kesilmelerinden sonra devam edilebilmesi için alınmış bir önlemdir.

Geri alma formu şu anda iki işlev sunar. Birincisi io anki veritabanının yedklenmiş olanla değiştirilmesidir. İkincisi yedeği eksik bir veritabanı gibi kabûl edip onu mevcut veritabanının üzerine yüklemektir. Mevcut olanla yedek arasında tablolarının (makale tablosu, kısa haber tablosu vb.) numaralanmasında çakışmalar olabileceği için SPIP yedeğin elemanlarını mevcut olanın son numarasından başlatarak yeniden numaralandırır. İkinci geçişte de yeniden numaralandırdığı elemanları transfer eder. Zaten birinci geçişte elemanları karşılaştırıp tekrarları şu kurallara göre elemiştir:

-  mevcut veritabanında aynı isimli bir anahtar-sözcük grubu varsa transfer edilecek bu grup göz ardı edilir;

-  eğer anahtar-sözcük grubu transfer edilmeyen bir anahtar-sözcük bir anahtar-sözcük grubunda orijinal grubu ile aynı ismi taşıyan bir eşanlamlıya sahipse bu anahtar-sözcük göz ardı edilir;

-  mevcut veritabanında sektörde, transfer edilecek bölümle aynı ismi taşıyan bir bölüm varsa bu bölüm göz ardı edilir;

-  eğer bir üstteki başlığı transfer edilmemiş bir alt-başlık aynı akrabalığa sahip bir eşanlamlaıya sahipse bu alt-başlık göz ardı edilir; aynı kural makaleler, kısa haberler ve atıfta bulunulan siteler için de geçerlidir;

-  eğer mevcut veritabanında transfer edilecek bir belge ile aynı isme sahip bir belge varsa ve aynı uzunluktalarsa bu belge göz ardı edilir.

Bir başka deyişle, kaynaştırma işlemi iki veritabanının birleştirilmesidir, tekrarlanan elemanlarda mevcut veritabanının içeriği transfer edileninkine göre önceliklidir (örneğin, aynı isimdeki iki bölümde, mevcut veritabanının texte ve descriptif alanları korunacak ve diğerleri göz ardı edilecektir.).

Ek belgelere gelince, bunlar uzak belgeler olarak transfer edilecek ve parçalı yedekleme ile /IMG dizininin tekrar sayılması ve kopyalanması gerekmeyecektir. Daha sonra kaynak siteye erişmek için her belgede yerel kopyalama düğmesi kullanılabilecektir. Eğer bu düğme kaybolduysa veya alıcı site tarafında aşılamayan erişim kısıtlamalarına sahipse orijinal IMG/ dizini erişilebilir bir URL’ye kopyalanacak ve transfer formunun son kutucuğuna yazılacaktır.

Yayınlandı durumunun Önerildi değerine dönüştürülmesine dikkat edin : bu bize çok yoğun bir transfer yapmamıza rağmen her duruma göre değişen bir yayın politikası oluşturma olanağı tanıyacaktır.

Tam bir örnek

Aşağıdaki "mutualisée" SPIP kurulumu tek bir yapılandirma dizini (_DIR_CONNECT) ve tek bir yedekleme dizini (_DIR_DUMP) olmasını sağlar. Böylece her site diğer sitelerdeki veritabanlarının bir görüntüsünü verebilir, onları birleştirebilir, yedeklerini kullanabilir. Çevrimiçi yardım için de tek bir dizin kullanılmış olur (_DIR_AIDE) çünkü SPIP bu dosyaları spipnet hizmet biriminden transfer eder, Document Type Definitions için de tek bir dizin kullanılmış olur. article 4117 W3C sitesinde veya diğer sitelerde (_DIR_XML) arar .

Haklar ve jurnal hazırlama işlemleri de sadece iki dizin altında toplanmış olur: (_DIR_CHMOD ve _DIR_LOG).

Kök dizinde config/connect, config/chmod, tmp/log, tmp/dump, tmp/xml ve tmp/aide oluşturulacaktır. İlki A veritabanına bağlanmak için A.php dosyasını içerecektir, ikincisi B için B.php vb.

if ( preg_match(',/([a-zA-Z0-9_-]*)[/?],',$_SERVER['REQUEST_URI'],$r)) {
	if (is_dir($e = _DIR_RACINE . 'Ajouts/' . $r[1]. '/')) {
		$cookie_prefix = $table_prefix = $r[1];

		define('_SPIP_PATH', 
		_DIR_RACINE. 'Ajouts/' . $table_prefix  . '/dist/:' .
		_DIR_RACINE .'Ajouts/' . $table_prefix  . '/:' .
		_DIR_RACINE .'dist/:' .
		_DIR_RACINE .'dist/javascript/:' .
		_DIR_RESTREINT);

		$pi = $e . _NOM_PERMANENTS_INACCESSIBLES;
		$pa = $e . _NOM_PERMANENTS_ACCESSIBLES;
		$ti = $e . _NOM_TEMPORAIRES_INACCESSIBLES;
		$ta = $e . _NOM_TEMPORAIRES_ACCESSIBLES;

		$pig = _DIR_RACINE . _NOM_PERMANENTS_INACCESSIBLES;
		$tig = _DIR_RACINE . _NOM_TEMPORAIRES_INACCESSIBLES;

		define('_DIR_DUMP', $tig . 'dump/');
		define('_DIR_AIDE', $tig . 'aide/');
		define('_DIR_CACHE_XML', $tig . "xml/");
		define('_DIR_LOG', $tig . 'log/');
		define('_DIR_CONNECT', $pig . 'connect/');
		define('_DIR_CHMOD', $pig . 'chmod/');
		define('_FILE_CONNECT_INS', $table_prefix);
		define('_FILE_CHMOD_INS', $table_prefix);
		define('_FILE_LOG_SUFFIX',
			 '_' . $table_prefix . '.log');

		$GLOBALS['test_dirs'] =
		  array($pa, $ta, $ti, $pig, $tig,
		_DIR_DUMP, _DIR_LOG, _DIR_CONNECT, _DIR_CHMOD);

		spip_initialisation($pi, $pa, $ti, $ta);
	}
)