SPIP http://www.spip.net/ Système de Publication pour Internet fr SPIP - www.spip.net SPIP http://www.spip.net/local/cache-vignettes/L144xH49/siteon0-56029.jpg http://www.spip.net/ 49 144 yesSystème de Publication pour Internet Las autorreferencias multilingües de la documentación http://feedproxy.google.com/~r/Spip/~3/fvAczg_Ss00/es_article4157.html http://www.spip.net/es_article4157.html 2009-07-14T09:03:20Z text/html es David Sánchez <p>Este artículo explica por qué es necesario utilizar el atajo <code class='spip_code' dir='ltr'>[{}->artN] </code> para referenciar el artículo N de la documentación, cualquiera que sea el idioma del artículo referenciado o del texto que lo referencia.</p> - <a href="http://www.spip.net/rubrique413.html" rel="directory">Traducir SPIP</a>

Ya que la versión SPIP 2.0 ha introducido la posibilidad de sobrecargar el tratamiento de hreflang de los atajos tipográficos, el presente sitio dedicado a la documentación multilingüe de SPIP ofrece actualmente un método sencillo para referenciar sus propios artículos.

Anteriormente, cuando un artículo A referenciaba un artículo B de la documentación, quienes lo traducían se encontraban ante una situación insatisfactoria y propicia al olvido. Se traducía primero A y se obtenía otro artículo, llamémosle C, dentro del cual se dejaba la referencia a B, sin tener todavía la URL de la traducción de B, ya que aún no existía. Durante el tiempo que esta traducción, llamémosle D, era realizada y publicada, era muy fácil olvidar que C contenía una referencia a B que había que reemplazar por D.

En este momento, los redactores de la documentación tienen que utilizar obligatoriamente la notación [{}->artN] para referenciar el artículo N de la documentación, y quienes lo traduzcan pueden copiar este atajo sin necesidad de modificarlo en el futuro. En efecto, si el artículo N no existe en la lengua del texto que utiliza este atajo, éste presentará la URL del artículo N (aquel que sea mejor). En cambio, si existe una traducción, se presentará automáticamente la URL de esa traducción. Más exactamente, este comportamiento se observará estrictamente cuando haya una referencia en el espacio privado, mientras que en el espacio público se añadirá la condición suplementaria de que la traducción esté publicada, para presentar una URL disponible en el acto.

¿Cómo es esto posible? De hecho, hacía ya mucho tiempo que los atajos de SPIP autorizaban la utilización de llaves para especificar el valor del atributo hreflang. No obstante, SPIP 2.0 interpreta además un par de llaves vacías como un hreflang igual al idioma del texto donde figura el atajo. La sobrecarga introducida por este sitio consiste simplemente en buscar si el artículo designado por el atajo existe en el idioma indicado por el hreflang. Si es este el caso, el atajo ->artN se reemplaza por ->artP, donde P es la traducción de N.

]]> http://www.spip.net/es_article4157.html Structure HTML des formulaires de SPIP 2 http://feedproxy.google.com/~r/Spip/~3/GgSD6wgKpP8/fr_article3791.html http://www.spip.net/fr_article3791.html 2009-06-27T10:48:14Z text/html fr ARNO*, cerdic, Matthieu Marcillaud, romy.tetue.net Document de références précisant comment les formulaires dans SPIP doivent être structurés Structure HTML Un formulaire de base est ainsi structuré : <div class="formulaire_spip formulaire_editer formulaire_editer_nomformulaire" id="formulaire_editer_nomformulaire-id"> <a id="nomformulaire" name="nomformulaire"></a> <form action="#" method="post"> <fieldset> <legend>Une légende</legend> (...) - <a href="http://www.spip.net/rubrique522.html" rel="directory">Interactivité</a>

Document de références précisant comment les formulaires dans SPIP doivent être structurés

Structure HTML

Un formulaire de base est ainsi structuré :

Le div englobant porte la classe générique formulaire_spip. Les formulaires d'édition de l'espace privé portent de plus la classe formulaire_editer indiquant qu'on a affaire à un formulaire d'édition de données d'une base.

Le premier fieldset étant optionnel, on peut aussi écrire, sans le fieldset et sans les paragraphes optionnels :

Les classes spéciales

  • « explication » : pour indiquer un message d'explication (qui porte soit pour l'ensemble des champs, soit sur une étape). Exemple :

    .

  • « attention » : pour afficher un message concernant un champ d'édition critique. Exemple : <:texte_login_precaution:>.
  • « obligatoire » : pour signaler un champ obligatoire, à appliquer à l'élément de liste parent. Exemple :
  • .
  • « erreur » : pour signaler une étape en erreur, à appliquer à l'élément de liste parent. Exemple :
  • . chaque erreur bénéficie d'un message explicatif, portant la class « erreur_message » : .

Cadre englobant

Ce formulaire peut optionnelement être inclu dans un cadre-formulaire-editer, et peut alors contenir un entete-formulaire :

Gestion des messages réussite/erreur

Messages globaux

Un formulaire comporte obligatoirement deux paragraphes permettant d'afficher les réussites et erreurs globales qui ont pu apparaître à la soumission. Les variables d'environnements message_ok et message_erreur sont des retours envoyés par SPIP (formulaires CVT).

Messages spécifiques

Chaque champ de formulaire, encapsulé dans un li peut recevoir un message d'erreur spécifique. Celui-ci est contenu dans la le tableau d'environnement 'erreurs' et peut être obtenu de la sorte :

On peut attribuer la classe 'erreur' au li et afficher une erreur spécifique si elle existe de la sorte :

Particularités pour les styles css

Champs input

Chaque différent de hidden doit posséder une classe identique à son type (afin de palier à un déficience du navigateur Internet Explorer) :

Boutons de soumission

Les boutons de soumissions sont inclus dans une boîte .boutons (qui peut recevoir plusieurs boutons) :

radio/checkbox

Dans le cas de bouton radio ou checkbox, on peut ne pas reprendre tout a fait la même structure, par exemple pour avoir le bouton avant le label, ou pour avoir la liste radio en horizonal

Chaque entrée (radio + label) peut alors être encadrée par un bloc .choix

Par défaut, la liste est verticale. Pour rendre la liste horizontale, il suffit de spécifier que .champ en question est de type inline :

.formulaire_editer .editer_syndication .choix {display:inline;}

Principes généraux de ces formulaires pour avoir les labels alignés à gauche

On se retrouve dans un cas où l'on a :

1) on applique un padding gauche au LI supérieur à la taille du label (ex:120px)

2) on demande au label d'être flottant et décalé sur la gauche (via un margin négatif)

3) lorsqu'un fieldset suit un li, on le décale aussi vers la gauche (seul IE n'en tient pas compte) pour que le fieldset prenne toute la largeur aussi

]]> http://www.spip.net/fr_article3791.html #VAL http://feedproxy.google.com/~r/Spip/~3/IZ_49INI21E/fr_article4026.html http://www.spip.net/fr_article4026.html 2009-06-18T09:15:46Z text/html fr maieul La Balise #VAL prend un paramètre qui est retourné tel quel. Elle permet par exemple d'appliquer des filtres sur des constantes. Par exemple [(#VAL<:chaine_de_langue:>|image_typo)] - <a href="http://www.spip.net/rubrique543.html" rel="directory">balises</a>

