La démarche normale consiste d’abord à rédiger l’article, ensuite à modifier la date de publication pour une date à venir et finalement à cliquer «Publish».

Dans les versions plus récentes de Wordpress, la date à venir est automatiquement détectée et le texte du bouton «Publish» est alors remplacé par «Schedule».

Après ces étapes, dans la colonne «Date» de la liste des communiqués, on remarque le texte «Scheduled» sous la date de publication du communiqué en question.

Ces étapes sont donc faciles à suivre. Le problème, c’est que ça ne marche pas toujours. Il arrive parfois que le réveil de Wordpress refuse obstinément de sonner !

En effectuant des recherches, j’ai découvert que Wordpress procède à la publication automatique des articles par l’entremise du script wp-cron.php qui est responsable de changer au moment opportun le statut «Scheduled» des articles à paraître pour «Published». Le script est appelé à intervalles réguliers via une requête HTTP grâce à la fonction PHP fsockopen. Un des paramètres de cette fonction est l’url du site Web. Pour que fsockopen fonctionne il doit donc être exécuté sur un serveur qui est en mesure de résoudre son propre nom de domaine. Ça n’était pas le cas sur mon serveur et c’est précisément la raison pour laquelle la publication automatique ne fonctionnait pas.

Vous pouvez vérifier si c’est aussi votre cas en exécutant le script suivant sur votre serveur Web (sans oublier de remplacer «example.com» par l’url de votre site Web et d’ajuster le chemin vers le fichier «wp-cron.php») :

<?php
$argyle = fsockopen( 'example.com', 80, $errno, $errstr, 0.01 );
if ( $argyle ) {
fputs( $argyle, "GET /wp-cron.php HTTP/1.0\r\n" . "Host: example.com\r\n\r\n");
echo "Success sending the GET.\n";
} else {
echo "Error: $errstr ($errno)\n";
}
?>

Si vous obtenez une erreur du type «[function.fsockopen]: php_network_getaddresses: getaddrinfo failed: No such host is known», vous êtes probablement dans la même situation. Dans ce cas, vous pouvez contacter le service technique de votre hébergeur afin de signaler que le serveur Web n’arrive pas à résoudre son propre nom de domaine et demander à ce qu’on apporte les corrections nécessaires.

Si vous contrôlez votre serveur Web, une solution possible consiste à ajouter une entrée au fichier hosts de votre système afin de faire pointer votre nom de domaine sur 127.0.0.1.

Moralité : There is no places like 127.0.0.1 !

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="index.aspx.cs" Inherits="index" Title="dgiw - accueil" %>

<%@ OutputCache Duration="60" VaryByParam="none" %>

Ce code constitue la plus simple expression de la directive de mise en cache. Pour plus de détails sur cette technique, consultez la documention sur MSDN.

La seule ombre au tableau lorsqu’on utilise la directive «OutputCache» est qu’elle cohabite mal avec les extensions et les contrôles du AJAX Control Toolkit. Si, par exemple, on tente d’ajouter une extension AutoComplete à un contrôle TextBox dans une page avec une directive «OutputCache», on risque d’avoir le message d’erreur suivant :

Javascript error: AjaxToolkit is undefined.

Lorsqu’une requête est adressée à une page contenant une directive @OutputCache, le code côté-serveur ne sera pas exécuté si la page est déjà mise en cache. À ce moment, seulement le HTML et le code JavaScript mise en cache seront retournés, sans les références aux scripts clients de la librairie AJAX.

Dans la réponse officielle de Microsoft aux nombreuses personnes qui ont signalé ce problème, on explique que l’utilisation de «output cache» combinée aux extensions AJAX et aux classes ScriptManagerProxy, ScriptControl et ScriptReference n’est pas encore supportée. La solution proposée par Microsoft consiste à ajouter une référence aux scripts clients, nécéssaires aux fonctionnalités AJAX, à l’extérieur du contrôle mis en cache. Le hic avec cette proposition c’est qu’elle ne peut s’appliquer quand c’est la page en entier qui est mise en cache.

Il existe toutefois une solution. Normalement, avant de pouvoir utiliser des contrôles AJAX dans vos pages Web, vous devez d’abord y inclure un contrôle ScriptManager qui sert à gérer les scripts et les librairies ASP.NET AJAX. Le truc consiste à remplacer le contrôle ScriptManager par un contrôle ToolkitScriptManager, une version améliorée du ScriptManager contenu dans le AJAX Control Toolkit.

Voici un exemple de l’utilisation du ToolkitScriptManager :

<%@ Master Language="C#" AutoEventWireup="true" CodeFile="index.cs" Inherits="index" %>

<%@ Register Assembly="System.Web.Extensions, Version=1.0.61025.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
    Namespace="System.Web.UI" TagPrefix="asp" %>
<%@ Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit" TagPrefix="cc1" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>

