1. Initialisez votre IIS Manager (touche Windows puis saisir « iis » et appuyer sur Return) ;
2. Dans la zone IIS, double-cliquer sur « FastCGI Settings » :
3. Dans la liste des exécutables PHP qui apparaît, double-cliquez sur celle pour laquelle vous souhaitez ajouter la variable d’environnement APPLICATION_ENV :
4. Dans la zone « FastCGI Properties », sélectionnez « Environnment Variables », puis cliquez sur le bouton de droite :

   

5. Dans la boîte de dialogue, cliquez sur le bouton « Add » :

   

6. Dans la zone de droite, modifiez la valeur du champ « Name » pour la remplacer par « APPPLICATION_ENV » :

   

7. Dans le champ « Value », indiquez comme valeur « development » :

   

Vous pouvez trouver des informations complémentaires à l’URL ci-dessous :

http://www.iis.net/ConfigReference/system.webServer/fastCgi/application/environmentVariables

J’ai présenté pendant cette soirée l’application Architectes Web Solution créée par notre entreprise Otoo. Cette application après avoir été customisée et mise en place, permet aux architectes ou aux agences d’architecture, de gérer les contenus de leur site Internet sans aucune connaissance du développement de sites.

Un des avantages de cette solution est la structuration des sites ainsi produits au référencement naturel. Nous avons envisagé la structuration des sites et l’optimisation du code généré en amont du développement de la plateforme.
La question posée est très pertinente et pouvait être déstabilisante. « Si tous les sites produits sont bien structuré pour un référencement naturel, comment mon site va sortir avant ceux de mes confrères ? »
Je viens ici, rappeler quelques notions nécessaires à un bon référencement naturel.

Technologies

Il est important de penser au référencement du site en amont de son développement. Il est primordial que les moteurs de recherche aient accès à toutes les pages du site. De ce fait, il faudra choisir les technologies adéquates. Les éléments tels le JavaScript et le Flash ne doivent pas être structurants au risque de voir les robots ne pas visiter le site et donc ne pas indexer certains (ou toutes) pages du site. Il est bien évident que notre propos n’est pas de dire qu’il ne faut pas utiliser ces technologies, elles doivent être utilisées à bon escient.

URL

Le nom de domaine est un des éléments à prendre en compte dans la stratégie de référencement. Ainsi la présence d’un mot clé important donnera plus de poids à son référencement. D’autre part, les noms de pages doivent être très explicites (URL rewriting) et en rapport avec le titre de celle-ci.

Contenus

A une requête de recherche sur un moteur de recherche, celui-ci va scruter les pages dont le contenu se rapproche de la demande. Et à partir de ce moment, il devra les classer en fonction de la pertinence. Personne ne connaît précisément les critères de classement, même si on s’accorde à dire que cela dépend de :
- Nombre d’occurrences dans la page (attention aux abus) ;
- Présence de cette occurrence dans l’URL, le titre de la page ;
- Nombre de liens internes vers la page ;
- Nombre de liens externes vers la page (backlinking) ;

Mise à jour des contenus

Un site qui renouvelle ses différents contenus sera mieux noté que ceux qui n’évoluent pas. Cette notion est importante au risque de voir son site dégringoler dans les réponses des moteurs de recherche.

Organisation du contenu

