eID signifie extension ID. Il s'agit de scripts, au sein de TYPO3, qui sont chargés de recevoir des données en POST ou en GET et d'effectuer certains traitements puis de retourner éventuellement une réponse. Ces scripts ont des fonctionnalités assez basiques car le framework TYPO3 n'est pas chargé, contrairement à un plugin frontend avec tslib_pibase. Par conséquent, ils sont plus légers, les traitements sont plus rapides et permettent tout de même d'accéder à la base de données ou à d'autres services dans TYPO3 et à quelques constantes.

Vous vous doutez donc que l'on peut parfaitement utiliser ce genre de solution pour de l'Ajax. On pourrait par exemple mettre en place sur un serveur un mécanisme d'autocomplétion pour un moteur de recherche, une validation de formulaire en fonction d'un nom d'utilisateur si ce dernier existe déjà par exemple en base. Si l'on résume ce que nous venons de dire, il s'agit de valider des informations qui ne sont pas disponibles coté client, donc, coté serveur.

Comment repérer ce genre de script dans TYPO3 ? Comment ça marche ?

Un script doit être appelé depuis une page ou bien depuis un fichier javascript. En admettant que nous souhaitions passer des paramètres par l'URL, par exemple un mot clé ou un nom d'utilisateur, il faudrait appeler le script de la manière suivante :

www.monsite.fr?eID=nom_extension&parameterx=123&parametery=456

Ce que l'on peut dire, c'est que la principale difficulté consiste à inclure les classes adéquates de l'API et de n'utiliser ce genre de script que partiellement et ce, pour conserver de la souplesse et de la rapidité dans les traitements.

Pour déclarer un nouveau script, il faut évidemment créer une extension. A la base de celle-ci, vous devez ensuite créer une classe.

Par exemple, prenons le cas suivant :

Mon extension s'appelle "testextension". Placez un fichier à la racine. Ici, il s'appellera class.tx_testextension_eid.php et son chemin complet est typo3conf/ext/testextension/class.tx_testextension_eid.php. Je suppose que vous avez déjà utilisé le kickstarter pour développer vos extensions.

Dans le fichier ext_localconf.php, ajoutez la ligne suivante :

$GLOBALS['TYPO3_CONF_VARS']['FE']['eID_include'][$_EXTKEY]
    = 'EXT:' . $_EXTKEY . '/class.tx_testextension_eid.php';

Ensuite, voici le contenu de votre fichier class.tx_testextension_eid.php. Je l'ai volontairement raccourci le code mais sachez que vous pouvez utiliser $GLOBALS['TYPO3_DB']->exec_SELECTquery pour effectuer vos requêtes.

<?php

// Inclusion des librairies nécessaires
require_once(PATH_t3lib . 'class.t3lib_befunc.php');
require_once(PATH_t3lib . 'stddb/tables.php');
require_once(t3lib_extMgm::extPath('cms', 'ext_tables.php'));

class tx_testextension_eID {

    /* Méthode principale */
    function main() {

        // Connexion à la base de données
        tslib_eidtools::connectDB();

        // Récupération de mes paramètres passés depuis l'URL
        $parameterx = trim(t3lib_div::_GP('parameterx'));
   
        // ...

        $res = $GLOBALS['TYPO3_DB']->exec_SELECTquery(
            $select,
            $from,
            $where,
            $groupBy,
            $orderBy,
            $limit
        );

        if($res) {
            while (false !== ($ar =
                $GLOBALS['TYPO3_DB']->sql_fetch_assoc($res))) {


        // ....
        // ....
            }
        }


    // Resultat à traiter
    // Peut être interprété par une librairie JS
    return $result;

    }
    // End main() function

}

if (defined('TYPO3_MODE') && $TYPO3_CONF_VARS[TYPO3_MODE]['XCLASS']['ext/testextension/class.tx_testextension_eid.php']) {
    include_once($TYPO3_CONF_VARS[TYPO3_MODE]['XCLASS']['ext/testextension/class.tx_testextension_eid.php']);
}


