Développement sous TYPO3

TYPO3 6.0 Alpha 1 : petit aperçu

Publié le Mis à jour le

La première version alpha de TYPO3 6.0 est sortie le 23 mai 2012. La prochaine alpha est prévue pour le 26 juin.
Vous pouvez consulter la roadmap ici : http://forge.typo3.org/projects/typo3v4-core/roadmap

Comme vous le savez peut-être déjà, la version 4.7 sera la dernière version de la branche 4. La branche 5 n’existera pas, afin de faire table rase sur tout ce qui a été dit sur Phoenix.

On repart donc sur une v6 avec son lot de nouveautés décrites sur typo3.org.

J’ai installé « l’introduction package » mais j’ai rencontré assez rapidement un premier souci. Il est en fait lié à l’utilisation de tt_news, qui fait encore appel à la méthode readLLXMLfile, méthode marquée comme étant dépréciée depuis la version 4.6 de TYPO3. Elle n’existe plus dans la version 6 car remplacée par getParsedData().

Le deuxième souci est apparu lorsque j’ai voulu vérifier la mise à jour des extensions. L’option est manquante dans le gestionnaire d’extensions.

Ensuite, troisième souci, impossible d’enregistrer l’utilisation du français comme langue du backend. Pourtant, j’ai réussi à mettre mon nom puisqu’il apparait près du bouton de déconnexion, mais il n’apparait pas dans mes données personnelles.

Il y a forcément d’autres soucis… Je ne vais pas trop m’attarder, il s’agit d’une alpha !

Voici donc sans plus attendre, les nouveautés de cette version.

– amélioration de l’utilisabilité du backend. Selon Wikipedia, l’utilisabilité est « le degré selon lequel un produit peut-être utilisé […] pour atteindre des buts définis avec efficacité, efficience et satisfaction […].
Il reste encore pas mal de travail à accomplir, mais des petits changements sont apparus.

L’insertion d’éléments de contenu est plus explicite. On retrouve cette possibilité d’insérer des contenus dans les éléments spéciaux de l’assistant.
Modification de l’ordre de quelques icones, des éléments de contenus dans l’assistant. Ces changements sont mineurs.

– nettoyage du code… encore et encore. Le but consiste à éduquer un peu plus les développeurs à délivrer un code orienté davantage sur la qualité en proposant un modèle sur lequel s’appuyer.

Les modules de backend log (belog) et viewpage ont été migrés vers Extbase. Sachez que les modules about et aboutmodules ont été les premiers à connaitre cette migration avec TYPO3 4.7. Si vous souhaitez développer des modules backend, c’est un bon point de départ !

Une quantité importante de code déprécié a été supprimée. Il convient de tester ses extensions sous cette version alpha pour vérifier leur portabilité sur la prochaine version de TYPO3. tt_news ne fonctionne plus par exemple…

Le bootstrap qui permet d’initialiser TYPO3 a été retravaillé. Il y a plusieurs classes et méthodes, ce qui permettra une meilleure maintenance du code PHP.

Quelques remarques :

– La méthode de Xclass a été modifiée. Il faut ajouter une entrée avec ‘ux_’ en préfixe de la classe surchargée dans le fichier ext_autoload.php de votre extension. Voir ici pour plus d’informations et des exemples : http://wiki.typo3.org/Autoload

– Extbase et Fluid sont toujours chargées car utilisées dans des extensions système obligatoires

– Implémentation de FAL ou la couche d’abstraction de fichiers (File Abstraction Layer)

Les fichiers dans fileadmin peuvent être localisés dans un « nuage » ou « cloud ». Le cloud, c’est le stockage en ligne de fichiers. Ces fichiers sont généralement localisés sur une multitude de serveurs dispersés sur plusieurs continents. Quand vous naviguer sur un site internet, les fichiers sont délivrés depuis le serveur le plus proche de votre localisation pour accélerer l’affichage des pages. Vous connaissez certainement ces solutions : Dropbox, Box, Hubic, Ubuntuone… Il existe également des solutions plus professionnelles existent comme Amazon S3.

L’espace de stockage par défaut est fileadmin. Vous pouvez en ajouter d’autres. Il suffit de se rendre en mode LISTE sur la page id=0, tout en haut de l’arborescence.

