Le blog de llaumgui - IPBSDK

Scénario-PaintBall version 3 en préparation

llaumgui — Thu, 30 Aug 2007 23:05:00 +0200

Après plusieurs années de bons et loyaux services, il est grand temps que la version 2 de Scénario-PaintBall tire sa révérence, pour donner naissance à une v3 ;-).
Pourquoi ?

Le forums : L'une des raisons principales et la version d'IPB, la 2.1.x. Cette dernière n'est plus ou ne sera bientôt plus supportée. Il est donc grand temps de passer à la branche 2.3.x.
Les autre points découlent de cette mise à jour.
Le portail : Il utilise l'ipbSDK qui n'est plus développé depuis la version 2.1 d'IPB (déjà que la 1.6 beta 5 pour IPB 2.1 était « limite »). Si je veux récupérer mon portail il faut donc que je rende compatible la dernier version du sdk avec la version actuel du forum... Or, j'ai la flemme de récupérer du vieux code !
Le design : le passage vers IPB 2.3 oblige à refaire la feuille de style (si on veut pas faire le porc). A remonter une page, autant en remonter une nouvelle.

Des pistes pour l'évolution

Pour la partie graphique, Radinus est en train de voir avec un designer.
Pour la techno, je pense utiliser eZ Publish 4.0 qui ne devrait plus tarder à sortir en version alpha voir peut être même bêta... Je rappel que la version du sdk utilisée actuellement est une bêta 2 ultra modifiée par moi même, donc on est plus à une bêta près.
En attendant la v4 d'eZ, je commence les tests sur la version 3.9 communautaire compatible php5.