La Balise #VAL prend un paramètre qui est retourné tel quel.

Elle permet par exemple d'appliquer des filtres sur des constantes.

Par exemple [(#VAL{<:chaine_de_langue:>}|image_typo)]

]]> http://www.spip.net/fr_article4026.html #ARRAY http://feedproxy.google.com/~r/Spip/~3/zYdxwzRpxaQ/fr_article4009.html http://www.spip.net/fr_article4009.html 2009-06-16T06:52:27Z text/html fr BoOz, denisb #ARRAY La balise #ARRAY définit un tableau au sens php c'est à dire un ensemble de paires clef/valeur. Un #ARRAY permet ainsi le stockage de valeurs indexées et peut être utilisé, entre autre, associé à l'opérateur IN d'une boucle. Déclarer un tableau : #SETmon_tableau, #ARRAYclef1,valeur1,clef2,valeur2... Récupérer la valeur associée à une clef en utilisant le filtre |table_valeur : [(#GETmon_tableau|table_valeurclef)] Remplir un tableau dynamiquement en utilisant le filtre |push : #SETmots_choisis, (...) - <a href="http://www.spip.net/rubrique543.html" rel="directory">balises</a> / <a href="http://www.spip.net/@array" rel="tag">#ARRAY</a>

La balise #ARRAY définit un tableau au sens php c'est à dire un ensemble de paires clef/valeur. Un #ARRAY permet ainsi le stockage de valeurs indexées et peut être utilisé, entre autre, associé à l'opérateur IN d'une boucle.

- Déclarer un tableau :

#SET{mon_tableau, #ARRAY{clef1,valeur1,clef2,valeur2...}}

- Récupérer la valeur associée à une clef en utilisant le filtre |table_valeur :

