Le client: « Alors on voudrait un site e-commerce avec [... *utilisation de symfony envisagée*] et il faudrait aussi y intégrer un blog WordPress
- Obligatoirement WordPress?!
- Oui, oui »

En avant Guingamp, nous voilà parti à l’aventure!

Avant de commencer, quelques petites précisions

Dans ce tutoriel, les versions de symfony 1.2 et WordPress 2.7 sont utilisées. Afin de gérer à peu près au mieux la cohabitation, j’utilise deux bases de données. Enfin, la méthode utilisée est un peu sauvage au départ, et toujours autant à la fin! Le but recherché n’est pas de ré-écrire le frontend de WordPress, tout juste de le rendre présentable pour une intégration totalement fonctionnelle. Je vous invite bien évidemment à me faire part de vos expériences, doutes, angoisses, etc…

Enfin, ce tutoriel implique d’avoir un minimum de connaissances du framework symfony.

Intégration du core de WordPress dans symfony (par fabriceb sur theodo.fr)

Pour commencer, il vous faut installer WordPress n’importe où, nous verrons les détails plus tard. Une fois que vous avez finalisé l’installation, nous pouvons continuer. Sans rien toucher à la structure des fichiers, déplacez le dossier dans

plugins/sfWordpressPlugin/lib/vendor

Pour que ces fichiers soient accessibles, il nous faut créer un lien symbolique vers ce dossier:

ln -s plugins/sfWordpressPlugin/lib/vendor/wordpress web/blog

Il nous faut créer un module qui va nous servir de réceptacle pour tout ça. Nous l’appelerons sfWordpress. Et le routing qui va bien:

1
2
3

blog:
  url:   /blog/*
  param: { module: sfWordpress, action: index }

Bien sûr, il va nous falloir bricoler un peu pour que le contenu de la page soit renvoyé proprement puisque WordPress utilise I18N et fait ainsi conflit avec celui de symfony entre autre. Voici donc ce à quoi va ressembler notre action Index:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

< ?php
    /**
     * intégration de Wordpress
     *
     * @param sfWebRequest $request
     * @author fabriceb
     * @since Mar 4, 2009 fabriceb
     */
     public function executeIndex(sfWebRequest $request)
     {
       // Don't load symfony's I18N
       $standard_helpers = sfConfig::get('sf_standard_helpers');
       $standard_helpers = array_diff($standard_helpers, array('I18N'));
       sfConfig::set('sf_standard_helpers', $standard_helpers);
 
       define('WP_USE_THEMES', true);
       chdir( dirname(__FILE__) . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . '..' . DIRECTORY_SEPARATOR . 'lib' . DIRECTORY_SEPARATOR . 'vendor' . DIRECTORY_SEPARATOR . 'wordpress' );
       global $wpdb;
       ob_start();
       require_once( 'wp-blog-header.php' );
       $this-&gt;blog = ob_get_contents();
       if (function_exists('is_feed') &amp;&amp; is_feed())
       {
         ob_end_flush();
         throw new sfStopException();
       }
       else
       {
         ob_end_clean();
       }
     }

Nous nous retrouvons ainsi avec des problèmes de variables global. Pour remédier à ça, il va nous falloir éditer le fichier
plugins/sfWordpressPlugin/lib/vendor/wp-blog-header.php
pour qu’au final il ressemble à ca:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

< ?php
/**
 * Loads the WordPress environment and template.
 *
 * @package WordPress
 */
 
if ( !isset($wp_did_header) ) {
 
	$wp_did_header = true;
 
	require_once( dirname(__FILE__) . '/wp-load.php' );
 
    // Debut du hack 1/2
    $local_global_vars = get_defined_vars();
    foreach($local_global_vars as $local_name =&gt; $local_value)
    {
        $GLOBALS[$local_name] = $local_value;
    }
    // Don't create new global variables ourselves, and do not overwrite other global variables, for example $name...
    unset($local_name, $local_value, $local_global_vars);
    // @HACK FABRICE
 
    wp();
 
    // @HACK Fabrice
    global $posts;
    // @HACK Fabrice
 
	require_once( ABSPATH . WPINC . '/template-loader.php' );
 
}
 
?>

Nous y voilà presque, il ne nous manque plus qu'à nettoyer le code HTML pour enlever toutes les références aux fonctions

• get_header()
• get_sidebar()
• get_footer()

Vous pourrez les retrouver dans pratiquement tous les fichiers de votre thème, attention donc.

Enfin, il ne nous reste plus qu'à afficher le tout en ajoutant tout simplement dans notre indexSuccess.php le code suivant
< ?php echo html_entity_decode($blog, ENT_QUOTES) ?>
And voilà ! Nous voilà donc avec un affichage très sommaire de vos articles Wordpress. Toutefois, puisque nous avons supprimé les entêtes HTML de celui-ci, plus aucun CSS. Sans avoir testé cet aspect, on peut également affirmé que certains plugins pourraient ne pas être fonctionnels étant donné que les initialisations de certains d'entre eux sont effectués lors des appels aux différentes fonctions que nous avons fraichement supprimées. Toutefois cela peut-être suffisant, je pense, dans la majorité des demandes.

Un prochain billet tentera de remédier à ces différents problèmes si je ne trouve pas de meilleur solution d'ici là car, je le rappele, ceci est le résultat d'expérimentations... À bientôt donc...

PS: pour les Mac users, je viens de tomber sur quelque chose qui peut être sympa à mettre en place après avoir été adapté (je doute que beaucoup parmis vous utilisent les versions préinstallées d'Apache et de PHP sous OS X...): faire une copie locale de son blog WordPress grâce à Mac OS X