// instanciation
$SOBE = t3lib_div::makeInstance('tx_testextension_eID');
$SOBE->main();

?>

Vous pouvez tester votre script depuis la barre d'URL de votre navigateur.
Pour appeler ce script, tout dépendra de votre javascript. Personnellement, j'utilise Jquery car je trouve cette librairie JS plutôt facile d'accès et les plugins sont légions. Avec Jquery, vous pouvez appeler la fonction $.ajax : http://docs.jquery.com/Ajax/jQuery.ajax#options. Ce qui est intéressant avec cette fonction, c'est que les paramètres sont nombreux. En fonction du type de réponse renvoyée par le serveur, vous pourrez spécifier un traitement spécifique avec dataType (xml, html, script ou json).

Exemple :

$.ajax({
     type: "POST",
    url: "?eID=testextension", // Mon script eID !!!
        data: "{'username': '" + $('#field').val() + "'}", // Les paramètres passés par l'URL
    contentType: "application/json; charset=utf-8",
    dataType: "json",

    success: function(msg) {

    $('#valid').html("<img src='images/waiting.gif' alt='Checking username!'>");

    var delay = function() {

        AjaxJobOK(msg);

         };
 
            setTimeout(delay, 2000);

         },

         error: AjaxFailed

});

Voilà, j'espère que cet article vous sera utile :)

En ce moment, entre mes différents projets, je trouve le temps de m'amuser avec Windows Mobile 6.5. Je ne vais pas faire un énième test ou une preview du système. Néanmoins, comparé à un Windows Mobile 6.0 ou 6.1, on s'aperçoit que Microsoft a bien travaillé même si l'on est loin d'un Iphone. Il y a quand même du progrès. A l'usage, on fini vite par oublier que Microsoft a laissé à l'abandon son système pendant plusieurs années au profit de son système d'exploitation phare, Windows XP/Vista. C'est à cause de son manque d'intérêt pour les terminaux mobiles que de nombreuses interfaces ont été développées par des constructeurs comme HTC avec son Touch Flow. Bref, Microsoft a réagit un peu trop tard, laissant le champ libre à Apple qui a quand même pris de l'avance coté ergonomie. Pour en revenir à cette nouvelle monture de Windows Mobile, on notera des icones plus larges, des menus plus accessibles et un Internet Explorer qui a regroupé des spécifications de IE8. On avait abandonné ce navigateur au profit d'Opera et on sent que les techniciens de Microsoft se sont inspirés de ce dernier pour leur monture même si je préfère encore la dernière version d'Opera Beta (9.51 b2), plus complet. Pour terminer, la gestion de la mémoire semble être améliorée.
Bref, vivement WM 7.0 ;)

Vous connaissez certainement la commande "df -h" pour vérifier l'espace disque sur une distribution GNU/Linux de type Debian.
Je suis tombé aujourd'hui sur un programme sympathique qui se nomme di (apt-get install di).

"di" permet de customiser l'affichage des informations et d'effectuer au besoin des tris pour tracker les fichiers les plus lourds et faire de la place si nécessaire.



Un "di -g" permet d'afficher l'espace disponible mais en Mo.

Enfin, vous disposer normalement de la commande du (disk usage) sur votre distribution.

Voici un exemple :

du -ah | sort -rn > espace.txt

Elle permet de classer les fichiers ainsi que leur taille, du plus lourd au moins lourd, dans un listing que vous pourrez consulter plus facilement dans votre éditeur favori.

Exemple :

1020K   ./local/src/Geo-IP-1.35
1016K   ./share/locale/pt_BR
1016K   ./share/groff
1016K   ./local/src/typo3_src-4.2.6/typo3/sysext/tsconfig_help/ext_tables_static+adt.sql
1016K   ./local/src/typo3_src-4.2.4/typo3/sysext/tsconfig_help/ext_tables_static+adt.sql
1016K   ./local/src/typo3_src-4.2.3/typo3/sysext/tsconfig_help/ext_tables_static+adt.sql
1016K   ./local/src/typo3_src-4.2.1/typo3/sysext/tsconfig_help/ext_tables_static+adt.sql
[...]