Comme on le fait dans nos rédactions, il est judicieux de bien organiser les contenus afin de faciliter la lecture aux visiteurs et aussi aux moteurs de recherche.
Hiérarchiser son contenu en utilisant les balises titres (<h#>) lui conférera une meilleure structure et montrera l’importance des niveaux de titres.
En suivant cette logique, dans un même niveau de texte, si on veut montrer l’importance d’un mot ou d’une phrase, il faudra utiliser la balise de mise en forme « gras » (<strong>).

Liens

Les moteurs de recherche vont donner plus d’importance aux pages vers lesquelles plusieurs liens sont trouvés. Ces liens sont encore plus pertinents s’ils sont en haut de page ou si plusieurs endroits du site font référence à cette page. Il est bien sûr recommandé que le texte cliquable soit explicite et contienne les occurrences que l’on souhaite voir inéxées.

Images

Les moteurs de recherche ne perçoivent pas les images. Pour leur indiquer la présence des images et ainsi augmenter le contenu de la page, il faudra renseigner la balise de texte alternatif.

Suivi du référencement du site

Une fois référencé, il est important de suivre l’évolution du positionnement et la qualité du trafic. Ceci permettra d’affiner son référencement en choisissant de nouveaux mots clés et de surveiller ses concurrents.

Outils

Plusieurs outils permettent de suivre le positionnement de son site et le trafic généré par les différents mots clés. Certains gratuits comme Google Analytics et les outils pour Webmasters de google peuvent rendre énormément de services.

L’achat de mots clés.

Il peut être judicieux de compléter son référencement naturel par des campagnes d’achat de clics. Pour qu’elle reste abordable et efficace, cette étape doit se faire sur des produits spécifiques et sur lesquels la concurrence reste limitée.

Voici le contexte dans lequel nous nous trouvons dans le cadre de cet article :

• un modem routeur qui effectue du NAT (Network Address Translation) de l’Internet vers un serveur HTTP du réseau local (le traffic entrant sur le port 80 est redirigé vers le port 80 du serveur du réseau local) ;
• un serveur Linux (Fedora Core 9) hébergeant de multiples services dont un serveur HTTP (Apache 2.2.9) ;
• sur ce même serveur, nous trouvons également le services iptables que nous allons utiliser pour mettre en place notre filtrage.

L’objectif

L’objectif de cet article est d’utiliser iptables de notre serveur pour limiter l’accès au service HTTP, en se basant sur les adresses IP transportées par les paquets réseau entrants.

Modifier les règles iptables

Connectez-vous en mode console (via un client SSH par exemple) à votre serveur pour y modifier les règles iptables.

Les règles iptables sont réparties en chaînes :

• INPUT : règles agissant sur les paquets réseau entrants sur le serveur ;
• FORWARD : règles agissant sur les paquets réseau passant d’une interface réseau à une autre (d’un serveur à un autre par exemple) ;
• OUTPUT : règles agissant sur les paquets réseau sortants du serveur.

Dans notre cas, nous allons créer plusieurs règles iptables au sein de la chaîne INPUT, puisqu’il s’agit de filtrer les paquets réseau entrants.

Sauvegarder

Avant d’aller plus loin, nous allons avant tout procéder à la sauvegarde des règles iptables existantes, on ne sait jamais…

Pour cela, utiliser la ligne de commande qui suit :

iptables-save > /etc/iptables-save

En cas de problème, pour restaurer, vous pourrez utiliser la commande suivante :

iptables-restore < /etc/iptables-save

Lister les règles courantes

Pour visualiser la liste des règles iptables en place, utiliser la commande :

iptables -L

Cette commande vous permettra ainsi de visualiser les modifications apportées à vos règles iptables.

Ajouter les règles nécessaires au filtrage

Les règles iptables sont lues de haut en bas. Il faut donc insérer en haut de la liste des règles, nos nouvelles règles iptables afin qu’elles écrasent éventuellement celles qui ne nous conviennent plus.

Nous commençons par ajouter une règle iptables pour rejeter tous les accès HTTP à notre serveur (port 80) :

iptables -I INPUT -p tcp --dport 80 -j REJECT

L’option -I INPUT permet d’insérer la nouvelle règle en haut de la liste de la chaîne INPUT. L’option -p tcp permet de préciser le protocole et l’option –dport 80 indique le port de destination, dans notre cas, le port 80, celui qui correspond généralement au service HTTP. Enfin, la dernière option -j REJECT, indique le saut (ou l’action à accomplir si les conditions sont remplies) qui doit être fait. Dans notre cas, nous demandons le rejet. Nous aurions aussi pu indiquer DROP, mais il semble que REJECT soit plus propre…

Ensuite, nous ajoutons une règle iptables pour autoriser les machines du réseau local à se connecter à ce serveur HTTP :

iptables -I INPUT -s 192.168.0.0/24 -p tcp --dport 80 -j ACCEPT

L’option -s 192.168.0.0/24 permet d’indiquer la source concernée. Dans notre cas, nous indiquons toutes les machines du réseau local. Le masque /24, indique que seul la dernière partie de la plage IP est variable. On accepte donc les IP du genre : 192.168.0.1, 192.168.0.2, 192.168.0.3, etc., jusqu’à 192.168.0.254 (255 valeurs possibles en tout).

Pour terminer, vous pouvez ajouter une règle iptables pour chaque adresse IP que vous souhaitez autoriser en accès à notre serveur HTTP :

iptables -I INPUT -s XXX.XXX.XXX.XXX -p tcp --dport 80 -j ACCEPT

En effectuant :

iptables -L

Vous devriez voir apparaître vos nouvelles règles iptables en haut de la liste, au sein de la chaîne INPUT.

Vous pouvez sauvegarder vos règles iptables modifiées de cette façon :

iptables-save > /etc/iptables-save-updated

Mémoriser les nouvelles règles

La distribution Linux Fedora Core 9 donne la possibilité de mémoriser facilement (et définitivement) vos règles iptables modifiées :

service iptables save

Cette opération doit impérativement être faite pour que les règles iptables soient conservées, même après un reboot de votre serveur.

Redémarrer le service iptables

Pour prendre en compte immédiatement les nouvelles règles, redémarrez le service iptables :

service iptables restart

Une erreur peut se produire et rendre le comportement de votre application inattendue lorsqu’un fichier est manquant. Ce fichier peut être une image, une feuille de styles CSS, un favicon.ico ou tout autre généralement placé dans le répertoire /public de l’arborescence du framework.

L’erreur retournée est levée par une exception du type Zend_Controller_Dispatcher_Exception et retourne le message ci-dessous (exemple d’un fichier favicon.ico manquant) :

Zend_Controller_Dispatcher_Exception: Invalid controller specified (favicon.ico)

Le plus simple est dans ce cas d’ajouter le fichier manquant.

Principe des règles de réécriture d’URL

Fichier .htaccess

La raison de ce problème vient des règles de réécriture d’URL telles que proposées sur le site de Zend Framework à l’URL http://framework.zend.com/manual/fr/zend.controller.router.html.

Ci-dessous les règles de réécriture pour Apache, à placer dans un fichier .htaccess, dans le répertoire /public de l’application :

Code block

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Regardons rapidement ensemble les directives ci-dessus.

Directive RewriteEngine

La première directive RewriteEngine est placée à la valeur On. Elle active simplement le moteur de réécriture d’URL d’Apache.

Directives RewriteCond

Les directives commençant par RewriteCond vont conditionner l’exécution de la directive RewriteRule qui suit.

Dans notre cas, le test se fait sur la variable serveur REQUEST_FILENAME qui contient le chemin d’accès absolu à un script ou un fichier correspondant à la requête courante.

Cette chaîne à tester est immédiatement suivie de la condition à effectuer.

La condition -s (is regular file with size) permet de vérifier l’existence d’un fichier dont le poids est strictement supérieur à 0 octet.

La condition -l (symbolic link) permet de vérifier l’existence d’un lien symbolique.

La condition -d (is directory) permet de vérifier l’existence d’un répertoire.

Par défaut, les conditions imposées par les directives RewriteCond se combinent (AND). Si l’on souhaite tester une des conditions, il faut alors placer le flag [OR] en fin de directive.

Directives RewriteRule

Les directives RewriteRule sont celles qui définissent la règle de réécriture elle-même.

La première d’entre elles :

Code block

RewriteRule ^.*$ - [NC,L]

ne fait qu’indiquer qu’il ne faut rien faire (c’est ce qu’indique le tiret placé juste avant les flags NC et L) si les conditions imposées par les directives RewriteCond qui précèdent sont remplies.

La suivante :

Code block

RewriteRule ^.*$ index.php [NC,L]

qui sera exécutée dans tous les autres cas redirige vers le Front Controller de notre application, c’est-à-dire le fichier index.php.

Ces directives possèdent dans notre cas des flags (ils apparaissent entre crochets).

Le flag NC correspond à No Case, ce qui rend la comparaison insensible à la casse.

Le flag L correspond à Last. Ceci signifie que si la règle de réécriture correspondante est réalisée, alors toutes celles qui suivent ne seront pas interprétées.

Modifier les règles de réécriture d’URL

De façon plus générale, et afin d’éviter les levées d’exceptions, je vous propose de modifier votre fichier .htaccess comme ci-dessous :

Code block

RewriteEngine On
RewriteRule ^\/?styles.*$ - [NC,L]
RewriteRule ^\/?media.*$ - [NC,L]
RewriteRule ^\/?js.*$ - [NC,L]
RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Le principe est de regarder tous les répertoires qui sont placés dans le répertoire /public de votre application puis d’utiliser des directives RewriteRule pour indiquer que ces répertoires et tout ce qui s’y trouve ne doivent pas être redirigé vers le Front Controller (index.php). Ils continueront ainsi à être considérés comme des répertoires et des fichiers, même si l’un d’entre eux n’existe pas.

C’est ce que je viens de faire en ajoutant les trois directives ci-dessous :

Code block

RewriteRule ^\/?styles.*$ - [NC,L]
RewriteRule ^\/?media.*$ - [NC,L]
RewriteRule ^\/?js.*$ - [NC,L]

à mon fichier .htaccess.

Dans mon cas, ces réécritures d’URL ont été faites pour les répertoires styles, media et js.

Les expressions régulières utilisées pour trouver les chaînes de texte se décomposent comme suit :

^ pour indiquer le début de la chaîne ;

\/? pour indiquer la présence facultative du / de début de chaîne ;

.* pour indiquer n’importe quel caractère (présent ou non) ;

$ pour indiquer la fin de la chaîne.

Entre ^\/? et .*$, se trouve le nom du répertoire à traiter.

Conclusion

Du coup, avec ces nouvelles règles de réécriture d’URL, lorsqu’on essaie d’accéder à un répertoire ou à un fichier contenu dans styles, media ou js, une erreur 404 (page manquante) est retournée par Apache. A vous de la traiter correctement pour obtenir un résultat professionnel !

Ces ajouts dans le fichier .htaccess nous permettent surtout d’éviter des problèmes lors de l’emploi des méthodes du Zend Framework qui manipulent les requêtes HTTP, comme getRequestUri() ou bien d’autres.

Cet article explique comment installer le framework PHPUnit fréquemment utilisé pour les tests unitaires des applications PHP. Cet article part également du principe que l’installation de WAMP est effectuée.

Etape 1 : installation de PEAR

Voici, en quelques étapes, comment installer PHPUnit sous WAMP. Nous allons utiliser PEAR pour procéder à cette installation. Il faut donc l’installer. Evidemment, si c’est déjà fait, vous passer directement à l’étape 2 (installation de PHPUnit avec PEAR).

1. Ouvrir une invite de commande (pour aller plus vite, sous Windows Vista ou 7, saisir simplement « cmd » dans le champ de recherche du menu « Démarrer » puis appuyer sur la touche « Entrée » du clavier) ;

2. Se déplacer dans le répertoire contenant le binaire PHP de WAMP. Dans mon cas, cela revient à faire la commande qui suit :

Code block

C:\cd C:\wamp\bin\php\php5.2.9-2

3. Lancer ensuite le fichier « go-pear.bat » ;

4. Quelques questions vous sont ensuite posées. Laisser les valeurs par défaut (à moins que vous ne sachiez exactement ce que vous êtes en train de faire).

5. A la fin de l’installation de PEAR, un fichier PEAR_ENV.reg est créé dans le même répertoire. Il faut le lancer pour créer les variables d’environnement nécessaires au fonctionnement de PEAR. Deux solutions sont possibles pour cela : soit en ligne de commande avec :

Code block

C:\wamp\bin\php\php5.2.9-2>PEAR_ENV.reg

Ou alors en vous rendant dans le répertoire en question, puis en double cliquant sur le fichier PEAR_ENV.reg.

Etape 2 : installation de PHPUnit avec PEAR

Voici ci-dessous comment procéder à cette installation.

1. Indiquer à PEAR le channel de PHPUnit :

Code block

C:\wamp\bin\php\php5.2.9-2>pear channel-discover pear.phpunit.de

Avant de passer à l’étape qui suit, vous aurez peut-être besoin de mettre à jour la version de PEAR et d’autres packages déjà installés.

Si nécessaire, vous pouvez le faire avec la commande :

Code block

C:\wamp\bin\php\php5.2.9-2>pear upgrade-all

2. Installer le package PHPUnit :

Code block

C:\wamp\bin\php\php5.2.9-2>pear install -a phpunit/PHPUnit

L’option « -a » derrière la commande « install » est importante. Elle permet de forcer l’installation de tous les autres packages dont dépend PHPUnit.

Pour vérifier que l’installation s’est correctement effectuée, vous pouvez saisir la commande :

Code block

C:\wamp\bin\php\php5.2.9-2>pear list -a

L’option « -a » derrière la commande « list » permet de lister les packages de tous les channels.

Avant de commencer, il est important que je vous précise que cet article n’est pas destiné à expliquer comment s’effectue le débogage d’une application avec VS.Php, ni même son fonctionnement.

Nous allons surtout voir ensemble en quelques étapes comment arriver à configurer VS.Php et WAMP pour pouvoir déboguer une application ou un site développé avec PHP 5.

Ceci dit, j’essaierai de faire un autre article sur l’utilisation du débogage avec VS.Php.

Étape 1 : installer et activer XDEBUG

Récupérer l’extension XDEBUG

Pour cela, il faut récupérer un fichier DLL à l’URL : http://www.xdebug.org/download.php.

Dans les sections « Windows binaries », trouvez la version qui correspond à votre installation. Par exemple, dans mon cas, la version de PHP installée avec mon WAMP est la 5.2.9-2. J’ai donc choisi comme version de XDEBUG : « 5.2 VC6 (32 bit) ».

Pour vérifier si votre installation est en mode NTS (Non Thread Safe) ou pas, afficher simplement le phpinfo() à partir de la zone « Outils » de la page d’accueil de WAMPSERVER.

Accéder à phpinfo() à partir de l'accueil de WAMP

Si « Thread Safety » est « enabled », alors vous n’êtes pas en « Non Thread Safe ». Dans le cas contraire, vous êtes en mode « Non Thread Safe », il faudra alors télécharger la version « 5.2 VC6 Non-thread-safe (32 bit) » de XDEBUG.

Vérification du mode d'exécution de PHP

Placer l’extension

Il faut ensuite placer le fichier DLL récupéré (« php_xdebug-2.0.5-5.2.dll » pour moi) dans le répertoire d’exécution de PHP. Dans mon cas, ce répertoire est « C:\wamp\bin\php\php5.2.9-2 ».

Modification du « php.ini »

Il faut ensuite modifier le fichier « php.ini » géré par WAMP pour lui ajouter les directives qui suivent. Pour ouvrir le fichier « php.ini », le plus rapide est de passer par le menu d’administration de WAMP en sélectionnant « PHP » puis « php.ini ».

Voici les lignes à ajouter (en fin de fichier pour faire simple) :

Code block

zend_extension_ts = C:/wamp/bin/php/php5.2.9-2/php_xdebug-2.0.5-5.2.dll
[XDebug]
xdebug.idekey = vsphp
xdebug.remote_enable = 1
xdebug.remote_port = 7870
xdebug.remote_autostart = 1

Pour plus d’informations sur ces directives, vous pouvez consulter l’URL (en anglais) : http://www.xdebug.org/docs/remote.

En gros, nous venons d’indiquer à l’extension XDEBUG qu’elle peut écouter les connexions distantes sur le port 7870.

Pour que ces modifications soient prises en compte, il faut évidemment redémarrer le service Apache de WAMP.

Attention, le chemin d’accès à l’extension XDEBUG peut varier en fonction de votre installation, et en particulier en fonction de la version installée de PHP.

Pour vérifier que l’extension a bien été prise en compte, afficher à nouveau le phpinfo() de WAMP. Si une zone « xdebug » apparaît, c’est que l’extension est correctement installée.

Vérification de l'activation de l'extension XDEBUG dans phpinfo()

Étape 2 : configurer VS.Php

Pour accéder au débogage à partir de VS.Php en utilisant un alias ou un virtual host d’une application ou d’un site hébergé par WAMP, il faut également procéder à quelques réglages de configuration dans VS.Php.

Ouvrir votre projet VS.Php

La première chose à faire est d’ouvrir le projet VS.Php de votre application ou de votre site PHP. En effet, sous VS.Php les paramètres de configuration du débogage, comme pour ceux du déploiement, sont attachés au projet.

Modifier les paramètres de configuration pour le débogage

Il faut maintenant indiquer à VS.Php comment il doit initialiser le débogage de notre application ou de notre site.

Dans Visual Studio, il faut pour cela accéder à la commande « Propriétés de votre projet… » du menu « Projet ».

Pour terminer, il ne reste plus qu’à renseigner les deux panneaux « General » et « Advanced » de la zone de configuration « Debug » comme ci-dessous.

Configuration générale du débogage

Le champ « Start Url » doit contenir l’alias ou le virtual host de votre site ou de votre application défini dans WAMP.

Configuration avancée du débogage

Le plus important ici, c’est que le port indiqué dans le champ « Debug client port number » corresponde à celui placé toute à l’heure dans la directive « xdebug.remote_port » du « php.ini ».

Il ne reste plus qu’à valider le tout en cliquant sur le bouton OK et à appuyer sur F5 pour lancer le débogage.