Thibaut LE LEVIER

Loader PHP: chargez vos class automatiquement

oct 18 2009

Si par erreur (ou justement pas) vous vous mettez un jour à coder proprement en PHP, vous vous rendrez vite compte qu’avoir ces petites classes toute faite pour interroger une base de donnée ou parcer un fichier XML peut s’avérer très pratique. Une fois ces classes écrites une bonne fois pour toute, avec la gestion d’erreur qui va bien et tout et tout, il ne reste plus qu’a copier/coller celle dont on a besoin dans un dossier « Class » du projet en cours et on les appellera au besoin sur les pages concernées.

Mais voilà, trêve de plaisanteries, trois tonnes d’include en haut d’un fichier PHP ça va vite devenir très cochon et pas franchement lisible.

Nous allons voir ici comment utiliser la fonction __autoload() de PHP pour inclure automatiquement les fichiers contenant les classes que nous allons appeler.

Commençons par organiser un peux notre projet.

Créez un dossier à la racine du site qui va contenir toute les librairies de notre projet et créez dans celui ci un dossier « class » qui lui contiendra les classes de notre application.

Créez maintenant un fichier nommé « Loader.php » à la racine du dossier « library » dans lequel nous allons placer le code suivant:

<?php

function __autoload($class_name) {

require_once ‘library/class/’ . $class_name . ‘.php’;

}

?>

On peut maintenant appeler ce fichier dans notre script d’origine, par exemple ici notre index.php

<?php

require_once(‘library/Loader.php’);

Ainsi une instanciassions de classe du type:

$sql_access = new db_access();

va automatiquement inclure le fichier « library/class/db_access.php » contenant la classe « db_access » et nous nous retrouvons directement avec une organisation du projet sous cette forme:

Bienvenu dans le monde des projets bien organisés!

4 responses so far

If there’s something strange in your neighborhood

oct 15 2009

Who you gonna call?
Ghostbusters

No responses yet

WordPress et PHP 5.3

oct 04 2009

Après plusieurs tentatives d’installation (ou de migration) de WordPress sous un serveur PHP 5.3, je viens enfin de trouver la solution à ce qui semble être une incompatibilité due à une configuration non explicite de php.

L’erreur est simple, vous affichez votre site/blog sous wordpress et celui ci vous hurle dessus que les fonction strtotime() et date() ne peut répondre à au système car le timezone n’a pas été défini dans php.

Capture d’écran 2009-10-04 à 15.53.29

Reste donc a aller faire un tour dans votre php.ini, a rechercher « date.timezone = » et à plus préciser « Europe/Paris » (oui ici on est en France monsieur!) en prenant soin de décommenter la ligne (retirez le « ; »)

Bon maintenant que j’ai downgrader mes serveurs en 5.2.10 je vais pouvoir remonter sur une 5.3!

One response so far

Uffie – Pop the Glock

sept 16 2009

EDIT Clip Officiel:

Uffie Pop The Glock from Uffie on Vimeo.

Autre version:

2 responses so far

Partager une librairie PHP entre plusieurs sites

sept 07 2009

Sur un serveur en production, il peut nous arriver d’avoir plusieurs sites qui utilisent le même framework, ou le même fichier de configuration. De la même manière, les framework, comme dans mon cas Zend Framework, évoluent très rapidement et il peux être utile de gérer plusieurs versions sur le même serveur. Dans tous les cas, cette manipulation vous fera économiser de la place et facilitera vos mises à jours.

Commençons alors par placer dans un répertoire le ou les framework ainsi que les versions qui nous intéressent et incluons ce répertoire dans la configuration de php (votre fichier php.ini).
Recherchez la ligne contenant la directive « include_path ». Celle si est commentée par défaut à l’aide d’un point-virgule (;). Elle décrit les différents répertoires contenant des fichiers sur lesquels nous voulons faire des include().
Décommentez alors la ligne en supprimant le point-virgule et adapter la description du chemin en fonction de l’endroit où vous avez placer vos librairies.
Dans mon cas, cela donne:

include_path = « .:/var/www/library »

Pensez à conserver le « . » dans la liste des chemins à inclure afin de pouvoir inclure un fichier localement dans vos différentes applications php et redémarrez votre serveur http.

Dans le cas où nous avons plusieurs versions, il peut aussi être intéressant de simplifier le chemin d’accès à la dernière version stable.
On peux alors utilise de manière toute simple utiliser les liens virtuels unix:

