nyroBlog
Bannière NyroBlog, par Côme Nicolas
Image par Côme Nicolas - ?

Tag : Serveur


Base de données : MySQL (Serveur Web sur Debian Squeeze)

Cette partie n'a pas évolué depuis Lenny. C'est exactement la même procédure.

On installe le serveur :

aptitude install mysql-server

Durant l'installation, il vous sera demandé le mot de passe de l'utilisateur MySQL root.

MySQL vient avec une commande sympathique qui permet de sécurisé le serveur :

mysql_secure_installation
# Current password : VOTRE_MOT_PASSE
# set new password : N
# remove anonymous Users : Y
# Disallow root login remotley : Y
# remove test database and access to it : Y
# reload privileges table now : Y

Si vous utilisez InnoDB comme moteur de stockage de vos tables, l'ensemble des données de chaque table est stockée dans un seul et même fichier pour toutes les tables InnoDB de toutes les bases de données. Cela peut vous embetter, et dans certains cas, causer des lenteurs du serveur. Il est possible de paramétrer MySQL pour créer un fichier de stockage par table. Nous allons aussi optimiser un chouilla la taille des caches. Pour ce faire, on édite le fichier /etc/mysql/my.cnf pour y ajouter dans la section [mysqld] :

innodb_file_per_table=1
innodb_buffer_pool_size=64M
tmp_table_size=32M
table_cache=128


On déplace les fichiers de la base de données dans /home/var en prenant soin d'arrêter le serveur avant : 

/etc/init.d/mysql stop
mv /var/lib/mysql /home/var/
ln -s /home/var/mysql/ /var/lib/mysql
chown mysql:mysql /home/var/mysql
/etc/init.d/mysql start

 

Nous voilà prêt pour installer le serveur DNS.

 

Retour au sommaire du tutorial complet.

Serveur Web : Nginx et PHP (Serveur Web sur Debian Squeeze)

Avant de commencer l'instalaltion de Nginx et PHP, quelques petits éléments.

J'ai décidé d'utiliser Nginx plutôt qu'Apache car il est beaucoup plus rapide et supporte des montées en charge beaucoup plus importantes qu'Apache.

Pour utiliser PHP avec Apache, il suffisait d'installer un module apache et tout fonctionnait directement. Avec Nginx, nous sommes obligés d'utiliser FastCGI Process Manager qui est plus ou moins un démon PHP qui va tourner sur le serveur et répondre à Nginx lorsqu'il le demandera. Plus de détails dans les configurations.

 

Pour installer PHP et pas mal d'extenstions à PHP (vous pouvez en supprimer si vous le souhaitez), une seule ligne de commande :

aptitude install nginx-extras php5-cgi php5-fpm php5 php5-mysql php5-dev php-pear php5-cli php5-gd php5-mcrypt php5-imap php5-curl php5-apc php5-fpm

php5-cli : Utilisation de php en ligne de commande (utile pour les tâche CRON)

php5-gd : Manipulation d'images en PHP

php5-imap : Connexion en Imap à un serveur de web en PHP