Je travaille actuellement sur un projet avec des sessions sous TYPO3. L'utilisation de sessions me permet de stocker des informations sur un utilisateur et de les conserver tout au long de sa navigation. Un utilisateur peut être connecté à un site en tant que user frontend ou bien un simple utilisateur qui ne dispose pas de compte. Il peut arriver que le site ne dispose pas d'espace privé. Dans ce cas, les données d'une session sont conservée 24 heures ou bien lorsqu'un utilisateur ferme son navigateur.

Lorsque l'on souhaite conserver en session des données, tout dépendra justement du type d'utilisateur concerné.
Voici comment stocker des données :

$GLOBALS["TSFE"]->fe_user->setKey($type, $var, $content);
$GLOBALS["TSFE"]->storeSessionData();

$type : espace de données - il s'agit ici de 'user' ou bien de 'ses'. Dans l'exemple que je vais présenter ici, l'utilisateur ne peut pas se connecter à un espace privé et donc, ses données seront conservées temporairement. On utilisera 'ses'.
$var est le nom de la variable que je vais stocker en session. Il est ainsi possible de stocker plusieurs variables.
$content contient les données à conserver. On utilisera un tableau, c'est d'ailleurs bien pratique.

Dans un plugin frontend, on va par exemple créer deux méthodes :
- une pour stocker les données de session
- une pour récupérer ces données

Désolé, mes commentaires sont en anglais ;)

Pour stocker les données :

/**
     * Call this function to store information is current session
     * Session are limited to 24 hours, remember !
     *
     * @param    string        $type: 'ses' or 'user'
     * @param    string        $var: varname
     * @param    array        $content: the content we need to store
     * @return    [type]        nothing !
     */
    public function storeSessionValues($type, $var, $content) {
        // more info: http://typo3.org/documentation/document-library/references/doc_core_tsref/4.1.0/view/14/1/

        // Store data into session (ses)
        $GLOBALS["TSFE"]->fe_user->setKey($type, $var, $content);
        $GLOBALS["TSFE"]->storeSessionData();
    }

Pour les récupérer :

    /**
     * Retrieve user data from session
     *
     * @param    [type]        $type: 'ses' or 'user'
     * @param    [type]        $var: varname
     * @return    [type]        array
     */
    public function getSessionValues($type, $var) {
        return $GLOBALS["TSFE"]->fe_user->getKey($type, $var);
    }

Pour utiliser ces fonctions, je vais initialiser mes tableaux :

$userData = array(); // données de l'utilisateur
$document = array(); // ce que je dois stocker

Ensuite, je récupére les données éventuelles

// Get user data from session
$userData = $this->getSessionValues('ses', 'documents');

Si des données existe, je les rajoute à mon tableau multidimensionnel
// We get the existing items
if(!empty($userData)) {
              $document= $userData;
}

Je stocke mes données à conserver dans mon tableau

// Store data into a session
$document[$uid]['data1'] = $var1;
$document[$uid]['data2'] = $var2;
$document[$uid]['data3'] = $var3;

$this->storeSessionValues('ses', 'documents', $document);

Mes données sont en session dans un tableau qui s'appelle 'documents' :)
Je rappelle le lien vers la doc core.

Pour tous mes projets, j'ai l'habitude d'utiliser l'extension weeaar_googlesitemap. J'ai même fais un tuto sur la création d'un sitemap.xml à l'époque sur typo3journal.
Aussi, quand j'ai vu arriver une extension de Google sitemap pour TYPO3, de Dmitry Dulepov de la Core team, je me suis posé la question suivante : pourquoi une énième extension ?