</head>
<body>
    <form id="form1" runat="server">
    <cc1:ToolkitScriptManager ID="ToolkitScriptManager1" CombineScripts="true" CombineScriptsHandlerUrl="/CombineScriptsHandler.ashx" runat="server">
    </cc1:ToolkitScriptManager>

Dans le contrôle ToolkitScriptManager, on délégue la tâche de combiner les scripts au HTTP Handler CombineScriptsHandler.ashx. Ce fichier, qu’on trouve dans le site de démonstration du AJAX Control Toolkit, contient le code suivant :

<%@ WebHandler Language="C#" Class="CombineScriptsHandler" %>

using System;
using System.Web;
using AjaxControlToolkit;

public class CombineScriptsHandler : IHttpHandler
{
    /// <summary>
    /// ProcessRequest implementation outputs the combined script file
    /// </summary>
    /// <param name="context"></param>
    public void ProcessRequest(HttpContext context)
    {
        if (!ToolkitScriptManager.OutputCombinedScriptFile(context))
        {
            throw new InvalidOperationException("Combined script file output failed unexpectedly.");
        }
    }

    /// <summary>
    /// IsReusable implementation returns true since this class is stateless
    /// </summary>
    public bool IsReusable
    {
        get { return true; }
    }
}

Grâce à cette démarche, les fichiers JavaScript de la librairie ASP.NET AJAX seront combinés en un seul fichier qui pourra être mis en cache et partagé par l’ensemble des pages où on utilise le contrôle ToolkitScriptManager.

Ainsi, aux bénéfices de la mise en cache de nos pages s’ajoute la réduction du temps de téléchargement des scripts clients, désormais combinés en un seul script composite.

Un des outils de Firebug avec lequel je me suis familiarisé plus récemment est l’onglet réseau, une petite merveille pour surveiller les performances de vos page Web.  L’outil présente une liste des fichiers de la page, avec leur poid respectif, le temps de téléchargement de chacun, l’ordre dans lequel ils ont été chargés, quels sont les fichiers qui proviennent de la mémoire cache et ceux qui proviennent du réseau ainsi qu’une foule d’autres renseignements qui vous permettront de mieux cibler les responsables des lenteurs de certaines de vos pages.

Pour compléter votre arsenal d’optimisation il existe YSlow, une autre extension de Firefox issue des ateliers de Yahoo, qui s’intégre à Firebug  pour évaluer vos pages Web selon une liste de 34 bonnes pratiques.

YSlow analyse vos page et génère un rapport détaillé de ce qui peut être fait pour en améliorer les performances. Parmi les nombreux outils proposé dans YSlow pour vous aider dans votre optimisation, on retrouve JSLint pour analyser vos JavaScripts, All JS Minified pour les compresser et Smush.it,  un service en ligne de Yahoo pour optimiser vos images.

Avec ces extensions, vous disposerez donc de moyens pour transformer votre site Web en bolide de course, pour peu qu’il soit animé par un moteur puissant et hébergé dans une écurie décente !

Pourquoi les projets de backup créés dans MySQL Administrator sur Windows ne se déclenchent-ils pas automatiquement ? J’ai cherché la réponse à cette question un bon moment pour finalement trouver une solution toute simple.

Lorsqu’on créer un projet de backup de base de données et qu’on programme son exécution automatique, cela génère une entrée dans le planificateur de tâches de Windows qui porte le même nom que celui donné au projet de backup dans MySQL Administrator.

L’action de la tâche planifiée se résume comme suit :

"C:\Program Files\MySQL\MySQL Tools for 5.0\MySQLAdministrator.exe" "-UDC:\Users\Denis\AppData\Roaming\MySQL\" "-cDefault" "-bpwp_dgiw" "-btC:\mysql_backups\" "-bxwp_dgiw"

On remarque ici que la commande et ses arguments sont tous entre guillemets et c’est précisément ce qui provoquait des erreurs lors de son l’exécution sur notre serveur Windows 2003. Afin de régler mon problème, je n’ai eu qu’à éditer la commande en retirant les guillemets des quatre derniers arguments :

"C:\Program Files\MySQL\MySQL Tools for 5.0\MySQLAdministrator.exe" "-UDC:\Users\Denis\AppData\Roaming\MySQL\" -cDefault -bpwp_dgiw -btC:\mysql_backups\ -bxwp_dgiw

Depuis ces légères modifications, mes backups sont générés sans heurt.

Je cherchait un moyen de créer un nom de domaine fictif pour chacun des sites sur mon serveur local (ex. php_hacks.local). En plus de simplifier les URL de mes applications, cela m’éviterais d’avoir à modifier les chemins «Path» utilisés dans le code avant la mise en ligne des sites sur le serveur de production.
Après quelques recherches, j’ai découvert que la voie royale pour résoudre ce problème est de configurer des serveurs virtuels dans Apache. Ces derniers permettent entre autres de déterminer plusieurs noms de domaines pour un seul numéro ip, que ce soit celui un serveur live (ex. 65.182.100.136) ou un serveur de développement (ex. 127.0.0.1).