Par couche, celà signifie aussi que la base de données joue un rôle tampon en permettant de stocker des informations sur les fichiers : permissions, utilisation d’un fichier sur telle ou telle page, … ce qui permettrait de diminuer les doublons car il n’y aurait plus qu’une seule référence pour chaque fichier. Des tâches planifiées sont également prévues pour le nettoyage automatique de vos instances TYPO3.

L’insertion d’images dans les éléments de contenu « images » ou « texte et image » est plus claire.

TYPO3 6.0 implique l’utilisation d’extensions compatibles et ne contenant pas de code déprécié. Bien que l’on soit en version alpha 1, il est temps de vous interroger sur les extensions que vous utiliserez à l’avenir et sur vos méthodes de développements. TYPO3 6.0 représente une nouvelle étape. Ca serait dommage de ne pas pouvoir l’utiliser au mieux de ses possibilités 😉

Publicités

L’Extension Builder se dote d’un manuel

Publié le

Ce soir, en procédant à un « git checkout » et un « git pull », je me suis aperçu qu’une documentation s’était ajoutée dans le répertoire de l’extension extension_builder/doc. Je rappelle que l’extension « Extension Builder » est le kickstarter pour Extbase.

On retrouve donc une documentation de 8 pages qui reprend les informations contenues sur le Wiki. Pas très important mais je souhaitais le signaler quand même 🙂 D’ailleurs, cette extension… vous l’utilisez ?

TYPO3 Fluid : le View Helper de traduction

Publié le Mis à jour le

Les aides de vue ou View Helpers sont des aides à l’affichage. Ces View Helpers sont situés dans typo3/sysext/fluid/Classes/ViewHelpers/.

Nous allons voir aujourd’hui l’aide de vue pour les traductions. Ce View Helper est situé ici : typo3/sysext/fluid/Classes/ViewHelpers/TranslateViewHelper.php

Pourquoi l’utiliser ?

Le view helper (ou aide de vue) de traduction dans Fluid évite de coder en dur les différents messages dans les gabarits HTML.
Lorsque l’on souhaite mettre à jour une traduction, il est plus simple de passer par un seul fichier XML contenant l’intégralité des traductions, plutôt que de retoucher les fichiers HTML. De plus, et c’est là le plus important, un fichier XML est obligatoire si votre site est en plusieurs langues.
Néanmoins, on peut affirmer que même si votre site n’est traduit qu’en une seule langue, on ne dois jamais se passer d’un fichier XML. Il suffit juste de déclarer la langue du site comme langue par défaut.

<languageKey index= »default » type= »array »> […] </languageKey>

Comment utiliser ce view helper ?

Avec tslib_pibase, on n’utilisait $this->pi_getLL(‘the.key’) où « the.key » est l’entrée correspondante dans le fichier locallang.xml.
Pour Fluid, la syntaxe du fichier XML est la même mais on le code différement dans le fichier HTML.

Tout d’abord, petit rappel sur l’emplacement du fichier html. Celui-ci doit se situer dans le répertoire Resources/Private/Templates de votre extension.
Ensuite, on le place dans un dossier portant le nom du contrôleur appelé en front office.

Pour reprendre l’extension MVC blog_example, les contrôleurs identifiés sont : blog et post. On a donc deux dossiers dans Resources/Private/Templates :
– Blog
– Post
(Notez la première lettre en majuscule… c’est une règle).
On a ensuite un fichier HTML pour chaque action, le nom du fichier portant le nom de l’action, toujours avec une lettre majuscule au début.

# Voici l’appel du view helper dans un template (fonctionne également dans un partiel) :
<f:translate key= »the.key » htmlEscape= »false » />

Ce view helper va aller cherche la traduction de la clé « the.key » dans le fichier locallang.xml, situé dans le dossier Resources/Private/Language/.

C’est un appel basique mais d’autres appels sont également possibles :

# Référence à un fichier : <f:translate key= »LLL:EXT:myext/Resources/Private/Language/locallang.xml:the.key » />
L’intérêt ici c’est que vous pouvez spécifier un autre fichier que celui appelé par défaut.

