A la fin de la journée, comme la plupart d’entre vous j’éteins mon portable pour aller sur mon fixe ! vaquer à mes occupations et très souvent le matin quand je le rallume mon navigateur charge les mêmes onglets que la veille. C’est pratique, mais si j’étais en train de développer un script sensé se lancer la nuit et qui s’occupe par exemple de la réparation d’une grosse base de données ou d’un autre processus plutôt gourmand et bien il va probablement ralentir mon système à une heure où tous mes clients se connectent !

Pour ce genre de script j’ai prévu un écran de confirmation qui tient en trois ligne et qui permet lorsque le script n’est pas appelé en CLI de demander une confirmation avant son exécution.

if(php_sapi_name() != 'cli' and !isset($_POST['i-am-sure'])) {
    die('<form action="'.$_SERVER['REQUEST_URI'].'" method="post">
<input name="i-am-sure" type="submit" value="Etes-vous sur de vouloir lancer ce script ?" />
</form>');
}

Maintenant lorsque mon navigateur va ouvrir mes onglets de la veille, je devrais d’abord devoir confirmer que je suis sûr de vouloir le lancer.

Originally posted at Demander la confirmation d’un script PHP avant son exécution

Sans ce système de lock, il serait possible, pour une obscure raison, qu’il soit lancé par le crontab plusieurs fois : on aurait alors un petit script de spam qui enverrait en double ou pire les mêmes emails aux mêmes personnes (si ce sont des clients c’est embêtant !)

Pour éviter ce genre de cas de figure plusieurs solutions sont disponibles :

• on tue les processus déjà lancés avant d’en relancer un autre (en prenant le risque de ne pas laisser terminer la premier instance)
• on empêche les nouvelles instances de se lancer si une d’elle est déjà en cours (c’est cette solution que j’ai retenue)

L’idée étant de faire un script générique que l’on puisse utiliser sur n’importe qu’elle plateforme PHP5 c’est pourquoi pour que la première instance puisse déclarer qu’elle est en fonctionnement j’ai choisi de stocker son PID dans un fichier mais on aurait aussi pu utiliser memcache à la place.

Fini la présentation, voici maintenant un morceau de script générique que l’on peut coller en haut de chaque script CLI pour mettre en place le système de lock.

if(php_sapi_name() == 'cli') {
	$lockname = '/tmp/'.basename($argv[0], '.php').'.lock';
	$pid = is_file($lockname) ? trim(file_get_contents($lockname)) : false;
	if (($pid !== false) && posix_kill($pid, 0)) {
		die('Error: Batch is already running with PID: '.$pid."\n");
	}
	else {
		register_shutdown_function('unlink', $lockname);
		$fp = fopen($lockname, 'w');
		fwrite($fp, posix_getpid());
		fclose($fp);
	}
}

Les fonctions remarquables sont les posix_xxx accessibles uniquement en mode CLI (d’où la vérification du mode d’appel tout en haut avec php_sapi_name) et register_shutdown_function qui permet d’éxécuter une fonction à la fin du script (peu importe la façon dont sa fin est arrivée !)

Je ne trouve pas tellement de défauts à cette méthode alors si vous vous en voyez n’hésitez pas à les partager via les commentaires.

Originally posted at Système de lock d’éxécution de script PHP

Prenons un exemple : cakecoding.com acheté et hébergé chez OVH, il configuré nativement pour répondre à l’adresse cakecoding.com ou www.cakecoding.com.

Plutot que de laisser choisir les moteurs de recherche (= Google) au hasard nous allons les rediriger (les robots et nos visiteurs humains) vers le format de domaine que nous aurons choisis !

Pour ne pas perdre le positionnement éventuel des pages du domaine que nous n’avons pas retenu, toutes les “mauvaises” urls seront redirigées vers les “correctes” avec une redirection 301 dite permanente.

Il y a plusieurs façon de procéder :

• avec PHP via la fonction header
• avec Apache, mod_rewrite et un fichier .htaccess
• certainement bien d’autres…

Comme la méthode PHP ne permet de couvrir que les pages générées dynamiquement en PHP justement (Adieu images référencées ou autre contenu statique !), nous allons traiter la seconde méthode qui est, à mon sens la plus élégante.

En reprenant notre exemple, ce code permet de privilégier www.cakecoding.com :

RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\.cakecoding\.com$
RewriteRule ^(.*) http://www.cakecoding.com/$1 [QSA,L,R=301]

Celui là permet de faire l’inverse et privilégier le nom de domaine cakecoding.com :

RewriteEngine On
RewriteCond %{HTTP_HOST} !^cakecoding\.com$
RewriteRule ^(.*) http://cakecoding.com/$1 [QSA,L,R=301]

Je ne vais pas traiter en détails les commandes utilisées car la documentation disponible en ligne est vraiment bien faite. (Apache 1.3 mod_rewrite, Apache 2 mod_rewrite).

Maintenant, comme nous sommes tous de gros paresseux, nous voulons un code réutilisable !

Voici la version “domain-free” qui fonctionnera sur n’importe lequel de vos sites sans modifications aucunes.

Ici on privilégie le www.domain.tld :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^([^\.]+)\.([^\.]+)$
RewriteRule ^(.*) http://www.%1.%2/$1 [QSA,L,R=301]

Et ici on privilégie le domain.tld :

RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.([^\.]+)\.([^\.]+)$
RewriteRule ^(.*) http://%1.%2/$1 [QSA,L,R=301]

Si vous avez des remarques ou des questions, je serais vraiment très heureux de les lire dans les commentaires.

[Edit] Comme le souligne Arnaud, si on veut un code portable, il est bon de tester la présence du module modrewrite sur le serveur en entourant les instructions si dessus de

<IfModule mod_rewrite.c>
(...)
</IfModule>

Originally posted at Redirection automatique www avec .htaccess

Originally posted at Hello world!