J'ai remarqué que Dmitry cherche toujours à optimiser le fonctionnement de TYPO3 pour le rendre moins lourd. De même, il n'aime pas trop que des extensions TYPO3 sortent "des standards" des bonnes pratiques de codage. Ainsi, avec sa nouvelle extension intitulée dd_googlesitemap, il revendique les points suivants :
- son extension permet de créer des urls correctes
- ajoute une information sur la date de dernière modification
- calcule automatiquement la fréquence des mises à jour (un hook de tcemain est utilisé)
- création des urls pour tt_news
- utilise eID pour alléger la charge du serveur.

Je ne vais pas parler d'eID ici, ce n'est pas trop le sujet mais c'est un ensemble de fonctions qui permettent d'effectuer des requêtes en base sans charger l'intégralité des fonctions du frontend (pratique pour de l'Ajax par exemple).

Pour en revenir à dd_googlesitemap, c'est une très bonne extension. Elle s'installe rapidement - d'un clic, elle est légère et utilise correctement le base url de la configuration TS de l'instance TYPO3 pour recréer les liens vers les pages à référencer dans le sitemap.

Alors, le sitemap est disponible sous l'url suivante :
www.monsite.fr/?eID=dd_googlesitemap

Si vous souhaitez avoir www.monsite.fr/sitemap.xml, vous devrez faire deux choses :
- créer un page type 200

sitemap {

  # Type de page pour le sitemap.xml
  typeNum = 200

}

- rajouter une rêgle de réecriture dans votre .htaccess (une seule ligne pour la rêgle)

# SitemapIndex
RewriteRule ^sitemap\.xml$ /index.php?eID=dd_googlesitemap [L]

That's all ;)

Actuellement, je travaille sur le DAM... enfin, plus précisément sur une galerie. Je veux permettre à mon client d'ajouter différentes informations sur ses images comme un titre, une description, un copyright, une référence. Le TER propose de multiples galeries sans DAM mais aussi avec une prise en compte du DAM. J'ai testé un bon nombre de galeries et malheureusement, j'ai un peu de mal à en trouver une qui me propose les fonctionnalités que je recherche mais surtout, une mise à jour facile depuis le back office pour une personne qui n'a jamais touché à TYPO3... alors imaginez le DAM !