# Ajout d’un texte par défaut si la clé n’est pas trouvée : <f:translate key= »the.key » htmlEscape= »false » default= »Texte par défaut » />

# Autre notation et passage d’arguments :

Si on a le label suivant :
<label index= »the.key »>TYPO3 has a large and growing %s of users %s.</label>

%s et %s seront remplacés respectivement par community et worldwide, ‘default value’ est une valeur par défaut.

Vous pouvez bien évidemment utiliser des fonctions fournies par Fluid pour rendre dynamique les paramètres passés :

<f:translate key= »post.list » arguments= »{numberOfBosts: ‘{posts -> f:count()}’} »>

Ou encore (extension perso) :

<f:translate key= »tx_simplefaq_domain_model_category.selectedcat » arguments= »{0: ‘{singleCategory.title}’} » htmlEscape= »false » default= »Texte par défaut » />

Ci-dessus, on a fait appel à deux View Helpers :
– f:translate
– f:count

L’objet « posts » contient tous les posts retournés par le contrôleur avec les lignes suivantes :
$this->postRepository->findByBlog($blog);
$this->view->assign(‘posts’, $posts);

Au final : « This blog contains 5 posts »

Je vous encourage à inspecter les autres view helpers dans typo3/sysext/fluid/Classes/ViewHelpers/. Des exemples sont commentés dans le code PHP des classes 🙂

L’API de TYPO3 enfin rassemblée !

Publié le

Et oui, c’est pas trop tôt on va dire. Fini le temps où on allait sur typo3.org ou bien où l’on cherchait une extension qui proposait l’API à jour depuis le backend. Vous n’avez plus d’excuses désormais. Voilà le lien : api.typo3.org

Nous avons donc l’API de TYPO3, l’API de Fluid et l’API de la librairie Extbase, le fameux backport de FLOW3. La page d’accueil propose des liens directs vers les versions les plus récentes. Pour les archives, c’est http://api.typo3.org/archives

L’API est mise à jour automatiquement chaque nuit. Bref, en un seul mot : pratique

Extbase : documentation restructurée sur le wiki

Publié le Mis à jour le

Extbase va devenir de plus en plus importante dans la conception d’extensions TYPO3 (plugin frontend, module back office, …). Si vous n’avez pas commencé votre apprentissage, il est temps de s’y mettre. J’ai déjà commencé à le faire pour proposer des développement sous Extbase et Fluid à mes clients. A ce sujet, la documentation d’Extbase a été restructurée sur le Wiki : documentation Extbase sur Forge/Wiki.

On salue l’initiative mais comme vous le constaterez, quelques ressources restent en allemand, tout particulièrement le livre de Jochen Rau et de Sebastian Kurfürst.

Et vous ? Avez-vous commencé à apprendre Extbase ?

Edit : Lien vers l’API

loginNews : mieux communiquer avec vos contributeurs sous TYPO3

Publié le Mis à jour le

 Une fonctionnalité qui existe depuis un bon moment sous TYPO3 mais que j’ai découvert très récemment, est la possibilité d’afficher des messages "flash" sous la boite de connexion au back office de TYPO3 :

Sympathique, non ?

Comment procéder ? La solution est sur le blog de l’agence Marit AG. Si vous avez quelques difficultés à comprendre l’allemand, voici comment procéder !

Il y a deux solutions mais dans tous les cas, il faut passer par une extension maison, depuis le kickstarter par exemple. En effet, le code PHP doit être ajouté dans un fichier local ext_tables.php. Ensuite, deux méthodes s’offrent à vous :
– la méthode "cracra"
– la méthode plus propre

1. Méthode "cracra"

Elle est rapide mais ce n’est pas terrible car pas très dynamique car vous devez passer obligatoirement pas ext_tables.php pour rajouter ou modifier un message

$GLOBALS[‘TYPO3_CONF_VARS’][‘BE’][‘loginNews’][] = array(
    ‘date’ => ‘23.10.2010’,
    ‘header’ => ‘New feature available’,
    ‘content’ => ‘This is a description how you can use the feature’
);

$GLOBALS[‘TYPO3_CONF_VARS’][‘BE’][‘loginNews’][] = array(
    ‘date’ => ‘15.10.2010’,
    ‘header’ => ‘Cool news below login box’,
    ‘content’ => ‘This news are shown below the backend login box’
);