$ ln -s Zend_1.9.2 Zend

Pensez également à régler vos droits sur vos librairies:

# chown -R www-data:www-data /var/www/library

Capture d’écran 2009-09-07 à 21.45.28
Enfin, voyons comment nous allons pouvoir utiliser cette librairie partagée coté applications. Je reprend alors mon exemple de Zend et le fichier bootstrap dans lequel nous avions l’habitude de re-écrire le path d’include de php (ici Zend se trouvais dans le ./library et ./application/models/ contient les modèles de notre application MVC):

set_include_path(‘.’
. PATH_SEPARATOR . ‘./library’
. PATH_SEPARATOR . ‘./application/models/’
. PATH_SEPARATOR . get_include_path());

Le path contenant le Zend Framework étant maintenant inclue par le « get_include_path() » nous pouvons supprimer le ./library des répertoires inclus.

Ensuite nous appelions notre framework avec la ligne:

require_once ‘Zend/Loader/Autoloader.php’;

Si vous avez suivit toutes les indications précédente et que vous laissez la ligne telle quelle, le site chargera ici la version courante de Zend Framework que j’ai décrit tout à l’heure par le lien logique unix. C’est ici que ça deviens intéressant et que nous pouvons préciser la version de Zend à utiliser.

Selon la manière donc vous avez nommé vos répertoires (dans mon cas Zend_x.y.z ou x.y.z correspond à la version du framework), vous pouvez alors appeler par exemple une version 1.6.2 de Zend dans une ancienne application.

require_once ‘Zend_1.6.2/Loader/Autoloader.php’;

Libre à vous d’adapter tout cela à vos propres conventions de nommage et de rangement.

No responses yet

Configuration d’Exim pour l’envoi externe

août 22 2009

La plupart des applications web que nous pouvons être amené à déployer sur un serveur web utilise des fonctions d’envoi de mails.

Afin de gérer soit même les files d’attentes, il peut alors être utile d’héberger soit même un serveur SMTP directement sur la machine qui héberge l’application. Nous allons donc voir comment configurer simplement Exim pour l’envoi de mails vers les domaines externes. Nous utiliserons une distribution Debian stable.

Commençons par installer Exim:

# aptitude install exim4

Exim va alors s’installer avec une configuration de base que nous allons modifier avec l’assistant fourni par exim4-config:

# dpkg-reconfigure exim4-config

Le premier écran vous expliquera le rôle de cet utilitaire, validez avec « Ok » pour passer à l’écran suivant.

Sur celui si, choisissez « Distribution direct par SMTP (site internet) ».

Ensuite sur l’écran suivant entrez le nom tel que vous l’avez défini dans votre configuration ou tel qu’il a été défini par votre hébergeur.

Deux écran plus loin, l’assistant va vous demander sur quelle adresse il va devoir accepter le courrier. Puisque nous sommes parti sur une configuration simple où le serveur d’applications (php par exemple) se trouve sur la même machine, nous utiliseront donc l’adresse 127.0.0.1 pour limiter les connections au serveur avec lui-même.

L’écran suivant nous demande alors de préciser sur quel autre nom le serveur doit accepter les mails. Nous pouvons ici lui repriser le nom DNS de notre machine.

Vient ensuite, la question des domaines à relayer. Nous l’avons déjà vu, nous n’acceptons les mails entrant que sur l’adresse de localhost: 127.0.0.1. Nous pouvons donc autoriser le transfert vers tous les domaines afin que les mails puissent sortir. Remplissez donc ce champ avec une étoile « * ».

Laissez la liste des machines à relayer vide car nous souhaitons que le serveur transmette lui même les mails sortants.

Deux écran plus loin, répondez « Non » à la proposition de minimiser les requêtes DNS, laissez la distribution du courrier au « format mbox dans /var/mail » et ne séparez pas la configuration dans plusieurs fichiers.

L’assistant va se fermer et va redémarrer Exim et vous pourrez tester sans problème le bon fonctionnement de votre MTA par exemple avec la fonction mail() de PHP.

No responses yet

Twitter par script

août 21 2009

Histoire d’intégrer twitter dans vos script, voici comment tweeter simplement via ligne de commande:

curl -k -u user:pass -d status= »mon tweet » https://twitter.com/statuses/update.xml

One response so far

NSlookup et Dig: surveillez vous mises à jours DNS

août 18 2009