Bref, j'ai décidé d'utiliser une vieille extension et la patcher, au lieu d'en développer une (la mission est assez courte, le budget aussi). Je souhaite également modifier l'affichage en ajoutant d'autres informations récupérées depuis la table dam_cat. J'ai donc choisi damd_gallery, une extension de 1997. C'est un risque car le DAM a évolué depuis, surtout depuis une importante mise à jour fin 2008.
Je n'ai donc pas été surpris lorsque rien ne s'affichait sur ma page, après avoir déposé un plugin et ajouté une catégorie du DAM. Pire encore, en passant sur un autre navigateur (hors connexion à l'admin de TYPO3), le serveur a commencé à ramer (être à genoux si vous voulez)...

Inquiétant tout ça. J'ai donc commencé à débugger l'extension. Les problèmes rencontrés :

- Une documentation incomplète
Elle existe mais elle est très incomplète

- damd_gallery utilise des sessions ($GLOBALS["TSFE"]->fe_user->getKey(type, key) - voir l'API de TYPO3). Pourquoi utiliser des sessions pour une galerie... en plus, j'ai besoin de quelque chose de simple et je n'ai pas non plus de données utilisateurs à stocker pendant une période déteminée. Du coup, quand j'ai souhaité changer de catégorie du DAM, j'avais toujours la même galerie affichée. Un problème de session ? Pas vraiment...

- Impossibilité de lire correctement un flexform
Bon, je sais que c'est devenu basique mais l'extension damd_gallery ou son auteur, semble avoir des difficultés à accéder à des informations dans un flexform. Je ne vais pas faire un cours ici mais pour info, j'ai utilisé ceci :

$catSelected = $this->pi_getFFvalue($this->cObj->data['pi_flexform'], 'wich_dam_cat', 'sDEF');

C'est tout bête et ca fonctionne... Je n'ai pas besoin de fusionner des données en TS et les données de mes flexform, surtout pour les catégories qui sont censées être dynamiques. Du coup, comme cette information était toujours vide, l'auteur de l'extension appelle la première catégorie dans l'arbre des catégories du DAM

- Des messages d'erreur en dur
Alors là non... que l'on m'épargne ceci. C'est pas compliqué de stocker les messages dans un flexform et ça permet d'internationaliser son extension.

- $this->pi_USER_INT_obj = 1 et $GLOBALS["TSFE"]->set_no_cache()
Donc, histoire de bien achever, on fait appelle à ces deux méthodes. Dans la première, mon plugin n'est pas mis en cache et au cas où on est pas certain si ça marche, on appelle set_no_cache pour être certain. En plus, pour une galerie d'image avec pour chaque image une lecture des informations dans la base de données, c'est le top.

Enfin, voilà, c'est mon petit coup de gueule... J'apprécie que des développeurs déposent le fruit de leur travail sur le TER mais il faudrait s'attacher à respecter avant quelques critères qualitatifs. Alors oui, c'est vrai, c'est là que 'alpha' prend tout son sens.

Mise à jour : les liens doivent être regénérés avec un cHash. Pour ce faire, ajout de la propriété suivante dans la classe étendue :
var $pi_checkCHash = true;

Puis au niveau des liens :

// ---> Update Christian - add cHash
$typoLinkConf = array();
$typoLinkConf['parameter'] = $linktopage; // PID
$typoLinkConf['useCacheHash'] = 1;
$typoLinkConf['additionalParams'] = '&' . $this->prefixId . '[singleimg]=' . $row["uid"];
$imarkerArray['###THUMBNAIL_IMAGE###'] = $this->cObj->typoLink($this->cObj->IMAGE($img), $typoLinkConf);

C'est un peu calme sur le blog mais ma nouvelle activité de freelance me prends du temps

Pour en revenir à l'actualité du jour, une alpha 2 pour TYPO3 4.3 a enfin été annoncée ce matin. Sa sortie est planifiée le 8 mars 2009, soit dimanche prochain. Rappelons juste quelques fonctionnalités marquantes de cette version :
- backportage du cache de Flow3
- intégration de l'authentification OpenID
- l'édition frontend devient une extension. D'ailleurs, l'édition du front-office a été repensée pour être plus moderne avec son temps (utilisation de l'Ajax)
- nouveau statut pour les extensions qui joue le rôle de protection contre une mise à jour non souhaitée
- intégration de la librairie extJS
- autoload des classes PHP
- corbeille (recycler) améliorée pour les enregistrements supprimés
- upload simultané de plusieurs fichiers (outil basé sur Flash)
- ...

Nous reviendrons sur les fonctionnalités un peu plus tard dans un prochain article. Cette Alpha 2 intervient avec à peu près 3 mois de retard sur la première date initiale (10 décembre) et 3 semaines après la seconde date qui était fixée au 15 février.

Il ne s'agit que d'une proposition de patch mais cette ligne de code typoscript permettrait de supprimer le fameux wrap qui entoure le code des plugins FE. Ce n'est certes pas grand chose mais comme la fonction pi_wrapInBaseClass m'irrite un peu, il fallait en parler ;)

Lien bugtracker

En complément du post précédent, voici la configuration (extrait) de l'extension RealURL pour Cal :