Voilà, vous rajoutez des entrées dans le tableau $GLOBALS[‘TYPO3_CONF_VARS’][‘BE’][‘loginNews’]. Vous l’aurez compris, je déconseille fortement cette méthode.

2. Méthode plus propre

Cette méthode consiste à se servir des atouts d’un CMS : passer par le back office pour faciliter la maintenance de vos messages. Vous pouvez créer une table news depuis le kickstarter et compléter les champs depuis le back office. Il suffit juste de 3 ou 4 champs : crdate, date, title et short. Sinon, et il est possible de s’appuyer sur l’exemple ci-dessous, utiliser tt_news !

Pour tt_news, il est conseillé de recréer un sysfolder spécifique et non visible par vos contributeur. Pour celà, modifier les droits de ce dossier avec la fonction "Accès" dans Web. Pas besoin de créer une catégorie supplémentaire.

Ensuite, dans le fichier ext_tables.php :

if(!t3lib_div::_GET(‘loginRefresh’)){
    if(t3lib_extMgm::isloaded(‘tt_news’)){
        require_once(PATH_t3lib.’class.t3lib_befunc.php’);
        $table = ‘tt_news’;
        $enableFields = t3lib_BEfunc::BEenableFields($table).t3lib_BEfunc::deleteClause($table);
        $pid = 251; // sysfolder news
        $limit = 20; // nombre max de news

        $res = $GLOBALS[‘TYPO3_DB’]->exec_SELECTquery(‘*’, $table, ‘pid = ‘.intval($pid).’ ‘.$enableFields,  », ‘crdate DESC’, intval($limit));

        while($row = $GLOBALS[‘TYPO3_DB’]->sql_fetch_assoc($res)){
            $GLOBALS[‘TYPO3_CONF_VARS’][‘BE’][‘loginNews’][] = array(
                ‘date’ => strftime(‘%e. %B %Y’, $row[‘datetime’]),
                ‘header’ => $row[‘title’],
                ‘content’ => nl2br($row[‘short’])
            );
        }
    }
}

La variable $pid est l’id du dossier qui stocke vos message en back office tandis que $limit, limite le nombre de messages à afficher.
Si un message doit être effacé, il suffit de la cacher ou de le supprimer tout simplément !

Direct_mail : personnaliser les salutations

Publié le

Personnaliser les salutations en fonction du sexe (colonne fe_users.gender) n’est pas possible à priori dans Direct_mail. Heureusement, un hook existe ! Oui, je n’ai pas fait durer le suspens bien longtemps, mais je vais vous donner la solution car c’est très pratique. Pour ma part, j’utilise M/Melle/Mme soit 1, 2 ou 3 pour la valeur de mon champ gender dans la table fe_users. L’exemple que je vais vous donner utilise soit m, soit f, c’est à dire masculin/féminin.

Vous devez créer une extension (ex : directmail_personalization) depuis le kickstarter mais sans étendre aucune table. Il s’agit juste de disposer des fichiers nécessaires pour faire fonctionner l’extension.

Dans le fichier localconf.php, vous allez indiquer la ligne suivante :

$hooks = array(‘EXT:directmail_personalization/hooks/class.tx_directmail_personalization.php:tx_directmail_personalization->mailMarkersHook’);

$GLOBALS[‘TYPO3_CONF_VARS’][‘SC_OPTIONS’][‘ext/direct_mail’][‘res/scripts/class.dmailer.php’][‘mailMarkersHook’] = $hooks;

Ajoutez ensuite une fonction mailMarkersHook dans votre classe tx_directmail_personalization, fichier class.tx_directmail_personalization.php.

Perso, j’ai l’habitude de mettre mes hooks dans un dossier particulier mais comme il s’agit ici d’une extension dédiée, pas besoin de sous-répertoire.

Vous pouvez voir l’intégralité de la solution ici : http://www.typo3.net/forum/list/list_post//90796/

Il ne reste plus qu’à personnaliser la fonction et à rajouter le marqueur ###USER_salutation### dans votre gabarit.

A titre d’information, une extension fait à peu près la même chose. Il s’agit de ods_dm_salutation.