php5-curl : Utilisation de CURL en PHP (utile pour beaucoup d'API)

php5-apc : Mise en cache de l'OP code de PHP poru accélérer son fonctionnement (utilsiation totalement transparente)

php5-fpm : Pour obtenir le script init.d qui permettra de gérer php-fpm. Le démon est maintenant inclus directement dans PHP.

 

Lorsque tout est installé, commencons par configurer Nginx. Dans le fichier /etc/nginx/nginx.conf, dans la zone events :

worker_connections 1024;
multi_accept on;
use epoll;

Détails sur la configuration.

Puis dans la zone http :

tcp_nopush off;
server_tokens off;
client_max_body_size 30M;
client_body_buffer_size 128k;
expires 31d;

index index.php index.htm index.html;

Détails sur la confgiration.

Puis nous allons éditer les paramètres par défaut utiliser lors du passage au PHP-FPM. Dans le fichier /etc/nginx/fastcgi_params, ajoutez :

fastcgi_index index.php;
fastcgi_split_path_info ˆ((?U).+\.php)(/?.+)$;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param PATH_TRANSLATED $document_root$fastcgi_path_info;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_pass unix:/var/run/php5-fpm.sock;

La dernière ligne indique le chemin du socket par lequel on va passer, que nous allons configurer un peu plus loin.

Editons le site par défaut /etc/nginx/sites-available/default de nginx pour y ajouter quelques éléments :

listen 80; ## listen for ipv4; this line is default and implied
listen [::]:80 default ipv6only=on; ## listen for ipv6

#comment index line

server_name localhost ks389877.kimsufi.com;
location = /nginx_status {
expires off;
stub_status on;
access_log off;
error_log off;
allow 176.31.102.83;
allow 127.0.0.1;
deny all;
}
location = /php_status {
expires off;
include fastcgi_params;
access_log off;
error_log off;
allow 127.0.0.1;
deny all;
}
location = /apc_info.php {
expires off;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME /home/var/www/apc_info.php;
access_log off;
error_log off;
allow 127.0.0.1;
deny all;
}

location ~ \.php$ {
expires off;
include fastcgi_params;
}

les loctions nginx_status, php_status et apc_info.php seront utilisé plus tard pour le monitoring du serveur.

Pour la dernière section, on active le PHP. Ce ne sera pas plus compliqué que ça pour activer le PHP pour un autre site.

Enfin, pour être sûr que le site par défaut soit bien chargé en premier, exécutez :

rm /etc/nginx/sites-enabled/default
ln -s /etc/nginx/sites-available/default /etc/nginx/sites-enabled/000-default

 

Voilà pour ce qui est du Nginx. Passons maintenant à la configuration du PHP.

D'abord la configuration de base du FPM pour autoriser l'envoi de fichier jusqu'à 15 Mégas dans le fichier /etc/php5/fpm/php.ini :

post_max_size = 30M
upload_max_filesize = 15M

Puis configurons le FPM pour correspondre un peu plus à nos attentes dans le fichier /etc/php5/fpm/pool.d/www.conf :

listen = /var/run/php5-fpm.sock
pm.max_children = 50
pm.start_servers = 10
pm.min_spare_servers = 5
pm.max_spare_servers = 10
pm.status_path = /php_status

La dernière ligne permet de répondre à la configuration que nous avons faites dans Nginx pour connaître le nombre de process du PHP-Fpm par exemple.

Puis, nous avons installé un accélérateur de code PHP. La configuration par défaut n'est pas très satisfaisante et arrive très vite a des limitations. Modifié le fichier /etc/php5/fpm/conf.d/apc.ini pour y mettre :

[apc]
apc.shm_size=256M
; workaround for CLI
apc.enable_cli=1
; Symfony make lot of path lookups, try to optimize
apc.include_once_override=0
apc.canonicalize=1

Tous les détails de cette configuration.

Dans Squeeze, PHP est installé directement avec suhosin. Cette une extension qui rajoute une couche de sécuirté dans pas mal d'éléments du PHP. Pour ma part, je n'avais pas vraiment envie de corriger tous les sites installé sur ce serveur. J'ai donc modifié la configuration de suhosin pour loggé ses erreurs (afin de les comprendre et les corriger), mais aussi d'augmenter les limites qu'il met en place et de supprimer quelques sécurités. Dans le fichier /etc/php5/conf.d/suhosin.ini :

[suhosin]
suhosin.log.syslog.facility = LOG_LOCAL2

suhosin.executor.include.whitelist="phar"

suhosin.memory_limit = 4G

suhosin.post.max_value_length = 1280000
suhosin.request.max_value_length = 1280000

suhosin.session.encrypt = Off
suhosin.cookie.encrypt = Off

Tous les détails de cette configuration.

la première ligne de cette configuration utilise rsyslog, avec le numéro 2. Il faut donc créer le configuration correspondante dans le fichier /etc/rsyslog.d/php-suhosin.conf :

local2.*  /home/var/log/php-suhosin.log

Et comme on ne veut pas gardé ad vitam eternam ces logs, on ajoute dans le fichier /etc/logrotate.d/rsyslog juste en dessous de /var/log/messages :

/var/log/php-suhosin.log

 

Pour finir, on déplace le dossier www dans notre /home/var, on redémarre les démons dont la configuration a été modifié et notre serveur web est prêt !

mkdir /home/var/www/
ln -s /home/var/www/ /var/www
/etc/init.d/rsyslog restart
/etc/init.d/php5-fpm restart
/etc/init.d/nginx force-reload

 

La suite : Base de données MySQL.

Retour au sommaire du tutorial complet.

Préparation et accès SFTP (Serveur Web sur Debian Squeeze)

La première étape lors de la réception d'un serveur dédié et de bien préparer le terrain pour configurer l'espace de travail dont nous avons besoin.

Pour l'édition de fichiers, j'utilise vi. Il existe une variante un peu plus ergonimique et avec plus d'options, nommé vim.

Je commence par l'installer :

aptitude install vim vim-common

Puis j'éditer la configuration de base pour y ajouter la colorisation syntaxique et l'affichage du nombre de ligne.

En modifiant le fichier /etc/vim/vimrc :

syntax on # décommenter
set number # ajouter la ligne

Puis, on va aussi ajouter la colorisation lorsqu'on parcours les dossiers et fichier, c'est toujours plus agréable. On va aussi ajouter un alias sur la ligne de commande vi pour utiliser vim.

Editer le fichier /root/.bashrc pour décommenter les lignes suivantes et ajouter la dernière :

export LS_OPTIONS='--color=auto'
eval "`dircolors`"
alias ls='ls $LS_OPTIONS'
alias ll='ls $LS_OPTIONS -l'
alias l='ls $LS_OPTIONS -lA'
alias vi='vim'

 

Lorsque vous vous connectez la première fois sur votre serveur, ce sera sûrement en root. Les administrateurs n'apprécient pas vraiment ça. Personnelement, je préfère garder mon accès root pour plus de liberté. Plutôt que de devoir utiliser sudo à tour de bras, je préfère créer un alias de l'utilisateur root, et n'autoriser que cet utilisateur à se connecter en SSH.

Editer le fichier /etc/passwd pour y ajouter la ligne :

toto::0:0:root:/root:/bin/bash

Puis exécuter les commandes :

passwd toto
shadowconfig on

La première vous demandera le mot de passe pour toto. La seconde améliore la sécurité des mots de passe sur votre serveur.

 

Puis, Nous allons autoriser uniquement cet utiliser à se connecter en SSH. Les autres utilisateurs appartenant au groupe www-data vont être forcé d'utiliser le sous-système SFTP.

Editer le fichier /etc/ssh/sshd_config pour y ajouter à la fin :

DenyUsers root
Match group www-data
ChrootDirectory %h
AllowTcpForwarding no
X11Forwarding no
ForceCommand internal-sftp

Chaque utilisateur du groupe www-data qui se connectera en SSH sera forcé d'utiliser le SFTP, et sera en plus Chrooté dans son répertoire personnel.

On redémarre le serveur SSH et nous voilà déjà avec un serveur SFTP opérationnel :

/etc/init.d/ssh force-reload

Si vous êtes sûr que tout fonctionne bien, vous pouvez vous déconnecter et vosu reconnecter avec toto.

 

La seconde partie importante de la prépaparation du serveur Debian consiste à mettre à jour les sources de fichiers APT.

Pour ce faire, il faut éditer le fichier /etc/apt/sources.list pour autoriser les sources contrib et non-free, y ajouter les backports. Nous y ajoutons aussi dotdeb qui permettra d'obtenir les dernières versions de PHP par exemple. Le fichier sources.list devrait donc ressembler à cela :

deb http://mirror.ovh.net/debian/ squeeze main contrib non-free
deb-src http://mirror.ovh.net/debian/ squeeze main contrib non-free

deb http://security.debian.org/ squeeze/updates main contrib non-free
deb-src http://security.debian.org/ squeeze/updates main contrib non-free

deb http://backports.debian.org/debian-backports squeeze-backports main contrib non-free
deb-src http://backports.debian.org/debian-backports squeeze-backports main contrib non-free

deb http://packages.dotdeb.org stable all
deb-src http://packages.dotdeb.org stable all

Pour terminer l'installation des sources dotdeb, il faut exécuter :

wget http://www.dotdeb.org/dotdeb.gpg
cat dotdeb.gpg | apt-key add -
rm dotdeb.gpg

Nous voilà prêt pour notre première mise à jour du serveur. vous en aurez peut-être déjà !

aptitude update
aptitude full-upgrade

 

Sur le serveur dédié OVH que j'ai acheté, le / du serveur ne dispose que de 10G, alors que le /home a quant à lui 1.8T ! Plutôt que de stocker les logs sur le / et de craindre d'atteindre un jour cet hypotétique 10G de logs, je préfère les stockés dans /home/var/log. Réalisé simplement grâhce à un lien symbolique :

mkdir /home/var
mv /var/log /home/var
ln -s /home/var/log/ /var/log

 

Enfin, pour être compatible IPv6, il faut d'abord récupérer l'adresse IPv6 de votre serveur. Chez OVH, vous le trouverez dans le manager, sur le récapitualitf de votre dédié. Il s'agira sûrement d'une plage d'adresse IP, se terminant par exemple par /64. Nous allons pour noter serveur n'utiliser qu'une seule adresse IPv6. L'adresse IPv6 indiqué par OVH est 2001:41d0:8:1753::/64. J'ai décidé d'utilsier comme adresse IPv6 2001:41d0:8:1753::1. Pour que le serveur comprenne qu'il possède cette IP, il faut ajouter dans le fichier /etc/network/interfaces :

iface eth0 inet6 static
address 2001:41d0:8:1753::1
netmask 64

Puis redémarrer le service correspondant :

/etc/init.d/networking restart

 

Voilà, votre serveur est prêt pour la suite, le serveur Web.

 

Retour au sommaire du tutorial complet.

Serveur Web sur Debian Squeeze : Tutorial complet

Il y a maintenant 3 ans, j'avais mis en ligne un tutorial complet pour installer un serveur Web Debian avec la version Lenny. Comme le support officiel de cette version s'est arrêté le 6 Février 2012, il est temps de mettre à jour vos serveurs.

De plus, le serveur sera totalement compatible IPv6.

Donc je vais reprendre le tutorial complet de la version Lenny, avec quelques changements, dont les principaux sont :

  • Plus de serveur FTP. A la place, nous utiliserons SFTP uniquement qui est beaucoup plus écurisé et ne nécessite pas de logiciels supplémentaires.
  • A la place du très gourmand Apache, Nginx sera utilisé : beaucoup moins gourmand en mémoire vive, Nginx gagne des parts de marché très rapidement.

Comme pour la première version de ce tutorialn, les prérequis sont :

  • Connaissance de base de Debian/Linux : gestion des droits, aptitude, démons, etc...
  • Edition de fichiers avec vi (ou autre éditeur de votre choix)
  • Connaîre SSH, comment se connecter à un serveur distant (via PuTTY par exemple)

Voici donc le sommaire de ce tutorial :

Je tenterai d'expliquerua au mieux l'ensemble des configurations utilisées. Si vous avez des questions, vous pourrez évidemment poser des questions dans les commentaires.

Ce tutorial n'est en rien un gage de sécurité et je ne pourrai être tenu pour responsable pour un manquement quelconque.

Vous êtes prêt ? Passons à la première étape.

nyroFwk, Framework PHP - Présentation

Ceci est un brouillon d'introducion à la documentation de nyroFwk. Toutes remarques, suggestions ou questions pour l'améliorer est la bienvenue !

Vendredi dernier, j'ai mis en ligne l'API et le svn (user : anon / passe : anon) de nyroFwk.

Bon c'est très bien tout ça, mais qu'est-ce que c'est ?

Pour commencer, petit extrai de wikipedia : Un framework est un kit de composants logiciels structurels, qui définissent les fondations ainsi que les grandes lignes de l'organisation de tout ou partie d'un logiciel.

Oui, mais des frameworks PHP, il en existe des tas, non ?
Oui, on peut signaler symfony, Zend Framework et CakePHP ici. J'ai testé ces 3 là plus ou moins fortement. Chacun a ses avantages et ses inconvénients. Mais aucun ne répondait exactement à mes besoins et habitudes de développements. Alors quand quelque chose ne me convient pas, moi, je le refais, tout simplement (comme nyroModal par exemple)

Alors qu'est-ce que je n'aime pas ou j'aime dans ces frameworks ?
  • CakePHP : la gestion des bases de données et des objets associés. A l'époque où j'avais testé, on était obligé de modifier les objets lorsqu'on avait des relations entre différents objets. Et puis je n'ai jamais réussi a vraiment faire quelque chose de bien avec. Pas forcément réellement tout testé non plus, je dois bien l'avouer. Là où CakePHP marque des points, c'est dans la génération automatique de l'administration et toutes les fonctionnalités ajax super simple à implémenter.
  • Zend Framework : Je ne l'ai jamais concrètement utilisé car il me paraissait trop énorme. Ce framework a absolument tout ce dont on peut rêver. L'organisation des fichiers, de la documentation et de tout ce qui va autour de ce framework est géniale.
  • Symfony : c'est celui que j'ai le plus utilisé (et que j'utilsie encore). J'aime bien la génération automatique des objets de base de données, même si je trouve cela dommage de devoir regénérer ça à chaque modification de la base de donnée. J'aime pas le grand nombre de fichiers de configuration et encore moins tous les différents formats possibles. Pourquoi s'embetter et donc ralentire le processus avec des fichiers YAML alors qu'un simple tableau PHP fait très bien l'affaire ? La barre de débuggage peut être très utile. La séparation des classes de chaque controller pose problèmes ; dans certains cas, on est obligé de réécrire le code...
Et puis il y a plein d'autres choses qui ne sont pas dans ces frameworks, comme :
  • Gestion simple de formulaire permettant d'ajouter des champs, de vérifier s'il est valide, de le remplir, de récupérer les valeurs, etc...
  • Intégration des règles d'opitimisations de yahoo developper simplement et de base
  • Gestion des images souples, rapide et efficace
  • Intégration d'un éditeur WYSIWYG simple
  • Gestion des fichiers envoyés par les utilsiateurs sécurisée (ie : possibilité de restreindre l'affichage de ces fichiers qu'aux utilsiateurs connectés)
  • Tout est objet
Vous l'aurez compris, ces éléments sont intégrés de base dans nyroFwk.

Dans mon framework, chaque objet a sa propre configuration, qui hérite de toutes la configuration de ses parents. Chaque configuration est définie de base par le framework mais est modifiable pour chaque site très simplement. Suivant les besoins, on peut aussi modifier la configuration de chaque classe suivant le controller (front ou admin). Prenons un exemple, plus parlant. La classe response_http_html gère tout ce qui sera envoyé au navigateur lorsque la page demandée est en HTML. Elle hérite de la classe reponse_http, qui elle hérite de la classe reponse_abstract qui hérite de object. La définition de cette classe est dans le fichier nyro/response/http/html.class.php. Sa configuration est dans le fichier nyro/response/http/html.cfg.php est conteint (extrait) :
$cfg = array(
    'meta'=>array(
        'robots'=>'index, follow',
        'description'=>'nyro project',
        'keywords'=>'nyro, project',
        'language'=>request::get('lang'),
    ),
);
On définit donc les balises meta par défaut de toutes les réponses HTML. A noter que la langue ici est dynamique sera en rapport avec la langue demandée par l'utilisateur (explications plus tard).

Cette configuration est là pour définir des éléments par défaut, mais doit bien évidemment être modifié pour chaque site. Pour ce faire, chaque site aura un dossier personnel dans lequel il doit définir ses classes propres aux sites, mais aussi toutes ces configurations. Ce dossier se nomme par défaut my dans nyroFwk et est placé juste à côté du dossier nyro.

Dans ce dossier propre à chaque site, on peut aussi redéfinir chaque classe de nyroFwk. En effet, à la demande de chaque classe, le framework va vérifier si le fichier correspondant à la classe existe dans le dossier my au bon endroit. Sinon, il cherchera dans le dossier de base du framework. Un mécanisme similaire est utilisé pour les configurations. Au lieu de remplacer la configuration, on va fusionner les configurations successives de la classe, en gardant bien sûr le plus spécifique. Par exemple, pour nyrodev.com, le fichier my/response/http/html.cfg.php ressemble à (extrait) :
$cfg = array(
    'meta'=>array(
        'title'=>'nyroDev, Analyste Développeur Web (PHP, jQuery)',
        'description'=>'Cédric Nirousset, nyroDev : Conception, Analyse et Développement de sites web (PHP, jQuery).',
    ),
);
Je redéfinis les balises meta title et description pour mon site public.

Les configurations sont un point très important pour nyroFwk. C'est pourquoi il est possible de définir encore plus finement ces configurations. Tout d'abord, on peut spécifier le controller de la configuration si on veut être plus précis. Pour mon site, l'administration porte le nom de controller 'admin' et le site public 'front' (par défaut dans nyroFwk). Pour l'administration, on n'a pas besoin des meta description par exemple. C'est la raison pour laquelle le fichier de configuration du site public ne se nomme pas comme je l'ai indiqué plus haut, mais en réalité my/response/http/html.front.cfg.php. Vous avez remarquer le front en plus qui indique que l'on veut l'affciher que pour le site public. Juste à côté, le fichier my/response/http/html.admin.cfg.php existe pour définir les éléments pour l'administration.

Avec ce système, on a déjà quelque chose de tout à fait souple. Mais ce n'est pas fini ! nyroFwk gère les sites multilangues de base. Son fonctionnement est :
  • On définit une langue par défaut
  • On définit les langues disponibles
  • Si l'URL demandé est du type : monsite.com/LANG/maPage avec LANG une langue définit, alors on passe dans la langue demandée.
Bien, et alors, le rapport avec les fichiers de configuration ? Simple, en plus de la spécification par rapport au controller, les fichiers de configuration permettent aussi de spécifier une configuration spécifique pour la langue demandée. Exemple pour mon site qui est aussi disponible en anglais, le fichier my/response/http/html.front.en.cfg.php contient :
$cfg = array(
    'meta'=>array(
        'title'=>'nyroDev, Analyst Developper Web (english) (PHP, jQuery)',
        'description'=>'Cédric Nirousset, nyroDev: Conception, Analysis and Development of websites (PHP, jQuery).',
    ),
);
Ce mécanisme est utilisé à plusieurs endroits dans nyroFwk pour définir des messages à l'utilisateurs. Et comme vous l'avez remarques, ces fichiers sont de vrais fichier PHP. Donc rien ne vous empêchera, quand vous serez plus à l'aise avec le framework, d'utiliser des classes avec des fonctions statiques pour faire d'autres choses comme par exemple utiliser la base de donnée pour modifier ces éléments...

Et n'oubliez pas : les configurations sont successives et n'écrasent pas les autres configurations, aussi bien des classes parentes, mais aussi des configurations du controller et de langue. Ainsi, pour la classe response_http_html, la configuration est le résultat de la fusion des configurations (le plus bas étant le plus prédominant) :
  1. nyro/object.cfg.php
  2. nyro/object.fr.cfg.php
  3. nyro/object.front.cfg.php
  4. nyro/object.front.fr.cfg.php
  5. my/object.cfg.php
  6. my/object.fr.cfg.php
  7. my/object.front.cfg.php
  8. my/object.front.fr.cfg.php
  9. nyro/response_abstract.cfg.php
  10. nyro/response_abstract.fr.cfg.php
  11. nyro/response_abstract.front.cfg.php
  12. nyro/response_abstract.front.fr.cfg.php
  13. my/response_abstract.cfg.php
  14. my/response_abstract.fr.cfg.php
  15. my/response_abstract.front.cfg.php
  16. my/response_abstract.front.fr.cfg.php
  17. nyro/response_http.cfg.php
  18. nyro/response_http.fr.cfg.php
  19. nyro/response_http.front.cfg.php
  20. nyro/response_http.front.fr.cfg.php
  21. my/response_http.cfg.php
  22. my/response_http.fr.cfg.php
  23. my/response_http.front.cfg.php
  24. my/response_http.front.fr.cfg.php
  25. nyro/response_http_html.cfg.php
  26. nyro/response_http_html.fr.cfg.php
  27. nyro/response_http_html.front.cfg.php
  28. nyro/response_http_html.front.fr.cfg.php
  29. my/response_http_html.cfg.php
  30. my/response_http_html.fr.cfg.php
  31. my/response_http_html.front.cfg.php
  32. my/response_http_html.front.fr.cfg.php
Bien sûr, ces fichiers ne sont utilisés que s'ils existent ! Et ceci avec n'importe quelle classe du framework.

Mais je dois créer un fichier pour chaque classe qui en a besoin ? Au début, c'était le cas oui. Mais je me suis aperçu que cela pouvoit devenir très vite long et fastidieux. Ce mécanisme existe toujours et est toujours utilisé car dans certains cas indispensable, mais il existe un autre moyen. En effet, la configuration de la classe nyro permet de modifier la configuration de n'importe quelle classe dans un seul et même fichier de configuration. Par exemple, on aurait pu définir les éléments montrés précédemment dans le fichier my/nyro.front.cfg.php de cette façon :
$cfg = array(
    'response_http_html'=>array(
        'meta'=>array(
            'title'=>'nyroDev, Analyst Developper Web (english) (PHP, jQuery)',
            'description'=>'Cédric Nirousset, nyroDev: Conception, Analysis and Development of websites (PHP, jQuery).',

        ),
    ),
'une_autre_classe'=>array(
'uneAutreConfig'=>'yeah'
),
);
Cette configuration est utilisé en dernier lieu pour créer la configuration de chaque classe.

Vous avez d'ailleurs remarqué la classe object ? Toutes les classes instanciables héritent de cette classe, ce qui permet une gestion centralisée et uniforme des configurations et de la création des objets.

Bon, voilà déjà pour la configuration.

Pour revenir sur les fonctionnalités du framework, voici une liste (sans doute non exhaustive) de ce que gère pour l'instant nyroFwk :
  • Programmation orientée objet
  • Configuration avancée et très souple des classes
  • Gestion des sites multilingues
  • Gestion des bases de données multilingues avec récupération automatique des données propre à la langue
  • Configuration de base de donénes multiples
  • Gestion des utilsiateurs et de leur connexion, vérifications des accès, etc...
  • Gestion des formulaires avancées et souples : validation, affichage, etc...
  • Manipulation des images simplement, avec souplesse et efficacement
  • Création de formulaires directement depuis la structure de la base de données (gestion des données liées et en relation)
  • Création de l'administration automatique
  • Minimisation en un seul fichier compressé des fichiers JavaScript et CSS nécessaire à la page
  • Application d'un maximum de règle d'optimisations données par Yahoo
  • Barre de débogage
  • Editeur WYSIWYG (tinyMce) très simplement intégrable
  • jQuery et jQuery UI intégré
  • Ajax ready : différents templates s'il s'agit d'une requêtes ajax
  • Extensibilité simple et accrue : tout peut être redéfini
  • etc...
Fiou, ça n'a pas été une mince affaire de rédiger tout ça... J'espère que ça vous donne déjà une meilleure idée de ce qu'est nyroFwk et que vous aurez envie d'en savoir plus...