Lors de l’achat d’un nom de domaine chez un registar, celui ci fourni généralement des services d’hébergement, de mails, mais aussi les services DNS liés à la gestion de ce domaine. On peux alors modifier directement sa configuration DNS dans l’interface mis à disposition par l’hébergeur et cette configuration sera alors répliquée sur les différents serveurs DNS desservant votre nom de domaine.

Nous allons voir ici comment contrôler la mise en applications de vos modifications via 2 outils en lignes de commande: NSLookup (présent sur tous systèmes) et Dig (présent de base sous Linux et Mac OS X, une version cygwin existe pour Windows).

Prenons un exemple concret, je viens de migrer mon blog sur un nouveau serveur et je souhaite que l’adresse « blog.lelevier.fr » pointe bien sur ce nouveau serveur. J’ai fait les modifications nécessaire dans l’interface de mon registar et je connaît l’adresse ip ou le nom de mon nouveau serveur.

Commençons par NSLookup avec une requête simple:

23:03: tibo@Boudallu ~ % nslookup blog.lelevier.fr
Server: 192.168.1.1
Address: 192.168.1.1#53

Non-authoritative answer:
blog.lelevier.fr canonical name = rps.lelevier.fr.
Name: rps.lelevier.fr
Address: 87.98.170.232

Ici c’est mon serveur DNS local qui me répond (192.168.1.1) et bien qu’il n’ai pas autorité sur le domaine (il ne le gère pas directement) il me répond que « blog.lelevier.fr » est un Alias de « rps.lelevier.fr » défini par l’adresse « 87.98.170.232″ qui est justement mon serveur.

Même si le résultat est ici concluant nous allons partir sur le cas où la modification n’a pas encore été répliquée sur notre serveur local.
Regardons alors directement sur les serveur DNS de notre registar pour voir si les modifications ont était prise en compte sur ces derniers.
Commençons par trouver l’adresse ou le nom des serveurs DNS faisant autorité sur notre domaine avec Dig:

23:04: tibo@Boudallu ~ % dig NS lelevier.fr

; <<>> DiG 9.4.3-P3 <<>> NS lelevier.fr
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64451
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2

;; QUESTION SECTION:
;lelevier.fr. IN NS

;; ANSWER SECTION:
lelevier.fr. 86400 IN NS dns11.ovh.net.
lelevier.fr. 86400 IN NS ns11.ovh.net.

;; ADDITIONAL SECTION:
dns11.ovh.net. 86371 IN A 213.251.188.130
ns11.ovh.net. 86371 IN A 213.251.128.130

;; Query time: 54 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Wed Aug 19 00:06:38 2009
;; MSG SIZE rcvd: 107

Nous pouvons lire ici dans la zone « ANSWER SECTION » que notre domaine est gérer par les serveur « dns11.ovh.net » et « ns11.ovh.net ».
Retournons alors maintenant sur NSLookup pour vérifier l’état de la résolution sur un serveur précis.
Lançez NSLookup sans argument avec la commande « NSLookup », spécifiez le serveur DNS avec l’option « server » suivit du nom ou de l’ip d’un des serveur trouvé au dessus, et enfin entrez le nom DNS que vous souhaitez résoudre:

23:06: tibo@Boudallu ~ % nslookup
> server dns11.ovh.net
Default server: dns11.ovh.net
Address: 213.251.188.130#53
> blog.lelevier.fr
Server: dns11.ovh.net
Address: 213.251.188.130#53

blog.lelevier.fr canonical name = rps.lelevier.fr.
Name: rps.lelevier.fr
Address: 87.98.170.232
>

On peut alors lire ici que le serveur en question redirige encore une fois « blog.lelevier.fr » vers l’hôte « rps.lelevier.fr » dont l’adresse est « 87.98.170.232″. On pourra alors vérifier sur le second serveur DNS que les informations concordent et en conclure l’état de notre modification et sa prise en compte par notre registar.

A noté cependant qu’il faut généralement entre 4h et 48h pour que la modification soit répliquée.

No responses yet

True Blood saison 2

août 04 2009

Depuis quelques semaines maintenant la saison 2 de True Blood est diffusé tout les dimanches soir (heure US) sur HBO.

Même si l’histoire stagne un peux au début de la saison, une fois les nouveaux personnages en place, l’intrigue reprendre de plus belles (épisode 6/7).

Le 31 Juillet dernier, HBO à annoncé officiellement la 3ème saison qui sera diffusée en 2010.

En attendant, prochain épisode dans la nuit de dimanche prochain!

No responses yet