De nombreux utilisateurs de Wordpress éprouvent des difficultés à programmer la publication automatique de leurs articles. Cette fonctionnalités peut s’avérer pratique dans les cas où on veut préparer des articles à l’avance qui seront publiés automatiquement à des dates prédéterminées (avant un départ en vacances par exemple).
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 !
Dans la plate-forme ASP.Net, un des moyens les plus efficaces pour améliorer la performance de vos applications Web est la mise en cache. Plusieurs méthodes sont proposées, mais la technique la plus simple consiste à ajouter une directive de mise en cache juste sous les directives de page.
<%@ 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.
À moins d’être resté caché sous une pierre ces dernières années, la plupart des développeurs Web auront entendu parlé de Firebug, l’extension pour Mozilla Firefox qui permet de déboguer, éditer et modifier le HTML, le CSS et le JavaScript d’une page web. Je l’utilise surtout pour déboguer mon JavaScript et parfois pour cibler des anomalies causées par mes règles CSS (à la condition qu’elle soient visibles dans Firefox !).
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.
Dernièrement, je me suis créé en environnement de développement PHP avec Eclipse et le plugin PDT (PHP Developpement Tools) ainsi que WAMP 2.0 (Apache MySQL et PHP sur windows).
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 :
