Poster sur Wordpress depuis une Application Java

Pour poster sur WordPress, tout le monde sait que l’on peut le faire en passant par le panneau d’administration de son blog. Vous connaissez peut-être aussi des programmes qui vous permettent de poster directement sur votre blog, sans avoir à lancer votre navigateur web. Une liste de tels programmes est disponbile sur le site de WordPress.

En fait, ces applications peuvent publier des billets et interagir avec votre blog grâce à un script particulier, intégré aux blogs WordPress. Ce script PHP s’appelle xmlrpc.php et permet de communiquer via HTTP en échangeant des structures JSON. Autrement dit, pour qu’une de vos applications puisse interagir avec votre blog, il suffit qu’elle communique avec ce fameux script.

Dans le cas d’une application Java, plusieurs options sont possibles.
Personnellement, je n’avais pas envie de me prendre la tête pour décortiquer toutes les structures de données de l’API WordPress. Je me suis donc tourné vers une librairie Java qui fournit une API propre (et à peu près claire). Cette librairie, c’est WordPress-Java.

Il y a quelques exemples disponibles sur le site.
Je me permets ici d’en rajouter un de ma composition.

import java.net.MalformedURLException;

import net.bican.wordpress.Page;
import net.bican.wordpress.Wordpress;
import redstone.xmlrpc.XmlRpcArray;
import redstone.xmlrpc.XmlRpcFault;

/**
 * @author Vincent Zurczak
 */
public class WordPressDemo {	
	
	/**
	 * Publishes the given posts on the blog. 
	 */
	public static void publishOnBlog() {

		String username = "mon-nom-d'utilisateur";
		String pwd = "mon-mot-de-passe";
		String xmlRpcUrl = "http://mon-adresse-de-blog/xmlrpc.php";

		try {
			Page newPost = new Page();

			newPost.setTitle( "Le titre de mon post" );
			newPost.setExcerpt( "Un résumé de mon billet" );
			newPost.setMt_keywords( "mot clé 1, mot clé 2" ); // Tags
			newPost.setMt_allow_comments( 1 ); // Allow comments
			newPost.setMt_allow_pings( 0 ); // No ping
			newPost.setDescription( "Le contenu de mon post, avec des liens, etc." );

			XmlRpcArray cats = new XmlRpcArray();
			cats.add( "Technique" );
			newPost.setCategories( cats ); // Post categories

			Wordpress wp = new WordPress( username, pwd, xmlRpcUrl );
			wp.newPost( newPost, true );

		} catch( MalformedURLException e ) {
			e.printStackTrace();

		} catch( XmlRpcFault e ) {
			e.printStackTrace();
		}
	}
}

Après, vous pouvez faire des trucs plus avancés.
Mais les tags, les catégories et les éléments utilisés ici sont les plus courants.

Publicités

Wordpress en-dehors de Wordpress et les erreurs 404

Côté technique

WordPress, c’est pas mal du tout.
Mais des fois, on se doit de le faire cohabiter avec d’autres sites, que ce soit avec des pages écrites à la main ou bien d’autres plateformes web.

Pour pouvoir utiliser les fonctions WordPress en-dehors de WordPress, dans un autre script PHP, il est généralement conseillé d’y intégrer le script wp-blog-header.php. Et ça marche. Du moins, en apparence. En fait, selon le programme avec lequel on va accéder à cette page, le comportement va varier. En analysant les logs du serveur (prenons ici Apache), on se rend vite compte que si cette page est bien envoyée en réponse, le code HTTP associé est en fait un code 404 (page introuvable).

127.0.0.1 – – [19/Apr/2011:00:31:31 +0200] « GET /galerie/ HTTP/1.1 » 404 29682

Cela pose un problème car certains programmes risquent de s’arrêter à l’analyse de ce code.

Pourquoi ce comportement ? Et bien parce que le script wp-blog-header.php analyse la requête et détermine si un billet ou une page correspond à cette requête. S’il n’y a rien, il envoie un header 404. A la suite de quoi, le reste de la page PHP est traité. Si par chance, la page a déjà envoyé des headers avant d’intégrer ce script WordPress, cette situation aura été évitée. Mais elle aboutira peut-être à un message indiquant que les entêtes HTTP ont déjà été envoyés.

La solution pour éviter ce problème, c’est de bannir wp-blog-header.php et d’inclure à la place le script wp-load.php.
Et là, ça marche pour de bon.

127.0.0.1 – – [19/Apr/2011:00:33:56 +0200] « GET /galerie/ HTTP/1.1 » 200 29682

Et pour la petite histoire…

J’ai découvert ce problème suite à plusieurs étrangetés sur mon site :

  • Les outils de Google pour les webmasters m’avaient indiqué à plusieurs reprises des erreurs 404 dans l’exploration de mon site, alors même que ces pages s’affichaient très bien dans Firefox.
  • En fait, le déclic a été un script PHP que j’invoquais depuis un programme Java. Celui-ci ne s’exécutait pas du tout.
  • Partant de ça, j’avais pu vérifier que ce script ne s’exécutait que dans Firefox. Mais pas dans Google Chrome, ni dans Internet Explorer 8.
  • Enfin, le validateur du W3C m’a signalé la même chose (erreur 404). Au final, les logs Apache ont confirmé l’évidence.

Et c’est donc bien Firefox qui a été un peu trop cool dans cette affaire.
J’ai passé 3 heures à éliminer des explications (réécriture d’URL bancale, mauvaise inclusion dans les scripts PHP, script foireux…) avant de n’avoir plus qu’une seule explication encore cohérente. Et je vous ai mis la solution plus haut…