En résumé, voici les étapes à suivre :

1- Décommentez la ligne suivante dans le ficher http.conf :

Include conf/extra/httpd-vhosts.conf

Cette instruction permet de faire référence au fichier où seront définit vos serveurs virtuels. Sur windows, le fichier httpd.conf se trouve normalement dans C:\Program Files\Apache Group\Apache2\conf\httpd.conf. Avec Wamp 2.0, vous le trouverez dans C:\Program Files\wamp\bin\apache\apache2.2.6\conf\httpd.conf

2- Si l’endroit où se trouve le site est en dehors du dossier root par défaut du serveur Apache, vous devrez ajoutez une section semblable à celle-ci dans le fichier httpd-vhosts.conf :

<Directory G:/www/php_hacks >

Options Indexes FollowSymLinks

# AllowOverride controls what directives may be placed in .htaccess files.

# It can be “All”, “None”, or any combination of the keywords:

# Options FileInfo AuthConfig Limit

#

AllowOverride All

#

# Controls who can get stuff from this server.

#

Order allow,deny

Allow from all

Ce fichier se trouve dans C:\Program Files\Apache Group\Apache2\conf\extra\httpd-vhosts.conf. Avec Wamp 2.0, le fichier se trouve dans C:\Program Files\wamp\bin\apache\apache2.2.6\conf\extra\httpd-vhosts.conf.

3- Toujours dans httpd-vhosts.conf, vous devrez ajouter une section semblable pour chaque serveur virtuel :

<VirtualHost *:80>

DocumentRoot G:/www/php_hacks

ServerName php_hacks.local

DocumentRoot est le chemin où se trouve le dossier du site et ServerName, le nom de domaine par lequel vous voudrez y accéder. Il est aussi possible d’y définir plusieurs autres paramètres (ex, ServerAdmin, ServerAlias, ErrorLog, CustomLog, ect.). Pour une description complète de ces derniers, référez-vous à la Documentation sur les serveurs virtuels Apache.

4- Vous devrez ajouter vos nomd de domaine fictifd à votre fichier hosts. Les utilisateurs de Windows le trouvent généralement dans %SystemRoot%\system32\drivers\etc\

Voici un exemple du fichier hosts qu’on retrouve sous Windows. On peut éditer ce fichier à l’aide de Notepad. L’entrée 127.0.0.1 localhost s’y trouve généralement par défaut. Il est préférable d’ajouter chacune des entrées sur une nouvelle ligne. Une entrée est constituée d’un numéro ip suivit du nom de domaine associé. Le numéro ip doit être séparé du nom domaine par au moins 1 espace. Il doit aussi y avoir un retour de ligne après la dernière entrée du fichier hosts.

# Copyright © 1993-1999 Microsoft Corp.

#

# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.

#

# This file contains the mappings of IP addresses to host names. Each

# entry should be kept on an individual line. The IP address should

# be placed in the first column followed by the corresponding host name.

# The IP address and the host name should be separated by at least one

# space.

#

# Additionally, comments (such as these) may be inserted on individual

# lines or following the machine name denoted by a “#” symbol.

#

# For example:

#

# 102.54.94.97 rhino.acme.com # source server

# 38.25.63.10 x.acme.com # x client host

#

127.0.0.1 localhost

127.0.0.1 php_hacks.local

5- Finalement, dans une fenêtre de commande, testez votre nouveau serveur virtuel avec l’instruction ping php_hacks.local. Vous devriez obtenir le résultat suivant :

Envoi d’une requête ‘ping’ sur php_hacks.local [127.0.0.1] avec 32 octets de données :

Réponse de 127.0.0.1 : octets=32 temps<1ms TTL=128

Réponse de 127.0.0.1 : octets=32 temps<1ms TTL=128

Réponse de 127.0.0.1 : octets=32 temps<1ms TTL=128

Réponse de 127.0.0.1 : octets=32 temps<1ms TTL=128

Statistiques Ping pour 127.0.0.1:

Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%),

Durée approximative des boucles en millisecondes :

Minimum = 0ms, Maximum = 0ms, Moyenne = 0ms

Pistes pour la résolution de problèmes :

• ipconfig /flushdns
• Vérifier la syntaxe du fichier hosts
• Vérifier l’emplacement du fichier hosts
• Vérifier la variables DataBasePath dans la base de registre HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DataBasePath
• Suspendre le service DNS client
• Revoir la priorité des services dans la base de registre
• Assurez vous qu’il ne s’agit pas du vicieux bug dû à MSN Messenger. Dans la base de registre, sous \HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters changer le type de la clé “DataBasePath” de REG_SZ en REG_EXPAND_SZIl s’agit d’un bug de l’outil de dépannage de MSN Messenger qui réinitialise cette clé (mais avec un mauvais type) lorsqu’il n’arrive pas à se connecter.

Liens utiles :

• FAQ sur les fichier hosts
• Documentation sur les serveurs virtuels Apache