, 'cal'=> array(
                array(
                    'GETvar' => 'tx_cal_controller[view]'
                ),
                array(
                    'GETvar' => 'tx_cal_controller[getdate]'
                ),
                array(
                    'GETvar' => 'tx_cal_controller[lastview]'
                ),
                array(
                    'GETvar' => 'tx_cal_controller[type]'
                ),
                array(
                    'GETvar' => 'tx_cal_controller[category]',
                    'lookUpTable' => array(
                        'table' => 'tx_cal_category',
                        'id_field' => 'uid',
                        'alias_field' => 'title',
                        'addWhereClause'  => ' AND deleted != 1',
                        'useUniqueCache' => 1,
                        'useUniqueCache_conf' => array(
                            'strtolower' => 1,
                            'spaceCharacter' => '-',
                         ),
 
                    ),
                ),
                array(
                    'GETvar' => 'tx_cal_controller[uid]',
                    'lookUpTable' => array(
                        'table' => 'tx_cal_event',
                        'id_field' => 'uid',
                        'alias_field' => 'title',
                        'addWhereClause'  => ' AND deleted != 1',
                        'useUniqueCache' => 1,
                        'useUniqueCache_conf' => array(
                            'strtolower' => 1,
                            'spaceCharacter' => '-',
                        ),
                    ),
                ),
            )

L'extension Calendar Base est relativement complète si l'on jette un oeil à la documentation de l'extension.
Il est en effet possible d'afficher en frontend un calendrier avec des vues multiples (jour/semaine/mois), partager les calendriers de différents utilisateurs, autoriser l'édition frontend d'événements, permettre à des internautes de s'abonner à ces événements... Si l'on recherche néanmoins la simplicité avec cette extension, c'est possible ! A coté de l'agenda par défaut qui utilise les événements que l'on créé manuellement dans un sysfolder, il est possible d'importer un agenda externe. Vous pouvez donc saisir vos entrées sur votre agenda lié à votre compte Google et récupérer ces événements sur votre site.

L'importation se fait depuis un fichier ICS. Google agenda est capable de générer ce type de fichier depuis http://www.google.com/calendar/ : paramètres -> agendas -> cliquez sur l'agenda partagé -> Adresse URL de l'agenda -> icône ICS.

Vous devez ensuite dans un dossier système défini (n'oubliez pas de renseigner la valeur plugin.tx_cal_controller.pidList dans les constantes typoscript) un enregistrement de type 'Calendar' intitulé 'Agenda Google' par exemple avec l'url vers le fichier ICS dans le champ External Calendar URL. Dans 'Refresh Interval (Minutes)', indiquez la valeur 5 pour 5 minutes afin de synchroniser votre agenda Google avec l'extension Cal.

Enfin, ajouter un plugin 'TYPO3 Calendrier' avec la vue 'Mois' par exemple et dans la tabulation 'Filters', choisissez votre agenda Google.



Cependant, n'allez pas croire que la synchronisation de l'agenda va s'opérer toute seule. Il faut utiliser une tâche cron. L'extension Cal utilise une autre extension : Gabriel.

Dans le fichier ext_localconf.php de Cal, on retrouve d'ailleurs les lignes suivantes :

if (t3lib_extMgm::isLoaded('gabriel')) {
    $GLOBALS['TYPO3_CONF_VARS']['EXTCONF']['gabriel']['include'][$_EXTKEY] = array('cron/class.tx_cal_calendar_cron.php', 'cron/class.tx_cal_reminder_cron.php');
}

Dans le fichier class.tx_cal_calendar_cron.php, la classe tx_cal_icalendar_service (typo3conf/ext/cal/service/class.tx_cal_icalendar_service.php) est appelée. Les méthodes update et updateEvents vont mettre à jour la liste des événements pour notre calendrier externe Google. L'extension 'Gabriel' se sert d'un utilisateur backend nommé _cli_gabriel que vous devrez créer préalablement. Les événements seront créés dans le dossier système de Cal lorsque une tâche cron sera exécutée.

Voici un exemple (synchronisation toutes les 5 minutes) :

 */5 * * * * /var/www/instance_typo3/typo3conf/ext/gabriel/cli/gabriel_cron.phpsh> /dev/null

Vous pourrez vérifier ensuite votre calendrier en frontend pour voir que les événements ont été synchronisés.

La branche 4.x se prépare à adopter le modèle MVC (modèle/vue/contrôleur). La raison est simple : préparer la transition vers TYPO3 v5.0, la future version de TYPO3 réalisée avec le framework maison Flow3. D'ailleurs, beaucoup de principes seront repris de l'architecture de ce dernier.

Un diagramme du MVC est disponible ici où l'on voit comment le contrôleur réagit face
à une requête http.

La Core Team souhaite développer un modèle compréhensible tant par les débutants que les développeurs habitués à cette méthode de conception en fournissant une documentation appropriée et des exemples. Le kickstarter serait ainsi modifié pour créer la structure de fichiers nécessaire. Nous allons donc revoir la manière de développer des extensions sous TYPO3.
Il faudra définir des points d'entrée, à savoir un contrôleur et une action par défaut. Un plugin = un contrôleur et une action... pour le reste, rien n'est encore défini.

Un dispatcher fera le pont entre le modèle MVC de TYPO3 et l'extension du développeur. Par défaut, ce dispatcher qui est chargé d'appeler le modèle correspondant à une action, sera appelé mais il est possible de
le surcharger en typoscript (includeLibs, userFunc...).

Je vous invite à consulter la page en cours de construction : http://forge.typo3.org/wiki/typo3v4-mvc/MVC_Concept

Espérons que l'implémentation de ce modèle nous permettra de développer plus rapidement et plus proprement... c'est tout l'intéret d'un MVC vous me répondrez ;)