Du coup, en utilisant IPB + eZ publish, je n'ai plus qu'une seule chose à développer : une extension eZ pour communiquer avec IPB (connections membres + requêtes de récupération d'informations diverses).

Des non pistes

Pourquoi pas le module forums pour eZ ?

La licence IPB est payée à vie et c'est un excellent forums ultra (trop?) complet.

Pourquoi pas un CMS autour d'IPB ?

Je pense qu'un forum est un forum et qu'un CMS est un CMS ! Vouloir absolument développer un CMS autour d'un forum est, selon moi, une erreur. Erreur que j'ai d'ailleurs commise lors de la v2 de spb ;-).
La solution est donc de coupler différents scripts via des bridges (ma future extension ou les bridges à la Coppermine) ou grâce à des systèmes du type SSO (pour SPB on en est pas encore là).

TODO

Installer Eclipse Europa (3.3) avec les extensions qui vont bien (pdt, Smile eZ plugin). Je commence de loin, mais installer & configurer Eclipse c'est presque aussi long qu'installer un système complet.
~~Configurer mon serveur apache local~~.
~~Installer eZ 3.9 php5~~.
~~Convertir la base IPB 2.1.x vers 2.3.1~~.
Développer le plugins eZipb pour faire communiquer IPB et eZ publish (voir les différentes pistes offertes et voir aussi du côté de Converge).
Découper le design (que j'attends toujours).
Développer, dans la version eZ, les différentes fonctionnalités actuellement disponibles sur spb.
Migrer le forums en UTF-8.
etc...

Liste de mes mods IPB

llaumgui — Wed, 28 Sep 2005 18:43:00 +0000

Je commence à me faire une petite collection de mods persos pour IPB. Ce billet servira à tous les lister et savoir où les trouver.

IPB 1.3.x :
- RSS IPB News 1.6 (Chez Invisionize), (médaille du meilleur mod catégorie "Mid-scale" Juin 2005) : Ce mod vous permet d'exporter vos news issues de votre forum IPB au format RSS.
IPB 2.0.x :
- RSS IPB News 1.6 (Chez Invisionize): Ce mod vous permet d'exporter vos news issues de votre forum IPB au format RSS.
- [Task] goTrash 1.0 (Chez Invisionize): (médaille du meilleur mod catégorie "Mid-scale" Septembre 2005) Certaines multi-modération peuvent ajouter un préfixe dans le titre du topic. Par exemple, sur mon site, j'utilise le préfixe [Périssable] pour signaler que le topic rejoindra bientôt la corbeille. Cette task automatise juste ce déplacement dans la corbeille...
IPB 2.x :
- [SDK] Tchat Xpress (Chez Invisionize) : ShoutBox basée sur le SDK 1.5 pour IPB 2.x. Il faut donc l'avoir préalablement installé pour utiliser le Tchat XPress.
- Show Queued : Ce mod est un auto-module : donc pas de fichier d'IPB à modifier smile.gif. Il sert a afficher la liste des topics demandant un travail de modération (Posts invisibles ou sujets non approuvés).
IPB 2.1.x :
- [Task] goTrash 1.1 : Certaines multi-modération peuvent ajouter un préfixe dans le titre du topic. Par exemple, sur mon site, j'utilise le préfixe [Périssable] pour signaler que le topic rejoindra bientôt la corbeille. Cette task automatise juste ce déplacement dans la corbeille...
IPB 2.1.x (En cours de développement, mais disponible en pré-version):
- imode and Wap for IPB 1.1 : Une version iMode de votre site.
- JS export news 1.0 : Exporter vos news au format JavaScript.

Mon profil sur IPBR-Fr.
Mon profil sur Invisionize.

Mis à jour le 28/09/05

IPBSDK et la (mauvaise) gestion des attachements

llaumgui — Fri, 23 Sep 2005 15:51:00 +0000

Plus j'avance dans le débugage du IPBSDK et le développement de mon portail, plus je me rends compte qu'il n'y a pas de cohésion entre les différentes fonctions qui compose ce SKD. En effet, prenons l'exemple de la gestion des attachements qui fait 1 requête par attachement alors qu'il est si simple d'utiliser une fonction récupérant tout les attachements d'un message... Le pire est que cette fonction existe ! Mais les 2 ne sont pas reliées. Rassurez vous, je vous livre mon code à rajouter dans la classe MySDK.

/**

     * Get a post's attachments

     * Gestion d'une mise en cache.

     * @author Guillaume Kulakowski <guillaume_AT_llaumgui_DOT_com>

     * @author Pita <peter@randomnity.com>

     * @since 1.11

     * @param integer $postid The post id to check

     * @param boolean $override Whether to override permissions or not.

     * @return array Post's attachments

     */

     function get_post_attachments($postid,$override=FALSE) {



        $query = "";

        if($override == FALSE)

            { $query = " AND attach_approved=1"; }

            

        $this->DB->query(    "    SELECT *

                                        FROM ibf_attachments

                                        WHERE attach_pid='".$postid."'".$query);

        

        if( $this->DB->get_num_rows() == 0 )

            { return FALSE; }



        while ( $row = $this->DB->fetch_row() )

            { $return[] = $row; }

        

        $this->_cache['post_attachments'.$postid] = $return;

    }









    /**

     * Get HTML code for outputting an attachment image.

     * Utilisation d'un cache.

     * @author Guillaume Kulakowski <guillaume_AT_llaumgui_DOT_com>

     * @since 1.11

     * @param integer $postid The post id to check

     * @param integer $id The attachment id to be parsed.

     * @param boolean $override Whether to override permissions or not.

     * @return string HTML code

     * @see attachment_info(), attachment_thumb()

     */

    function attachment_image( $pid, $id,$override=FALSE ) {

        

        /*

         * On récupère tous les attachements du poste :

         */

        if ( empty($this->_cache['post_attachments'.$pid]) )

            {

                $this->get_post_attachments($pid);

                // Ancien sysèmeme, au cas où :

                if ( empty($this->_cache['post_attachments'.$pid]) )

                    {

                        $att = $this->attachment_info($id,$override);

                        if($att['attach_is_image'] == 0)

                            { return FALSE; }

                    }

            }

        else

            {

                foreach( $this->_cache['post_attachments'.$pid] as $key => $value )

                    {

                        if ( $value['attach_id'] == $id )

                            { $att = $value; }

                    }

            }

        

        /*

         * Gestion des miniatures :

         */

        if ( empty($att['attach_thumb_location']) )

            { $out = '<img src="'.$this->board_url.'/uploads/'.$att['attach_location'].'" alt="'.$att['attach_file'].'" />'; }

        else

            { $out = '<a href="'.$this->board_url.'/index.php?act=Attach&type=post&amp;id='.$att['attach_id'].'" target="_blank"><img src="'.$this->board_url.'/uploads/'.$att['attach_thumb_location'].'" class="attach" alt="'.$att['attach_file'].'" /></a>'; }

        return $out;

    }

?>

Messages et sujets sous modération (queued)

llaumgui — Thu, 30 Jun 2005 12:00:00 +0000

Lors de l'un de mes rares passages sur l'index de mes forums (XPerience-Fr), je me suis rendu compte d'un message en attente de modération (état invisible) depuis plus d'une semaine. La constatation est simple, un portail et la fonction "Voir les nouveaux messages" fait que nous ne passons presque plus sur l'index des forums.

Après une discutions chez les copain d'IPBR-Fr, la solution la plus simple me parait d'afficher un message dans la boite membre comme cela :

Pour cela j'utilise une fonction dans la classe MySDK (Petit rappel) que je vous livre :

**

* Retourne le nombre de message et de topics en attente de validation.

* @author Guillaume Kulakowski <guillaume_AT_llaumgui_DOT_com>

* @return array topics et posts en attente de validation

*/

function get_queued() {



if ( !empty($GLOBALS['ibforums']->cache['forum_cache']) && is_array($GLOBALS['ibforums']->cache['forum_cache']) )

  {

   $queued_topics  = 0;

   $queued_posts = 0;

   foreach ($GLOBALS['ibforums']->cache['forum_cache'] as $id => $value )

    {

     $queued_topics  += $value['queued_topics'];

     $queued_posts  += $value['queued_posts'];

    }

   return array($queued_topics, $queued_posts);

  }

else

  { return false; }

}

Cette nouvelle fonction gère le retour d'information, il suffit alors de modifier la fonction d'affichage. Le nouveau message affiché renvoi vers la liste des messages sous modérations, pour cela, j'utilise l'auto-module "Show queued" bientôt disponible chez IPBR-Fr.

Petit rappel sur ce qu'est un auto-module: C'est un mod pour IPB ne nécessitant aucune modification de fichier et utilisant le lanceur auto-module d'IPB.

IPB-SDK, les guests et le cache

llaumgui — Tue, 31 May 2005 19:44:00 +0000

Ayant recodé le système de débug pour mon site, j'ai analysé les requêtes MySQL. J'ai effectué l'analyse logué en membre et délogué comme simple invité. La logique voudrait qu'un membre demande plus de requête du fait qu'il interroge sa boite de message privé, récupère ses infos, etc. Hors sous IPB-SDK c'est l'inverse.

Le listing des requêtes faite ressortir une requête identique qui se répète plusieurs fois (5 fois dans mon cas) :

SELECT m.*, me.signature, me.avatar_size, me.avatar_location, me.avatar_type, me.vdirs,

me.location, me.msnname, me.interests, me.yahoo, me.website, me.aim_name, me.icq_number,

g.*, cf.*

FROM ibf_members m

LEFT JOIN ibf_groups g ON (m.mgroup=g.g_id)

LEFT JOIN ibf_pfields_content cf ON (cf.member_id=m.id)

LEFT JOIN ibf_member_extra me ON (me.id=m.id)

WHERE m.id='0'

Le constat est rapide. Il n'y a pas de membre à l'id = 0. La requête retourne rien donc alimente le cache avec rien. De ce fait une interrogation du cache ne retourne rien et ré-effectue la requête. La fonction concernée par ce problème et la fonction get_advinfo() que j'ai redéfinie pour qu'elle tienne compte des invités.

/**

* Grabs detailed information on a member.

* Modification : Gestion des guest.

* @author Guillaume Kulakowski <guillaume_AT_llaumgui_DOT_com>

* @author Pita (conversion to 2.0) <peter@randomnity.com>

* @author Cow <khlo@global-centre.com>

* @param integer $memberid

* @return array Member Information, or FALSE on failure

* @see get_info(),get_avatar(),get_raw_sig(),get_photo(),get_member_pips(),get_member_icon(),get_num_new_posts(),get_skin_id()

*/

function get_advinfo($memberid = '') {



if (!$memberid)

  { $memberid = $GLOBALS['ibforums']->member['id']; }



// Gestion des guests non présentes de base ! :

if ( empty($memberid) || $memberid == 0 )

  { return false; }

else if ($cache = $this->get_cache('get_advinfo', $memberid))

  { return $cache; }

else

  {

   $this->DB->query ("SELECT m.*, me.signature, me.avatar_size, me.avatar_location, me.avatar_type, me.vdirs,

me.location, me.msnname, me.interests, me.yahoo,

me.website, me.aim_name, me.icq_number,

g.*, cf.*

FROM ibf_members m

LEFT JOIN ibf_groups g ON (m.mgroup=g.g_id)

LEFT JOIN ibf_pfields_content cf ON (cf.member_id=m.id)

LEFT JOIN ibf_member_extra me ON (me.id=m.id)

WHERE m.id='" . intval($memberid) . "'");

   if ($this->DB->get_num_rows())

    {

     $info = $this->DB->fetch_row();

     $this->save_cache('get_advinfo', $memberid, $info);

    return $info;

    }

   else

    { return FALSE; }

  }

}

Dans le cas d'XPerience-Fr, cette fonction étant utilisée plusieurs fois, j'économise ainsi 5 requêtes MySQL sur la page d'accueil. Vous pouvez en gagner plus ou moins selon votre code.

Cache ipbSDK vs cache IPB

llaumgui — Sat, 28 May 2005 11:19:00 +0000

Afin d'afficher 2 blocs d'informations supplémentaires sur ma page d'accueil, je me suis mis à étudier les requêtes MySQL engendrées par le ipbSDK afin d'en réduire leur nombre et de pouvoir en mettre 2 de plus pour mes 2 blocs :). Et la surprise :

SELECT * FROM ibf_cache_store WHERE cs_key IN ( 'banfilters', 'settings', 'group_cache', 'systemvars', 'skin_id_cache', 'forum_cache', 'moderators', 'stats', 'languages' )

SELECT cs_value FROM ibf_cache_store WHERE cs_key = "stats"

A quoi sert de charger les informations issue du cache IPB (1ère requête), si la fonction get_board_stats() ne les utilise pas ???!!! La réponse est malheureusement simple, le cache ipbSDK ($this->_CACHE) et celui d'IPB ($GLOBALS'ibforums'->cache) sont différents... J'ai d'abord pensé charger le cache IPB dans celui du SDK:

$this->_cache = $GLOBALS['ibforums']->cache

Mais quel intêret de 2 cache identique ? Et de plus je trouvais que leur vocations étaient différentes car le cache du SDK pouvais contenir des informations sur le membres et non pas uniquement sur le forum... J'ai donc modifié la fonction get_board_stats() pour qu'elle interroge non pas le cache ipbSDK mais celui d'IPB. Bilan, 1 requêtes de gagnée !!!

/**

* Obtenir les statistiques de mon forums.

* Modification : Liaison avec le cache IPB au lieu de celui du SDK.

* @author Guillaume Kulakowski <guillaume_AT_llaumgui_DOT_com>

* @author Pita (conversion to 2.0) <peter_AT_randomnity.com>

* @author Cow <khlo_AT_global-centre.com>

* @return array Board Statistics

*/

function get_board_stats() {

    // 1 : Je cherche dans le cache IPB :

    if ( !empty($GLOBALS['ibforums']->cache['stats']) && is_array($GLOBALS['ibforums']->cache['stats']) )

        { return $GLOBALS['ibforums']->cache['stats']; }        

    else

        {

            $this->DB->query ('SELECT cs_value FROM ibf_cache_store WHERE cs_key = "stats"');

            $row                                     = $this->DB->fetch_row();

            $stats                                    = unserialize(stripslashes($row['cs_value']));

            $GLOBALS['ibforums']->cache['stats']     =  $stats;

            return $stats;

        }

}

A noter que la modification utilise ma classe MySQL et que je n'ai pas modifié la fonction du SDK mais que je l'ai redéfinie.

Héritage du ipbSDK - Part3 (De nouvelles variables)

llaumgui — Fri, 18 Mar 2005 22:28:00 +0000

Dans vos fonctions utilisant le ipbSDK (Ou MySDK dans notre cas), il peut être fort pratique d'utiliser des variables du style $SDK->portal_url. Pour cela, rien de plus simple, surtout si vous avez suivis les 2 premières parties.

La première étape et d'ajouter la variable et ça valeur dans le fichier de configuration du SDK : ipbsdk_conf.inc.php.

Ensuite, vous devez déclarer la variable dans votre classe SDK et charger ça valeur dans le constructeur.

<?

/**

*------------------------------------------------------------------------

*   Portail XPerience 4.01.

* ========================================

* @package XPerience-Fr

* @copyright Guillaume Kulakowski

*/



require_once 'ipbsdk_class.inc.php';



/**

* Classe MySDK héritant du IPBSDK et permettant de l'optimiser sans patir de la difficulté

* de future maj.

* @package IPBSDK

*/

class MySDK extends IPBSDK {

    

    var $portal_url;

    

    

    /**

     * Constructeur de la sous-classe MySDK.

       * @param array $options Use this to overwrite settings from the configuration file.

     * @todo Virer le require_once

     * @since 4.01

     */

     function MySDK ( $options = array('root_path' => '', 'board_url' => '', 'sdklang' => '', 'board_version' =>'', 'allow_caching'=>'', 'timer'=>'', 'debug'=>'') ) {

         

        require_once 'ipbsdk_conf.inc.php';

        

        $IPBSDK = IPBSDK::IPBSDK($options);                // On passe les argument au super.constructeur.

        

        // Je charge mes variables :

        $this->portal_url            = $portal_url;

     }

}

?>

Poursuivre :

Héritage du ipbSDK - Part1 (La théorie).
Héritage du ipbSDK - Part2 (Premier pas).
Héritage du ipbSDK - Part3 (De nouvelles variables).

Héritage du ipbSDK - Part2 (Premier pas)

llaumgui — Thu, 03 Mar 2005 19:52:00 +0000

Ma précédente aventure m'a permise de me familiariser avec le concept d'héritage sous php. L'aventure MySDK (Nom de ma classe héritant de IPBSDK) peut donc commencer.

La première étape est de construire une classe MySDK (mysdk.php) héritant du IPBSDK. Pour commencer cette classe sera vide, donc héritant de la totalité des fonctions du SDK.

require_once 'ipbsdk_class.inc.php';



class MySDK extends IPBSDK {

    

    

}

Cela fait, il suffit de modifier notre script php et remplacer :

require_once 'ipbsdk_class.inc.php';

$SDK =& new IPBSDK(array("timer" => "1")); // Load with Timer

Par :

require_once 'mysdk.php';

$SDK =& new MySDK(array("timer" => "1")); // Load with Timer

Voila, vous n'utilisez plus IPBSDK, mais une classe héritant du IPBSDK que vous pouvez faire évoluer à part en rajoutant des fonction ou en redéfinissant. Nous aborderons l'optimisation du SDK dans un prochain billet

Poursuivre :

Héritage du ipbSDK - Part1 (La théorie).
Héritage du ipbSDK - Part2 (Premier pas).
Héritage du ipbSDK - Part3 (De nouvelles variables).

Héritage du ipbSDK - Part1 (La théorie)

llaumgui — Sat, 26 Feb 2005 17:50:00 +0000

Le portail que j'ai développé pour XPerience-Fr et que j'utilise aussi sur Meta-Contact est développé en utilisant l'API IPB-SDK. Cependant ayant modifié voir réécris un grand nombre de fonctions, les mise à jour du SDK sont très laborieuses... C'est là que la gestion de l'objet et de l'héritage sous php (Et surtout sous php5) prend tout son sens.

Tout d'abords, ce billet fait suite à mon constat de la puissance de php5 et se base plus sur mes connaissances/compétences en Java mais je suis presque sûr que cela doit être applicable sans problème au php5 (voir php4), c'est d'ailleurs ce qui va m'occuper ces prochains jours.

L'idée est de ne plus instancier le ipbSDK ( $SDK =& new IPBSDK( array("timer" => "1") ); ) mais une classe héritant du SDK que nous appèlerons MySDK.

Cette classe faisant appel aux fonctions du SDK (Principe de l'héritage), mais utilisant la redéfinition de fonction (Action de redéfinir un fonction d'une sous-classe dans une sur-classe) au lieu de modifier directement le SDK. De ce fait on se retrouverait avec un SDK de base mais utilisant les fonctions réécrites. De là, les mises à jour s'en retrouveraient facilitées car elles correspondraient juste a un upload du nouvel SDK et à quelques corrections de la classe MySDK.

Me reste plus qu'à passer de la théorie à la pratique :-).

Poursuivre :

Héritage du ipbSDK - Part1 (La théorie).
Héritage du ipbSDK - Part2 (Premier pas).
Héritage du ipbSDK - Part3 (De nouvelles variables).