[(#GET{mon_tableau}|table_valeur{clef})]

- Remplir un tableau dynamiquement en utilisant le filtre |push :

#SET{mots_choisis, #ARRAY{}}

[(#SET{mots_choisis, #GET{mots_choisis}|push{#ID_MOT}})]

ou encore en forçant la valeur des clefs avec la fonction php utilisée comme filtre |array_merge :

#SET{mots_choisis, #ARRAY{}}

[(#SET{mots_choisis,
[(#GET{mots_choisis}|array_merge{#ARRAY{
#COMPTEUR_BOUCLE, #ID_MOT
}})]
})]

Attention 1 : le filtre |array_merge ne tient pas compte de la clef à forcer (#COMPTEUR_BOUCLE dans l'exemple ci-dessus) si cette clef est de type numérique. Auquel cas deux solutions :

  • soit préfixer cette clef avec une valeur alphabétique :#ARRAY{k#COMPTEUR_BOUCLE, #ID_MOT} ;
  • soit inverser clef et valeur (à condition que valeur ne soit pas elle aussi numérique) puis appliquer la fonction php comme filtre |array_flip sur le tableau final :[(#SET{mots_choisis, #GET{mots_choisis}|array_flip)]

Attention 2 : il faut déclarer le tableau avant son remplissage dans la boucle.

Note 1 : l'ordre de remplissage du tableau est déterminé par l'ordre d'apparition des données dans la boucle, donc est dépendant du ou des critères de tri qui sont appliqués à celle-ci.
Note 2 :[(#GET{mon_tableau}|table_valeur{6})] affichera la valeur associée à la clef numéro 6 du tableau ; c'est-à-dire la 7ème valeur : la numérotation des clefs débutant à zéro.

- Utiliser le tableau dans une boucle avec l'opérateur IN :


...

- Affichage conditionnel en fonction des valeurs d'un tableau :

[(#ENV{page}|in_array{#ARRAY{0,article,1,rubrique,2,site}}|oui)
Affichage conditionnel ]

autre exemple avec une variable 'lolo' passée dans l'url :
http://le_site/-ma-rubrique-?lolo=6

[ Ceci s'affichera si la valeur de la variable 'lolo' passée dans l'url est présente dans un tableau 'les_mots' déclaré et rempli précédemment
(#ENV{lolo}|in_array{#GET{les_mots}}|oui)
celà s'affichera aussi ]

Pour ne pas risquer de générer une erreur « Warning : in_array() [function.in-array] : Wrong datatype for second argument. » dans le cas où la variable passée ne serait pas de type array on pourra utiliser le filtre |in_any qui rattrape l'erreur sans afficher l'alerte, et permet d'afficher une valeur alternative.

[(#VAL{abc}|in_any{#GET{tablo}, truc à faire si GET_tablo n'est pas un array}|oui|?{truc à faire si abc est une valeur de GET_tablo, truc à faire si abc n'est pas une valeur de GET_tablo})]
]]> http://www.spip.net/fr_article4009.html Mise à jour 1 .9 .x vers 2 .0 .8 http://feedproxy.google.com/~r/Spip/~3/WOYqfQpOvC4/fr_article4121.html http://www.spip.net/fr_article4121.html 2009-05-29T06:51:09Z text/html fr denisb Niveau : facile SPIP 2.0 La version 2 de SPIP étant une version majeure, la mise à jour d'un site depuis une version 1.9.x est particulière. Quelques conseils pour que la transition se fasse au mieux désactiver tous les plugins par la page : ecrire/ ?exec=admin_plugin faire une sauvegarde de la base de données en utilisant la procédure de spip 1.9.x : ecrire/ ?exec=admin_tech (voir détails) récupérer cette sauvegarde par FTP (elle se trouve dans tmp/dump/) et la conserver soigneusement en local. créer un répertoire à la (...) - <a href="http://www.spip.net/rubrique151.html" rel="directory">Installation</a> / <a href="http://www.spip.net/@niveaufacile" rel="tag">Niveau : facile</a>, <a href="http://www.spip.net/@spip20" rel="tag">SPIP 2.0</a>

La version 2 de SPIP étant une version majeure, la mise à jour d'un site depuis une version 1.9.x est particulière.

Quelques conseils pour que la transition se fasse au mieux

  1. désactiver tous les plugins par la page : ecrire/ ?exec=admin_plugin
  2. faire une sauvegarde de la base de données en utilisant la procédure de spip 1.9.x : ecrire/ ?exec=admin_tech (voir détails)
  3. récupérer cette sauvegarde par FTP (elle se trouve dans tmp/dump/) et la conserver soigneusement en local.
  • créer un répertoire à la racine de SPIP (par exemple ancien_spip/)
  • déplacer à l'intérieur de ce répertoire tous les fichiers et répertoires de spip 1.9.x SAUF les répertoires IMG/ et config/
  • si vous aviez un fichier mes_options.php le déplacer dans config/
    • ne devrait donc rester à la racine que :
      • ancien_spip/
      • config/
      • IMG/

- déposer par FTP, à la racine de son site, l'ensemble des fichiers et répertoires de SPIP 2.0.8 sauf les répertoires IMG/ et config/

  • devraient donc se trouver à la racine :
    • ancien_spip/
    • CHANGELOG.txt
    • config/
    • COPYING.txt
    • ecrire/
    • htaccess.txt
    • IMG/
    • index.php
    • INSTALL.txt
    • local/
    • prive/
    • rien.gif
    • spip.php
    • squelettes-dist/
    • svn.revision
    • tmp/

- entrer avec son navigateur dans http://le_site/ecrire/
- accepter la mise à jour de la base de données

  • à ce stade, vous devriez retrouver, dans l'espace privé, l'intégralité des données de votre ancien site et une navigation dans l'espace public devrait les afficher avec les squelettes par défaut de spip (couleur mauve)
  • en cas de problème (page blanche par exemple), essayer de renommer temporairement votre fichier mes_options.php (dans le répertoire config/) pour le désactiver.

- récupérer maintenant les version adaptées à spip 2 des plugins que vous utilisiez et installer ces nouvelles versions dans un répertoire plugins/ à créer.
ou bien, après avoir créé un répertoire plugins/ puis son sous-répertoire auto/ utiliser la procédure d'auto-installation des plugins proposée dans la page ecrire/ ?exec=admin_plugin

- reste à créer un répertoire squelettes/ (si vous en avez l'utilité) et y déplacer calmement, par petits groupes, vos anciennes personnalisations récupérées depuis ancien_spip/squelettes/

- si vous aviez un fichier mes_fonctions.php, vérifier la conformité de ses fonctions et déclarations avec les nouvelles fonctions et variables de spip 2.0.8
- idem si des scripts php sont présents dans vos squelettes personnalisés

- si vous n'avez pas déjà un .htaccess actif, il vous faudra renommer htaccess.txt en .htaccess pour bénéficier des urls propres, arbo...

LES SQUELETTES

rappel :
les fichiers rangés dans votre répertoire squelettes/ prennent le pas sur ceux placés par défaut dans squelettes-dist/ ou dans prive/

si vous avez, en 1.9.x, copié l'organisation de votre répertoire squelettes/ sur celle de dist/ , sachez que 2.0.8 apporte des modifications importantes à cette organisation et qu'il vous faudra veiller à ne pas avoir des fichiers fantômes appelés en lieu et place des légitimes.
en particulier, un ancien squelettes/login.html tout comme squelettes/formulaires/login.html prendront le pas (et ce pourra être un problème) sur prive/login.html et prive/formulaires/login.html.

attention aussi aux fichiers de feuille de style et aux fichiers de script javascript.

- liste des fichiers qui étaient dans dist/ (que vous avez peut-être personnalisés dans squelettes/) et qui ont été déplacés ou supprimés :

ancien nouveau
dist/favicon.ico supprimé
dist/jquery.js.html supprimé
dist/login.html prive/login.html
dist/sommaire_texte.html supprimé
dist/spip_admin.css prive/spip_admin.css
dist/spip_style_invisible.css privé/spip_style_invisible.css
dist/spip_style_print.css prive/spip_style_print.css
dist/spip_style_visible.css prive/spip_style_visible.css
dist/spip_style.css prive/spip_style.css
dist/style_prive_defaut.css prive/style_prive_defaut.css
dist/style_prive.html prive/style_prive.html
dist/formulaires/choix_mots.html supprimé
dist/formulaires/forum_previsu.html supprimé
dist/formulaires/login_forum.html supprimé
dist/formulaires/login.html prive/formulaires/login.html
dist/formulaires/menu_lang.html prive/formulaires/menu_lang.html
dist/modeles/doc.html prive/modeles/doc.html
dist/modeles/emb.html prive/modeles/emb.html
dist/modeles/img.html prive/modeles/img.html
dist/modeles/pagination_page_precedent_suivant.html prive/modeles/pagination_page_precedent_suivant.html
dist/modeles/pagination_page.html prive/modeles/pagination_page.html
dist/modeles/pagination_precedent_suivant.html prive/modeles/pagination_precedent_suivant.html
dist/modeles/pagination.html prive/modeles/pagination.html
dist/modeles/paginationitem.html prive/modeles/paginationitem.html
dist/icones_barre/ prive/icones_barre/
dist/images/ prive/images/
dist/javascript/ prive/javascript/
dist/vignettes/ prive/vignettes/

d'une manière générale, s'inspirer des nouveaux squelettes de squelettes-dist/ et prive/ pour reprendre et mettre à jour vos personnalisations dans squelettes/

si vous avez déjà effectué votre mise-à-jour en déposant les fichiers de spip 2.0.8 sur votre spip 1.9.x, alors il reste sans doute d'anciens fichiers devenus obsolètes et que vous pouvez supprimer :

- passage de 1.9.2h stable [13886] à 2.0.8 stable [13982]
ces fichiers qui existaient en 1.9.x, sont, en 2.0.8, soit supprimés, soit déplacés
(cela concerne essentiellement le répertoire ecrire/ et ses sous-répertoires) il convient de les supprimer

- ecrire/action/autoriser.php
- ecrire/action/ical.php
- ecrire/action/inscription.php
- ecrire/action/instituer_mot.php
- ecrire/action/instituer_rubrique_articles.php
- ecrire/action/pass.php
- ecrire/action/rss.php
- ecrire/action/test_dirs.php

- ecrire/base/db_mysql.php
- ecrire/base/optimiser.php

- ecrire/engines-list.txt

- ecrire/exec/articles_ortho.php
- ecrire/exec/editer_mot.php attention !!! ne pas confondre avec 'ecrire/exec/editer_mots.php' (pluriel) qui est bien un fichier 2.0.8
- ecrire/exec/export.php
- ecrire/exec/forum_envoi.php
- ecrire/exec/puce_statut_article.php
- ecrire/exec/rubriquer.php
- ecrire/exec/statistiques_svg.php

- ecrire/extract/doc.php
- ecrire/extract/pdf.php
- ecrire/extract/rtf.php

- ecrire/inc/auth_ldap.php
- ecrire/inc/auth_spip.php
- ecrire/inc/compacte_js.php
- ecrire/inc/cron.php
- ecrire/inc/editer_article.php
- ecrire/inc/editer_mot.php attention !!! ne pas confondre avec 'ecrire/inc/editer_mots.php' (pluriel) qui est bien un fichier 2.0.8
- ecrire/inc/extra.php
- ecrire/inc/indenter_xml.php
- ecrire/inc/indexation.php
- ecrire/inc/maintenance.php
- ecrire/inc/ortho.php
- ecrire/inc/popularites.php
- ecrire/inc/sax.php
- ecrire/inc/sites_voir.php
- ecrire/inc/valider_xml.php
- ecrire/inc/visites.php

- ecrire/install/etape_5.php
- ecrire/install/etape_6.php

- ecrire/safehtml/classes/HTMLSax3.php
- ecrire/safehtml/classes/safehtml.php
- ecrire/safehtml/classes/HTMLSax3/Decorators.php
- ecrire/safehtml/classes/HTMLSax3/States.php
- ecrire/safehtml/license.txt
- ecrire/safehtml/readme-SPIP.txt
- ecrire/safehtml/readme.txt

- ecrire/urls/propres-qs.php attention !!! ne pas confondre avec 'ecrire/urls/propres_qs.php' (underscore) qui est bien un fichier 2.0.8

- ecrire/xml/atom.php
- ecrire/xml/ical.php
- ecrire/xml/rss.php

- ecrire/win_png.htc


- le répertoire dist/ et tous ses fichiers (voir plus haut LES SQUELETTES)

- le répertoire oo/ et son fichier index.php

- les 3 fichiers à la racine :

  • inc-public.php3
  • UPGRADE.txt
  • win_png.htc
]]> http://www.spip.net/fr_article4121.html SPIP çekirdeğinin ortak kullanımı http://feedproxy.google.com/~r/Spip/~3/KoxBIPzomnU/tr_article4114.html http://www.spip.net/tr_article4114.html 2009-05-28T06:25:23Z text/html tr mega <p>SPIP çekirdeğini birçok site arasında ortak kullanma prosedürü</p> - <a href="http://www.spip.net/rubrique590.html" rel="directory">Optimizasyon / Sistem</a>

SPIP çekirdeğinin ortak kulanımı SPIP 1.9'dan itibaren mümkündür. Amaç bir çok SPIP sitesini, tek bir SPIP çekirdeği kullanark tek bir hizmet birimi veya barındırma firması üzerinden idare etmektir.

Bu, önemli derecede disk alanı kazanmamızı sağlar, aynı zamanda çok basit bir güncelleme olanağı tanır çünkü sadece çekirdğei güncellemek yeterli olacaktır.

SPIP 1.9.1 daki gelişmeler prosedürü biraz kolaylaştırdı ama SPIP 1.9.2 ve getirdiği geliştirmeler [1] ortak kullanımı çok daha sağlam hale getirdi cve SPIP çekirdeğinin paylaşılmasına olanak tanıdı.

Bu makale SPIP 1.9.2 için Apache hizmet birimlerine kurulumunu açıklamaktadır [2] ve url'lerin yeniden yazılmasına izin vermektedir. (url_rewriting).

Aynı sonuca götüren birçok yöntem vardır : önemli olan ortak kullanımın bir hizmet biriminden mi yoksa bir barındırma firmasından mı yapılacağına karar vermektir.

Kavram ...

SPIP 1.9.2'ten itibaren SPIP çekirdeğinin işletilmesi için gerekli dizinler (ecrire, squelettes-dist, oo) ve bir sitenin etkinliğini gösterenler (config, IMG, tmp, local) tamamen ayrılmış ve belirlenebilirdir. Bu ayrılmışlık, tek bir SPIP çekirdeği etrafında bir çok otonom SPIP sitesini olanaklı kılar.

Bu otonomluk site başına 4 dizin olmasına bağlıdır. Spip bunlara site etkinliklerini yazar. Bu dizinler 4 tanedir çünkü bir yandan kalıcı ve geçici veriler, diğer yandan http ile erişilebilen veya erişilemeyen veriler vardır : yani 4 tip veri. Http ile erişilemeyen 2 dizin SPIP tarafından otomatik olarak kurulan bir .htaccess ile korunur (hizmet birimi idarecileri bu dizinleri http tarafından hizmet verilen ağaç yapısının dışına da yerleştirebilirler).

SPIP 1.9.2'den önce, bu 4 veri tipi tam olarak ayrılmış değildi ve IMG, CACHE, ecrire ve ecrire/data dizinlerinde bulunuyorlardı. SPIP 1.9.2 ile, bu 4 dizin tamamen ayrılmıştır ve şu PHP sabitleriyle adlandırılmıştır :

define('_NOM_TEMPORAIRES_INACCESSIBLES', "tmp/");
define('_NOM_TEMPORAIRES_ACCESSIBLES', "local/");
define('_NOM_PERMANENTS_INACCESSIBLES', "config/");
define('_NOM_PERMANENTS_ACCESSIBLES', "IMG/");

Ortak kullanıma açık olmayan bir SPIP kurulumunda bu dizinler spip_initialisation fonksiyonunun uygulanması esnasında yukarıdaki 4 değer sayesinde sitenin kök dizininde oluşturulur. SPIP kaynaklarının ortak kullanımını sağlamak için spip_initialisation fonksiyonunu URL'den elde edilen 4 değişik değer üzerinden özel bir URL'yi özel dizinler dörtlüsüne bağlamak yeterlidir.

Doğru dizinleri oluşturmak

Ortak kullanımı başlatmak için önce işlevsel bir siteden yola çıkmak gerekir. Örnekler için, http://ornek.org/ url'si ile çağrılan ve fiziksel olarak /home/deneme/public_html/ dizininde yer alan bir siteden yola çıkacağız.

Dağıtımın kök dizininde (/ecrire ile aynı seviyede) ortak kullanılan sitelerin dizinlerini içeren bir dizin oluşturmak gerekir (örneğin 'siteler').

- dizinin ortak kullanımı :
http://ornek.org/ilk_site/ ve http://ornek.org/ikinci_site/ adreslerinin her birinin bir spip sitesini çağırmaları isteniyorsa, /siteler dizininin altında şu alt-dizinlerin oluşturulması gerekir : /ilk_site ve /ikinci_site; sonra bunların içinde /config, /IMG, /tmp, /local dizinlerinin oluşturulması gerekir. Bu 4 dizin yazma izinli olacak biçimde erişilebilir olmalıdır. Devamında bu dizinlere /squelettes dizini de eklenecektir.

- alt-domaine ve domaine'in ortak kullanımı (bazı fikirler) :
http://deneme.ornek.org/, http://ornek.tld/ ve http://kullanici.ornek.com/ adreslerinden her birinin bir spip sitesi çağırması için /siteler dizininde /deneme, /ornek.tld ve /ornek.com/kullanici dizinlerinin oluşturulması gerekir.

Uyarı : Tüm bağlantılar kök dizini işaret etmelidir yani /home/deneme/public_html/. Bu, ya .htaccess dosyasının ya da ileride açıklayacağımız Apache hizmet birimi yapılandırmasının gerçekleştireceği bir görevdir.

Doğru düzenlenmiş yönlendirmeler !

SPIP'in bir sitenin ortak kullanıma açık olduğunu anlaması için (index.php tarafından çağrılan) spip.php skriptinin çalıştırılması gerekir. Bu skript /config/mes_options.php'ye eklenen bir kod sayesinde çağrılan URL'nin ortak kullanıma açık bir siteye karşı düşüp düşmediğine bakacaktır. Bunun için, http://ornek.org/ilk_site/ veya http://ornek.org/ikinci_site/ adresinin http://ornek.org/ adresine yönlendirilmesi ve index.php'yi çalıştırması gerekir...

Bu, .htaccess dosyasının görevidir (veya direkt olarak Apache hizmet biriminin yapılandırmasının)

htaccess.txt dosyasını dağıtımın kök dizinine kopyalamalı ve ismini .htaccess olarak değiştirmeli, sonra da şu değişiklikleri yapmalıdır :

URL'nin yeniden yazılmasına izin vermek için (normalde hiçbir şey değişmez) : RewriteEngine On

Eğer SPIP dağıtımı bir alt-dizindeyse rewritebase değiştirilmelidir. Burada, site kök dizinde, yani : RewriteBase /

Son olarak, kişisel ayarlarda, şu kod eklenmelidir ki /premier_site , /ikinci_site ve /üçüncü_site dizinleri dağıtımın kök dizininden işlenebilsin :

#Mutualisation
RewriteRule ^(ilk_site|ikinci_site|üçüncü_site)$ /$1/ [R,L]
RewriteRule ^(ilk_site|ikinci_site|üçüncü_site)/(.*) /$2 [QSA,L]

İlk rewriterule http://ornek.org/ilk_site adreslerini http://ornek.org/ilk_site/e yönlendirir. İkinci, /ilk_site/ 'nin ardındakileri kök dizine, örneğin: http://ornek.org/ilk_site/article112 http://ornek.org/article112 adresine yönlendirilir. (Bu arada, bu yönlendirme şeffaftır, url'nin ismi değişmez. daima http://ornek.org/ilk_site/article112'dir. Özellikle php'de ve php için !)

Peki ya SPIP bir alt-dizinde bulunuyorsa ?
Bu durumda, spip dosyaları /home/deneme/public_html/spip/ dizinindedir, SPIP http://ornek.org/spip/ tarafından çağrılır, ortak kullanıma açık siteler http://ornek.org/spip/ilk_site/ veya http://ornek.org/spip/ikinci_site/ tarafından çağrılır.

O zaman .htaccess dosyasına şunu koymak gerekir :

RewriteEngine On
RewriteBase /spip/

#Ortak kullanım (Mutualisation)
RewriteRule ^(ilk_site|ikinci_site|üçüncü_site)$ /spip/$1/ [R,L]
RewriteRule ^(ilk_site|ikinci_site|üçüncü_site)/(.*) /spip/$2 [QSA,L]

Peki ya tüm dizinleri ortak kullanılan siteler gibi yönlendirmek istersek ?

Yukarıda rewriterules yerine yerine ortak kullanıma açık sitedeki dizinin ismi ne olursa olsun işe yarayan bir jenerik kod kullanılabilir :

- kök dizinde

RewriteCond %{REQUEST_URI} !^/(config|squelettes-dist|ecrire|IMG|oo|plugins|siteler|squelettes|tmp|local)/(.*)
RewriteRule ^[^/]+/(.*) /$1 [QSA,L]

- veya bir /spip dizininde :

RewriteCond %{REQUEST_URI} !^/spip/(config|squelettes-dist|ecrire|IMG|oo|plugins|siteler|squelettes|tmp|local)/(.*)
RewriteRule ^[^/]+/(.*) /spip/$1 [QSA,L]

Domaine'ler ve alt-domaine'le için ?
Çok mutlu bir tesadüftür ki burada yapılacak hiçbir şey yok çünkü zaten SPIp dağıtımının kök dizinini işaret ediyorlar...

Mutualiser selon l'URL grâce à mes_options.php

İşin önemli kısmını halledecek olan kök dizindeki /config/mes_options.php dosyasıdır : bir URL'nin ortak kullanılıp kullanılmayacağını anlayıp SPIP'i buna göre başlatmak onun görevidir.

Dizinler ve domaine'ler arasında bir çok farklı durum olabilir. PHP skript'i çağıran URL'leri test etmek için 2 değişkenden yararlanabilir :

$_SERVER['REQUEST_URI']; // domaine isminin ardındaki her şeyi içerir : örneğin /ilk_site/article112 ...
$_SERVER['SERVER_NAME']; // domaine ve alt-domaine ismini içerir : örneğin kullanici.ornek.org

Ortak kullanıma açık dizinin ismini elde etmek için bakılacak değerlerş içeren bu 2 değişkendir.

Tüm dizinleri ortak kullanıma açacak basit bir yöntem aşağıdaki kodu kopyalamaktır :

if ( preg_match(',/([a-zA-Z0-9_-]+)/?,',$_SERVER['REQUEST_URI'],$r)) {

if (is_dir($e = _DIR_RACINE . 'siteler/' . $r[1]. '/')) {

$cookie_prefix = $table_prefix = $r[1];

define('_SPIP_PATH',
$e . ':' .
_DIR_RACINE .':' .
_DIR_RACINE .'squelettes-dist/:' .
_DIR_RACINE.'prive/:'.
_DIR_RESTREINT);

spip_initialisation(
($e . _NOM_PERMANENTS_INACCESSIBLES),
($e . _NOM_PERMANENTS_ACCESSIBLES),
($e . _NOM_TEMPORAIRES_INACCESSIBLES),
($e . _NOM_TEMPORAIRES_ACCESSIBLES)
);

$GLOBALS['dossier_squelettes'] = $e.'squelettes';

if (is_readable($f = $e._NOM_PERMANENTS_INACCESSIBLES._NOM_CONFIG.'.php')) include($f);
}
}
?>

preg_match satırı URL'nin ağaç yapısındaki dizin ismini alır, örneğin http://ornek.org/ilk_site/ 'deki 'ilk_site ... Sonra eğer /siteler/ilk_site/ mevcutsa skript ortak kullanımı dener.

Eğer SPIPbir /spip dizininin altındaysa ilk satırı şöyle değiştirmek gerekir : if (preg_match(',/spip/([a-zA-Z0-9_-]+)/?,', $_SERVER['REQUEST_URI'], $r)) {

SPIP'e kullanılan veritabanının ön-ekinin bildirilmesi gerekir : bunu da şu kod gerçekleştirir $cookie_prefix = $table_prefix = $r[1];
Bu satır, siteyi içeren dizinin ismini taşıyan ön-eklerle MySQL tablolarını oluşturur : örneğin spip_article yerine benim_sitem_article. Bu yöntem bize tek ve aynı veritabanı üzerinde bütün siteleri barındırma olanağı tanır. Varsayılan (spip) ön-ekini koruyabilirsiniz ama her site için ayrı veritabanları öngörmelisiniz.
Bunun için, şu kodu ekleyebilirsiniz :

$cookie_prefix = $r[1];
$table_prefix='spip';

spip_initialisation fonksiyonu, ortak kullanıma açılan sitenin çalışması için gerekli dizinlerin adresleri olan 4 parametreye gereksinim duyar.

$GLOBALS['dossier_squelettes'] = $e.'squelettes'; ortak kullanıma açılan sitenin iskelet dizinini tanımlar.

En sonunda da son satırlar şöyle bir dosyayı yükler : siteler/ilk_site/config/mes_options.php.

Bilgi :

SPIP çekirdeğinin config/mes_options.php dosyasında yapılan her değişiklik barındırılan tüm siteleri etkileyecektir.

Örneğin, bu dosyayı eklerseniz : $type_urls = 'propres' ;

Bu url tipindeki tüm siterleri etkiler... Ama her site bunu kendi dosyasında değiştirebilir /siteler/benim_sitem/config/mes_options.php.

Apache'ı domaine'ler ve alt-domaine'ler için yapılandırmak

Hizmet birimi tarafında, domaine'leri veya alt-domaine'leri ilgilendiren ortak kullanımın işletimi çok basittir ama bu sitelerin dikkate alınması için Apache hizmet biriminin yapılandırmasında bazı yönlendirmeler gerektirir.

İşte size 'ornek.tld' isimli ve alt-dizinler kullanan bir hizmet birimi için bir yapılandırma örneği (burada SPIP ortak kullanıma açıktır ve http://kullanici.ornek.org/spip/ tarafından çağrılır) .

SPIP çekirdeği '/home/deneme/public_html/spip/' dizinindedir.

O zaman şu iki dizin oluşturulmalıdır : /siteler/ornek.tld/ , /siteler/ornek.tld/kullanici/.

Yapılandırma dosyası /etc/apache2/sites_availables/default altında Apache 2/linux 'tadır. (siz sites_availables dizininde yeni bir dosya oluşturup onu etkinleştirebilirsiniz).

# SERVEUR exemple.tld
# SPIP par sous domaine...

ServerName exemple.tld
ServerAlias *.exemple.tld

# SPIP çekirdeğine yönlendirme
DocumentRoot "/home/deneme/public_html"

AllowOverride All
Order allow,deny
Allow from all


# Sadece http://kullanici.ornek.tld/spip/* adresi yönlendirilmelidir

# (kullanici.ornek.tld/spip/* -> /home/deneme/public_html/*)
RewriteCond %{SERVER_NAME} (www\.)?([^.]+)\.ornek\.net$
RewriteRule ^/spip/(.*) /home/deneme/public_html/spip/$1 [QSA,L]

# (kullanici.ornek.tld/* -> /home/deneme/public_html/siteler/ornek.tld/kullanici/*)
RewriteCond %{SERVER_NAME} (www\.)?([^.]+)\.ornek\.net$
RewriteRule (.*) /home/deneme/public_html/siteler/ornek.tld/%1/$1 [QSA,L]

/config/mes_options.php adresinde bu ortak kullanımları test etmek zorunludur :

# pour kullanici.ornek.tld/spip/ için
if ( preg_match(',(.*)\.exemple\.tld/spip/?,',$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'],$r)) {

if (is_dir($e = _DIR_RACINE . 'siteler/ornek.tld/' . $r[1]. '/')) {

$cookie_prefix = $table_prefix = $r[1];

define('_SPIP_PATH',
$e . ':' .
_DIR_RACINE .':' .
_DIR_RACINE .'squelettes-dist/:' .
_DIR_RACINE.'prive/:'.
_DIR_RESTREINT);

spip_initialisation(
($e . _NOM_PERMANENTS_INACCESSIBLES),
($e . _NOM_PERMANENTS_ACCESSIBLES),
($e . _NOM_TEMPORAIRES_INACCESSIBLES),
($e . _NOM_TEMPORAIRES_ACCESSIBLES)
);

$GLOBALS['dossier_squelettes'] = $e.'squelettes';

if (is_readable($f = $e._NOM_PERMANENTS_INACCESSIBLES._NOM_CONFIG.'.php')) include($f);
}
}
?>

Yedeklemeler ve geri yüklemeler üzerine notlar

Her site, kısıtlı bir yönetici için yedekleme dosyalarını /siteler/ilk_site/tmp/dump (veya /siteler/ilk_site/tmp/upload/login dizinine kopyalar). Geri yüklemeler de aynı dizin kullanılarak yapılır.

Dikkat:

Şu anda SPIP, /IMG dizini ile ilgili olarak, veritabanına tek başına sitelerde kullandığı IMG/* yerine ortak kullanıma açık siteler için siteler/ilk_site/IMG/* bilgisini kaydeder.

Geri yükleme ancak yedeklemeyi yapan siteden çağrıldığında çalışacaktır.

Yedeklemeyi başka bir yere geri yüklemek ancak dump.xml dosyasını düzenleyerek ve bu değerin geçtiği her yeri değiştirerek mümkündür (dir_img ve dir_logo deklarasyonları isitisnadır. ) :
- siteler/ilk_sitem/IMG/

  • (tek başına SPIP) ile : IMG/
  • veya (ortak kullanılan SPIP) : siteler/benim_yeni_sitem/IMG/

Tersine, ortak kullanılan bir dizinde tek başına bir SPIP yüklemek için tüm “IMG/” lerin “siteler/bemim_sitem/IMG/” olarak değiştirilmesi gerekir.

[1] Ortak kullanımı netleştirmek için yeni bir dizin dağıtım biçimi, login sorunlarının ve ayrık site isimlerinin ortak kullanılanlarla karışması gibi sorunların çözülmesi, ortak kullanılacak bir sitenin kurulum işleminin daha net olması

[2] Bilgi için : bu prosedürler Apache 2.0.55 ve PHP 5.1.2 ile Ubuntu Dapper Drake hizmet birimi ve PHP 5.1.6 ile Ubuntu Edgy Eft sistemlerinde test edilmiştir

]]> http://www.spip.net/tr_article4114.html Makale yazmak http://feedproxy.google.com/~r/Spip/~3/q7Y54f-bpbk/tr_article4120.html http://www.spip.net/tr_article4120.html 2009-05-27T18:33:08Z text/html tr mega İlk makaleleri yazmanın zamanıdır. Bu öğretici metinde sadece atılacak adımları değil aynı zamanda iskeletlerle çalışmayı da gösterecek. Önemli not Önceden SPIP iskeletleriyle uğraştıysanız en az bir makalenin yayınlanmış olması gerektiğini de bilirsiniz. Biz, grafik arayüzün oluşturulması esnasında mümkün olabilecek en fazla sayıda makale yazmanızı, çok sayıda bölüm oluşturmanızı ve hatta farklı uzunluklarda üst-başlığı veya alt-başlığı olan / olmayan, şapkası olan / olmayan makaleler yazmanızı öneririz. Bu makale sayısı (...) - <a href="http://www.spip.net/rubrique411.html" rel="directory">Eğitim: Döngü ve anahtar sözcüklerin ileri kullanımı</a>

İlk makaleleri yazmanın zamanıdır. Bu öğretici metinde sadece atılacak adımları değil aynı zamanda iskeletlerle çalışmayı da gösterecek.

Önemli not Önceden SPIP iskeletleriyle uğraştıysanız en az bir makalenin yayınlanmış olması gerektiğini de bilirsiniz. Biz, grafik arayüzün oluşturulması esnasında mümkün olabilecek en fazla sayıda makale yazmanızı, çok sayıda bölüm oluşturmanızı ve hatta farklı uzunluklarda üst-başlığı veya alt-başlığı olan / olmayan, şapkası olan / olmayan makaleler yazmanızı öneririz. Bu makale sayısı ne kadar fazla olursa daha da «esnek» bir arayüz oluşturabilirsiniz (yani olası bütün durumlara uyan). Tabii arayüz testleri için bu makaleler «uydurma metinler» olabilir (Web'den kesip koyalanan makaleler, yemek tarifleri vb.).

Oyun başına bir makale

Bir oyun içeren tüm makalelerin aynı bölümde toplanmasına karar verdik. Oyun üzerine ilk makaleyi yazmadan önce bu oyunun ismini taşıyan bir bölüm oluşturmalıyız (gelecek makaleler için tabii ki aynı bölüme konuşlanmalıyız).

Bölüm çok önemli bi rrol oynayacaktır : oyuna ismini veren bölüm olacaktır ve içerdiği tüm makalelere logo'yu sunan o olacaktır. Örneğin, «Resident Evil: Code Veronica» isimli bir bölüm oluşturacak ve bir logo atayacağız. Sonra, bu bölümde oyunun çözümünü içeren bir makale eklediğimizde bu makale oyunun ismini hatırlamak zorunda değildir (makale basitçe «Tam çözüm» ismini alacaktır) ve makaleye bir logo atamak zorunlu değildir.

Şu bölüme gidelim:
- Action/aventure | Survival horror

ve «Resident Evil: Code Veronica» isimli bir alt-bölüm oluşturalım.

Bu bölüm için bir «hızlı tanım» ekleyelim ve oyunun genel tanımını verelim.

Sonra bir ekran kopyası alarak bölümün logosunu oluşturalım.

Önemli not Bu bölüm logoları sitenin grafik arayüzünü elde etmek için çok sık kullanılacaktır. Biz, site. Nous vous conseillons donc de choisir arbitrairement (grafik gerekliliklere göre) tüm bu logolar için tek bir fomat seçmenizi öneririz. Bu, uyumlu bir arayüz oluşturulmasını sağlayacaktır. Örneğin tüm bölüm logolarının 120 x 160 piksel olmasını istiyoruz.

Şunu elde ederiz:

image 400 x 181

Oyunun tam bir testi !

Şimdi ilk bölüm oluşturulduğuna göre, bu oyunu içeren ilk makalemizi yazabiliriz.

Önemli not Bu sitedeki ilk olumsuzluğu vurgulayalım : bir oyunu içeren ilk makaleyi yazmadan önce s'astreindre à créer une rubrique (ve sitenin diğer katılımcılarına açıklamak) gerekir, Oysa normal davranış biçimi makaleyi direkt olarak «Survival horror» bölümünde yazmak ve başlık olarak (veya üst-başlık) olarak oyunun adını vermek olmalıydı. Bu, daha basit (tek bir makineyi işleten, sadece testler ve sonuçlar sunan) bir site için uygundur. Ama madem ki daha iddialı bir site için yola çıktık yapıda daha formal olmamız gerekir.

İlk anda, metin yaratmak ve resim eklemek yeterlidir.

Dikkat bu arada hemen belirlemek gereken 2 nokta var :
- oyunun ismi makalenin «kutucuklarında» belirtilmiş mi ? (başlıkta, üst-başlıkta, alt-başlıkta...)
- «hızlı tanım» zorunlu mu ?

Bu, daha sonra iskeletleri nasıl işleteceğimizi belirler. Rastgele biçimlerde seçim yapabilirsiniz ve daha sonra buna bağlı olarak iskeletlerinizi gerçekleştirin.

Bu eğitici belgede sunulacak örnekler için makalenin isminin oyunun ismini belirtmemesine karar verdik (ne başlıkta, ne üst veya alt-başlıklarda); bu isim sistemli bi rşekilde makaleyi içeren bölümden elde edilecektir. Ve iskeletlerimizde #DESCRIPTIF hızlı tanımını kullanacağız; yani bir tane hızlı tanım koymalıyız aksi halde hızlı tanıma atanan alan boş kalacaktır.

Son olarak, makalenin kendisine bir logo atamak zorunlu değil çünkü bölümünkini elde ederiz. Ama makaleye bir logo yerleştirmeye karar verilirse bölüm logoları için kabûl edilen formata uymanızı öneririz (çşjşs erırsrsrjeu 120 x 160 piksel).

Kabaca şunu verir :

image 140 x 300

- Makale başlığı oyunun ismi değil ama bir çengeldir "accroche" (Örneğin: «Le retour de Claire Redfield»);

- bir hızlı tanım var;

- sadece çevrim içi yayın tarihini kullanırız («ilk yayın tarihi» değil - zaten «İnce yapılandırma»'da bu olasılığı pasif hale getirdik); bu tarih yayın tarihine yani sitenin güncellenme tarihine karşı düşer (oyunların piyasaya ticarî çıkış tarihlerinin yönetimini daha sonra göreceğiz);

- yazarlarda, alışılmış yöntemle çalışırız : yazar sitede makaleyi yazan (testleri haberler...) ığeumobıewı. Burada bir «oyun yazarı» veya başka detay bilgiler vermeye çalışmayın.

Hangi makine(ler) için ? Hangi tip makale

Şimdi bu makalenin hangi makineleri ilgilendirdiği ve hangi tip bir makale olduğunu belirtmek kalır.

Bunun için, açılan menüler kullanacağız «Bir anahtar-sözcük ekleyiniz». İşte size pratik bir çözüm...

image 333 x 183

Pour ce jeu, nous considérerons que le test vaut aussi bien pour la version Dreamcast que pour la version Playstation 2. Si on considère que les deux versions sont suffisamment différentes, on peut tout aussi bien écrire un test différent pour chaque machine, il suffira alors de ne sélectionner qu'une seul machine par article.

Makale tipine gelince, bu bir test.

Elimizde ne var ? :

image 380 x 90

Bir makaleyi yayınlama biçiminin formalize edilmesi gerektiğini bir kez daha vurgulayalım. Her türlü yayından önce gerekli anahtarsözcüklerin varlığını kontrol etmek gerekir.

- Makinenin bildirilmesi gerçekten zorunlu değildir (makale yine de içindekiler bölümünde görülecektir); ama olmaması arayüzü bazı makalelerin makineleri belirtip bazılarının belirtmemesi yüzünden tutarsız kılacaktır ve makaleye «makineye göre» atıfta bulunulamayacaktır. Aynı makale için bir çok makine belirtilebilir.

- Makale tipi mutlaka olmalıdır. İleride bu tür makaleleri yoğun biçimde kullandığımızı göreceğiz. Unutulması durumunda, makale kamusal sitede görünmeyecektir. Bir makale için sadece tek bir tip belirtmek gerekir.

Bunu yaptıktan sonra bazıları çok makineli, farklı tiplerde ve farklı formatlarda başka makaleler oluşturun. Özellikle tam bir bölüm oluşturmaya çalışın (tüm makale tipleriyle) ve «Survival horror»'a yakın başlıkları zenginleştirin ki iskeletlerle ve site etkinliğini temsil edebilen başlıklarla çalışılabilsin. Yayın tarihlerini değiştirmeyi ve başlıkların ve makalelerin sıralanmasını test etmeyi unutmayın.

Bu durumda ideal olan sitede çok sayıda makale oluşturmak ve çok geniş bir yelpazeyi içeren yayın tarihleri kullanmaktır.

]]> http://www.spip.net/tr_article4120.html #AUTORISER http://feedproxy.google.com/~r/Spip/~3/F3XafcD6n7I/fr_article3896.html http://www.spip.net/fr_article3896.html 2009-05-25T20:24:59Z text/html fr cam.lafit, Fil calculee SPIP 2.0 #AUTORISER Cette balise a été introduite par SPIP 2.0. Cette balise permet, côté squelette, d'effectuer les mêmes contrôles que ceux qu'on peut réaliser en PHP avec la fonction autoriser() Elle renvoie un espace si l'autorisation est donnée, et une chaîne vide dans le cas contraire. On met autant d'arguments (et les mêmes) qu'on en mettrait dans la fonction autoriser(). Par exemple, pour savoir si le visiteur courant peut accéder aux statistiques de l'article : [(#AUTORISERvoirstats,article,#ID_ARTICLE) <a (...) - <a href="http://www.spip.net/rubrique543.html" rel="directory">balises</a> / <a href="http://www.spip.net/@calculee" rel="tag">calculee</a>, <a href="http://www.spip.net/@spip20" rel="tag">SPIP 2.0</a>, <a href="http://www.spip.net/@autoriser" rel="tag">#AUTORISER</a>

Cette balise a été introduite par SPIP 2.0. Cette balise permet, côté squelette, d'effectuer les mêmes contrôles que ceux qu'on peut réaliser en PHP avec la fonction autoriser()

Elle renvoie un espace si l'autorisation est donnée, et une chaîne vide dans le cas contraire. On met autant d'arguments (et les mêmes) qu'on en mettrait dans la fonction autoriser().

Par exemple, pour savoir si le visiteur courant peut accéder aux statistiques de l'article :

[(#AUTORISER{voirstats,article,#ID_ARTICLE})
voir les stats
]

Comme pour la fonction autoriser(), on peut passer un #ID_AUTEUR en argument pour demander si l'auteur en question est autorisé à .... .

Par exemple pour signaler d'une étoile les administrateurs et rédacteurs dans une liste d'auteurs :


#NOM [(#AUTORISER{ecrire,'','',#ID_AUTEUR}) *]

Un autre exemple, ci dessous, si le visiteur a des droits de modifications sur l'article, afficher un formulaire pour l'éditer, qui, une fois validé, retourne sur la page de l'article en question :

[(#AUTORISER{modifier, article,#ID_ARTICLE})
#FORMULAIRE_EDITER_ARTICLE{#ID_ARTICLE, #ID_RUBRIQUE, #URL_ARTICLE}
]

Rappel : les arguments de autoriser sont, dans l'ordre, (faire, quoi, id, qui, options).

Pour plus de détails nous vous invitons à consulter la documentation des fonctions de inc/autoriser.php.

]]> http://www.spip.net/fr_article3896.html SPIP'te veritabanları http://feedproxy.google.com/~r/Spip/~3/ZIPd-edWtak/tr_article4106.html http://www.spip.net/tr_article4106.html 2009-05-25T16:51:28Z text/html tr mega <p>SPIP'in veritabanlarıyla yapabildiği herşey</p> - <a href="http://www.spip.net/rubrique588.html" rel="directory">Veritabanları</a>

SPIP MIME formatında (HTML, RSS, ICS ...) veritabanı ekstreleriyle sayfa düzeni yapabilen bir gereç olarak görülebilir. SPIP 2.0'ın yeniliklerinden biri, birbirlerinden farklı hizmet birimlerinde yer alan farklı birçok SQL veritabanından gelen bilgileri tek sayfada toplayabilmesidir. SPIP hiç programlama gerektirmeden farklı bağlantıları işletebilir ve farklı tablo tanımlamalarını yapabilir. Bu makale yeni sürümün sunduğu bu özelliklerin kullanımını anlatmaktadır.

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:

_INSTALL_SERVER_DB SQL hizmet biriminin tipi (Mysql veya PG; büyük / küçük harfe duyarsız)
_INSTALL_HOST_DB SQL hizmet biriminin internet ismi (örneğin: localhost)
_INSTALL_USER_DB SQL hizmet biriminin kullanıcı ismi
_INSTALL_PASS_DB SQL hizmet biriminin kullanıcı şifresi

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 :

_INSTALL_NAME_DB veritabanının ismi

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:

global değişken $table_prefix
sabit _INSTALL_TABLE_PREFIX

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

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

#TOTAL_BOUCLE

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:

#NOM

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, (veya connect=B.) içeren bir URL ile ) 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 Kişiselleştirilmiş URL'ler kullanmak) 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. Entegre XML onaylayıcı 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);
}
)

Tarihçe. SPIP ilk sürümlerinde sadece bir veritabanının bazı alanlarına erişim izni veriyordu, Sadece tek bir veritabanında bir tablonun önüne ekler getirerek her bir veritabanını simüle ediyordu.

SPIP 1.8, 1.8.1 ve yeni iskelet derleyici HTTP hizmet birimiyle her veritabanının her alanına erişime iznin yolunu açtılar. Ama bu seçenek standart dosyaları taklit ederek PHP dosyalar yazmayı gerektiriyordu. Ayrıca SPIP hizmet birimi tipleri ve veritabanları arasındaki incelikleri fark edemiyordu: aynı hizmet biriminin veritabanlarını adreslemek için bu dosyaları kopyalamak gerekiyordu. Bu çok yetersiz yapı, birçok eklentinin kullanmış olmasına rağmen bu fonksiyonların niçin hiç belgelenmediğini de açıklıyor.

]]> http://www.spip.net/tr_article4106.html {titre_mot}, {type_mot} http://feedproxy.google.com/~r/Spip/~3/IpPkzBmDwSk/tr_article4113.html http://www.spip.net/tr_article4113.html 2009-05-20T22:33:46Z text/html tr mega titre_mot=xxxx veya type_mot=yyyy (SPIP 1.3'ten itibaren) sırasıyla anahtar-sözcüğe bağlı ismi «xxxx» olan veya «yyyy» anahtar-sözcük grubuna bağlı makaleleri seçer. Eğer bir çok kriter verilirse titre_mot=xxxx (veya bir çok type_mot=yyyy verilirse) bu sözcüklerin hepsini birden içerenler seçilecektir (Yeni özellik SPIP 1.9). - <a href="http://www.spip.net/rubrique583.html" rel="directory">Kriterler</a>

- {titre_mot=xxxx} veya {type_mot=yyyy} (SPIP 1.3'ten itibaren) sırasıyla anahtar-sözcüğe bağlı ismi «xxxx» olan veya «yyyy» anahtar-sözcük grubuna bağlı makaleleri seçer. Eğer bir çok kriter verilirse {titre_mot=xxxx} (veya bir çok {type_mot=yyyy} verilirse) bu sözcüklerin hepsini birden içerenler seçilecektir (Yeni özellik SPIP 1.9).

]]> http://www.spip.net/tr_article4113.html adult