Notons également que Fluid, le nouveau moteur de templating devrait être présent dans la version 4.4 de TYPO3.

Le champ TS Config dans l'entête de vos pages est très utile à n'en pas douter. Vous passez par exemple la config du RTE sur la page root de votre site... ceci est un premier exemple.
Un autre exemple consiste à n'autoriser la création d'enregistrements d'un type donné dans un sysfolder. Pour n'autoriser que des enregistrements tt_news dans un sysfolder, éditez l'entête de votre page
et ajoutez le code suivant :

// Allow only certain types of record
mod.web_list {
   allowedNewTables = tt_news, tt_news_cat
}

Pour supprimer certains champs d'un enregistrement, il faut agir sur le rendu des formulaires dans le backend (TCEFORM) :

// Suppression des éléments 'type' en trop dans une actu
TCEFORM.tt_news.type.removeItems = 1,2

Pour remplir par défaut un champ (ici le champ auteur dans la table tt_news) :

// Adresse email par défaut
TCAdefaults.tt_news.author_email = webmaster@typo3journal.info

Pour désactiver un champ :
TCEFORM.ma_table.champ.disabled = 1

Et un petit rappel de la documentation sur le TS Config : documentation TS Config

Juste pour passer une information... Le chargement d'extensions sur le TER de TYPO3 est à nouveau possible. Si vous n'avez pas vos identifiants, il faut utiliser la fonction d'oubli de mot de passe pour récupérer de nouveaux identifiants ; c'est d'ailleurs obligatoire car les anciens mots de passe ne fonctionnent plus.

L'autre jour, sur typo3journal.info après une migration sur un autre serveur, je me suis rendu compte que les dates générées par tt_news étaient toutes en anglais, alors que coté typoscript, tout était correct.
Voici d'ailleurs un extrait de ma configuration :

// Langue par défaut (FE)
config {
sys_language_uid = 0
language = fr
locale_all = fr_FR.utf8
linkVars = L
}

Après quelques recherches sur le net, mes soupçons se sont portés sur la configuration de mon serveur Debian. Et en effet, j'avais un problème de "locales". Les locales fr_FR étaient tout simplement manquantes. Voilà comment j'ai résolu mon problème (en espérant que ça puisse aider quelqu'un) :

La commande 'locale -a' affiche les locales disponibles sur votre machine.

$ sudo dpkg-reconfigure locales

Un assistant apparait... sélectionnez toutes les locales fr_FR* en cochant les options appropriées :

fr_FR@euro ISO-8859-15                                                 
fr_FR ISO-8859-1                                                       
fr_FR.UTF-8@euro UTF-8                                                 
fr_FR.UTF-8 UTF-8

On pourrait peut-être se passer des locales ISO si son installation de TYPO3 fonctionne en utf-8...

Ensuite, toujours dans l'assistant, choisissez fr_FR comme locale par défaut. Editez ensuite le fichier /etc/profile et ajoutez les lignes suivantes ves la fin du fichier :

export LANG=french
export LC_CTYPE="fr_FR"
export LC_NUMERIC="fr_FR"
export LC_TIME="fr_FR"
export LC_COLLATE="fr_FR"
export LC_MONETARY="fr_FR"
export LC_MESSAGES="fr_FR"
export LC_PAPER="fr_FR"
export LC_NAME="fr_FR"
export LC_ADDRESS="fr_FR"
export LC_TELEPHONE="fr_FR"
export LC_MEASUREMENT="fr_FR"
export LC_IDENTIFICATION="fr_FR"
export LC_ALL=fr_FR

Vider les caches de TYPO3... Tout devrait fonctionner normalement :)

Un nouveau projet 'utile' a été créé sur le Wiki de TYPO3 : traduire les textes codés en dur dans les fichiers PHP. Selon les auteurs du projet, il s'agit de se focaliser sur les traductions du backoffice et notamment sur les sources de TYPO3. Vous pouvez apporter votre contribution à ce projet :)

Voici l'url du projet : Hardcoded project

Dmitry Dulepov est bien connu dans le monde de TYPO3. Il fait partie de la Core Team, développe des extensions et les propose sur le TER, anime un blog très intéressant et a publié le mois dernier un livre sur le développement d'extensions aux éditions Packt Publishing.
Aujourd'hui, Dmitry propose des "Guidelines" ou "rêgles de conduite" dans le développement d'extensions sous TYPO3. Ces 'guidelines' ne sont pas officielles mais presque. Elle ont été soumises pour approbation aux membres de la Core Team le 4 août dernier mais il n'y aurait eu que très peu de retours et parfois injustifiés selon Dmitry. Bref, ce dernier a choisi de diffuser son propre document et lorsque l'on voit la qualité de son travail, on ne peut être que ravi et confiant ;) Le document est à télécharger au format PDF.

Unofficial TYPO3 Coding guidelines

Je viens de recevoir le nouveau livre "TYPO3 Extension Development" de Dmitry Dulepov aux éditions Packt Publishing. Je n'ai pas encore eu trop le temps de le parcourir depuis hier mais il me semble assez détaillé et les explications paraissent claires. Voici un résumé des chapitres disponibles :

1- API TYPO3 : aperçu de l'API TYPO3 et énumère les classes les plus importantes
2- Anatomie d'une extension TYPO3 : décrit les fichiers d'une extension, leurs rôles et comment s'en servir
3- Planifier vos extensions : se concentre sur la planification. Comment bien développer une extension et l'adapter parfaitement à un projet.
4- Générer les extensions : générer une extension étape par étape, toutes les options sont expliquées et des conseils sont prodigués.
5. Plugin Frontend : étude en profondeur - les extensions frontend en général et des conseils utiles
6. Programmer des plugins frontend - comment créer une vue en mode LISTE, Détail, mode recherche, utiliser Ajax, créer du code typoscript pour une extension...
7. Programmer des modules backend : description des fichiers, conseils et programmation
8. Finaliser les extensions : écrire de la documentation pour une extension et publier cette dernière sur le TER

L'attente fut longue pour obtenir ce livre. Vous pouvez peut-être commander la version PDF. Je ne peux pas en dire plus pour l'instant mais je reviendrai bientôt sur le livre en publiant un article sur typo3journal.info

Extension Development

Vous souhaitez tester le framework FLOW3 mais le processus d'installation vous exaspère ? Pas de souçi puisque des images de type VMware existent ! D'ailleurs, Virtualbox, Parallels et d'autres solutions sont aussi supportées. La taille du téléchargement est réduite puisque la dernière version en date de l'image FLOW3 (serveur Apache, PHP 5.3 Alpha 1 et Flow3) ne pèse que 100Mo.
Télécharger l'image FLOW3