Le Typoscript, c’est quoi exactement ?
Voici un billet qui peut paraître anodin pour ceux et celles qui connaissent déjà le CMS TYPO3, mais il me paraît essentiel de rappeler que sans le Typoscript, TYPO3 n’est rien !
Les quelques explications qui suivent sont destinées à un public déjà connaissant avec le SGC TYPO3, mais jugé non expert avec ce qu’est le Typoscript.
Mais qu’est-ce que le Typoscript ? Je me souviens qu’a mes débuts avec TYPO3, aux alentours de 2004 lors de mes premières lectures, il y avait des polémiques autour du TS (appelons-le comme çà par la suite ce sera plus simple). On disait alors que c’était comme du XML et donc pourquoi réinventer la roue ! On parlait alors d’un nouveau langage à apprendre, un énième ! Bref, tout un tas de raison pour dévaloriser TYPO3 et freiner tout novice que j’étais dans mon apprentissage de TYPO3. Je vous dirais que comprendre la mécanique de TYPO3 tout seul dans son coin est assez long, même si on vous montre quelques petits trucs, il y en a toujours et encore à apprendre. Donc faire le tour et comprendre l’intérêt réel du Typoscript ne se fait pas du jour au lendemain.
Maintenant après plusieurs années d’utilisation de TYPO3, je peux vous dire que je comprends mieux l’intérêt d’utiliser du Typoscript dans des projets de sites Web. J’irais même jusqu’à dire que Typoscript est l’avantage numéro 1 pour le CMS TYPO3 par rapport à tous les autres CMS de la planète (c’est un peu gonflé çà non ?), opensource ou non d’ailleurs. Il y a quelques années, je n’aurais sûrement pas été à l’aise pour dire çà et j’aurais sûrement mis en avant en avant d’autres avantages : les nombreuses extensions, le TER (le serveur qui gère les extensions et permet de pouvoir en importer facilement dans TYPO3), les Hooks ou les XCLASS. Sauf que maintenant les autres CMS ont déjà intégré ces mécanismes. Sur Wordpress c’est extrêmement simple d’installer une nouvelle extension ou de la mettre à jour, de même qu’avec Drupal, l’étendre, le « hacker » ça se fait aussi avec des Hooks. Mais toutes ces solutions n’ont pas encore compris l’intérêt d’avoir un outil de configuration intermédiaire comme le Typoscript.
J’ai dit « outil » ? Sans doute, parce qu’il est difficile de décrire ce qu’est le Typoscript. Il n’a jamais été considéré comme un vrai langage a proprement dit comme le PHP, car il n’y a pas vraiment de fonctions ou de classes. Mais pourtant il y a des conditions, des « sortes » de variable, des d’objets typés …
Voici ce que l’on peut lire dans la littérature de référence :
TypoScript is neither a programming language nor a script language, so it cannot be compared with Java, PHP, or JavaScript. It is not possible to use loops (for, while,…), for example. TypoScript serves as an « information carrier ». You don’t have to learn any new, and above all, proprietary languages. TypoScript itself is not run at any time.
D’ailleurs il existe un outil dans TYPO3 (object browser) qui permet d’avoir un aperçu du code Typoscript et celui-ci se compare aisément à la base de registre de Windows.
En voici un aperçu :

Navigateur d'objets Typoscript
Mais ça n’est pas suffisant pour décrire ce qu’est le Typoscript. En écrivant ce billet, je voulais faire un hommage au TS et à son créateur Kasper Skaarhoj qui a eu la géniale idée de créer ce pseudo langage, alors allons y !
Maintenant que vous êtes capable de situer la place de TYPO3 et du Typoscript par rapport aux autres CMS, je vais tenter de vous expliquer à quoi cela peut-il servir et pourquoi nous ne pouvons nous en passer.
Comment ça marche ?
Le Typoscript est au coeur de TYPO3, d’ailleurs une des premières étapes lors de la création d’un site à l’aide de TYPO3 s’est d’inclure un fichier externe d’environ 2500 lignes de code Typoscript.
Voici un aperçu des dernières lignes de ce fichier :
Ces lignes ont pour effet de définir comment doit s’afficher le contenu sur les pages du site. Par exemple un bloc avec son titre, son texte provenant du RTE, un lien « haut de page », etc.. Ou bien encore ce même contenu avec une série d’images alignée à gauche ou en haut. Le code Typoscript contient toute la syntaxe de comment afficher ces informations.
Voici un aperçu de ces champs et du résultat :
Si par exemple, nous voulions modifier le code HTML qui permet de générer le lien « Lien vers le haut » cela se retrouverait à travers les 2500 lignes de code proposées de base par TYPO3. Cela peut vous paraître compliqué, mais c’est un avantage de pouvoir avoir le contrôle entièrement sur le résultat final, ne serait-ce que si l’on veut que notre site réponde à tout les règles d’accessibilité en vigueur au gouvernement.
Voici la ligne a modifiée pour changer le code HTML du lien « haut de page » :
tt_content.stdWrap.innerWrap2 = | <p class="csc-linkToTop"><a href="#">
{LLL:EXT:css_styled_content/pi1/locallang.xml:label.toTop}</a></p>
Comme vous pouvez le constater, il y a un lien entre ce qui s’affiche sur une page de votre site et le code TS. Si vous ne le saviez pas encore, sachez que TYPO3 est programmé avec le langage PHP, c’est un langage de programmation très populaire aussi utilisé par le site Facebook ou Wikipedia. Sauf qu’à la différence de ces sites-là, le code PHP de TYPO3 a souvent besoin d’instructions supplémentaires pour afficher de quoi sur une page. Bien entendu, des parties de code PHP sont autonome et agissent entre elles sans avoir besoin de code TS, mais dans beaucoup d’actions, comme celles d’afficher le contenu « standard » sur le site, le TS est essentiel.
Ainsi si le code PHP se sert du code Typoscript pour générer du code HTML, il vous donne aussi la possibilité à vous administrateur du site de pouvoir contrôler le rendu du site, sans avoir aucune connaissance en PHP. C’est là une différence entre les autres CMS, ou souvent il faut aller « taponner » dans le code PHP pour pouvoir modifier le comportement de vos pages. Que ce soit avec Wordpress ou Drupal, c’est flagrant quand vous jouer dans vos gabarits HTML, il y a plein de code PHP qui s’entremêlent avec le code HTML.
Capture de Wordpress dans un gabarit :
Heureusement tout ceci n’existe pas avec TYPO3, ainsi maintenir un gabarit HTML c’est très facile. Mais attention ! si le développeur (que ce soit un membre du core de TYPO3 ou vous mêmes), ne prend pas la peine d’ajouter les mécanismes nécessaires pour connecter son code PHP à du code TS équivalent alors l’avantage est perdu et le Typoscript perd tout son sens.
Le code Typoscript ne s’apparente pas à un langage, il a sa propre syntaxe et beaucoup de monde le sait (surtout ceux qui le dénigrent), il faut du temps avant de pouvoir écrire aisément des lignes de Typoscript.
Mais revenons-en au mécanisme, comme je le disais plus haut, des bouts de code PHP dans TYPO3 attendent après du code Typoscript pour afficher le code HTML des pages de votre site. Voyons un premier exemple de ce que le PHP attend. Avant tout chose, il faut savoir que le code Typoscript est organisé hiérarchiquement via des objets prédéfinis. Certains de ces objets sont des objets de haut niveau (Top Level), par exemple l’objet PAGE qui permet de définir le rendu de la page ou l’objet CONFIG qui permet lui de modifier une partie de la configuration de la page.
Voici donc un premier exemple qui permet de modifier le doctype d’une page HTML :
config.doctype = xhtml_11
Cette ligne de code va générer les lignes suivantes dans votre code HTML :
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Et un autre qui permet de définir si l’interface de votre site (les extensions par exemple ou le contenu) doit s’afficher en français :
config.language = fr
Jusqu’à la c’est assez simple ? Rien de très excitant, on pourrait comparer cela à des constantes ou des variables dans un langage comme le PHP. Ce qui est un peu déroutant au début, c’est la syntaxe, on se demande : mais ou est le point virgule à la fin ??
Une fois que vous avez configuré le code Typoscript, le code PHP peut alors se fier à vos valeurs et ainsi générer le bon code HTML en sortie, sinon dans la plupart des cas il va générer des valeurs par défaut.
Voici un exemple des propriétés que vous pourriez retrouver sur un site Web :
La documentation officielle
Et pour connaître, tout ce code et ces valeurs, j’en entends déjà me demander où aller ? Rien de plus simple, il existe un guide de référence, qu’on appelle le TSref (pour Typoscript reference), qui peut être consulté dans différents formats. Par exemple sur le site de TYPO3 ici, vous pourrez le lire en ligne, et pour ceux comme moi qui préfère le consulter directement depuis leur navigateur Firefox hors ligne, il existe une extension pour Firefox à télécharger ici.
Dans ce guide, vous pourrez découvrir toutes les propriétés existantes pour chacun des objets. Par exemple si je consulte le TSref, j’apprends qu’il est possible d’indiquer au PHP sur quelle « locale » se fier lorsque celui-ci doit afficher des dates tout simplement en ajoutant cette ligne dans mon code :
config.locale_all = fr_CA
De cette manière, si le code PHP doit afficher une date, il pourra afficher les jours de la semaine ou du mois en français (si le tout est disponible sur le serveur bien entendu, le Typoscript ne fait pas de miracle non plus !)
Pour ceux et celles qui se seraient déjà jetés sur le TSref, attention car celui-ci n’est pas un guide pour apprendre le Typoscript, il existe pour cela des tutoriaux qui vous permettent de commencer doucement par la base.
En voici quelques-uns :
- Le Typoscript en 45mn (anglais et partiellement en français)
- Modern Templating (anglais et français)
- Typoscript par l’exemple (anglais et français)
- Syntaxe Typoscript (anglais)
Par contre, pour devenir meilleur, je vous encourage à lire le TSref le plus possible et si vous cherchez des exemples de quelques propriétés et bien faites appel à Google pour voir comment les autres TYPOistes les utilisent. Même si le TSref offre des exemples pour certaines propriétés, des fois c’est un peu obscur et dans ce cas Google reste votre ami.
Maintenant que vous avez vu des exemples de configuration possible, nous allons voir les nombreux avantages que cela offre dans la vraie vie !
Avantages
Comme je le disais en introduction, le Typoscript est l’avantage numéro 1 lorsque vous choisissez TYPO3 pour créer vos projets Web. Maintenant je n’hésite même plus à le dire à nos clients, ce qui n’était pas le cas il y a quelques années car peu familiarisé avec le TS. D’ailleurs à mon sens un client à plus d’avantages à aller modifier une constante quelque part dans le TS que d’aller jouer dans le code PHP, vous n’êtes pas d’accord ? Et si une entreprise a une équipe de développeurs PHP, l’apprentissage du Typoscript n’est pas une si haute marche à gravir pour eux autres.
Mise à part le faite que vous pouvez contrôler le rendu de la page via du TS, quels sont les autres avantages ? Il y en a de nombreux, comme par exemple modifier un comportement sur une section particulière de votre site. Ça paraît évident dans le cadre d’une utilisation multisite de TYPO3. Vous avez un site principal et de petits portails à l’intérieur pour des thématiques ou des événements spécifiques et vous voulez changer le comportement d’une extension, alors le TS est là pour vous aider. Car toutes les lignes de TS que vous allez ajouter au fil du temps via l’interface d’administration de TYPO3 sont CONTEXTUELLES ! C’est important de comprendre que le code TS ne se met pas toujours à la racine du site. En effet, on applique du code TS là ou l’on en besoin et celui-ci va se propager par lui même sur toutes les sous-pages. Ainsi il est facile de formater une date d’une certaine façon dans une liste de nouvelles, par exemple sur la page d’accueil et d’une autre façon sur une autre section du site. Pour cela, il suffit d’ajouter la ligne dans la bonne section du site et le comportement du code PHP se verra modifié en conséquence.
Voici comment se propage du code Typoscript sur une page spécifique :
Si vous vouliez faire ce type de mécanisme avec un autre CMS, il faudrait créer une exception dans le code PHP ou bien encore prévoir un outil de configuration pour le faire. D’ailleurs en parlant de cela, on pourrait alors se demander pourquoi ne pas afficher toutes les options du TS dans un outil de configuration avec plein de case à cocher, de champs d’entrées pour y saisir des valeurs ? La réponse est assez simple : d’abord il en faudrait beaucoup d’options (ce que le système TikiWiki se vante d’avoir, environ plus de 1000 options) et ça deviendrait rapidement le foutoir.
D’un autre côté le code TS n’est pas qu’un simple outil de configuration, car il existe ce qu’on appelle des fonctions et ce serait difficile de les exploiter via des « widget » dans une interface de contrôle.
Allez plus loin avec le TS
Vous voulez aller plus loin en Typoscript ? Il y a les fonctions pour cela, il en existe plusieurs, elles sont décrites au début du TSref. Par exemple si vous connaissez un peu le Typoscript, vous avez sans doute déjà entendu parlé de « stdWrap » ou « typolink » ou encore du « if ». À partir du moment où vous faites appel à une des propriétés décrites dans une de ces fonctions, ça veut dire que vous avez commencé à exploiter pleinement la puissance de TYPO3 et du Typoscript.
Les fonctions sont à mon sens, ce qui se fait de mieux dans le Typoscript, mais en arriver à les utiliser avec aisance prend un certain temps. En tout cas, cela m’en a pris pas mal avant d’arrêter de faire de bête copier-coller et de comprendre la finesse de ces fonctions. C’est grâce à ces fonctions que l’on peut dire que TYPO3 offre toute sa flexibilité !
Je vais vous donner deux exemples d’utilisation de la fonction « stdWrap » pour mieux comprendre.
Imaginez que vous avez une liste de nouvelles qui s’affichent à l’écran, mais que vous voulez tronquer le texte qui résume la nouvelle (le « teaser ») à une certaine longueur. Là encore, le réflexe serait d’aller dans le code PHP et d’utiliser la propriété « substr » du PHP. Mais pourquoi ne pas regarder du côté de la fonction « stdWrap » ? Le TSref nous indique une propriété « crop » qui en plus de pouvoir indiquer à partir de combien de caractères vous souhaiter couper votre texte, vous pouvez prendre aussi en compte les mots et de ne pas tronquer un mot en plein milieu. Elle n’est pas belle la vie ?
Voici un aperçu de la documentation pour cette propriété :
Un autre exemple serait de faire appel à la fonction « typolink », qui permet de pouvoir créer ou modifier facilement un lien. Exemple avec le lien de détail d’une nouvelle. Il y a de grandes chances que tous les liens générés par les extensions de TYPO3 fassent appels à cette fonction, ce qui vous ouvre beaucoup de possibilités, par exemple l’ajout de paramètres ou la modification d’attributs (Exemple modifier ou ajouter l’attribut « title »).
Voici un aperçu de la documentation pour cette fonction :
Bien entendu, il est difficile de comprendre toutes ces propriétés sans avoir déjà de bonnes connaissances du TS et de TYPO3, mais je voulais juste vous démontrer ici que tout problème à sa solution avec TYPO3, tant que l’on sait comment lire les guides mis à notre disposition et en cherchant un peu.
Menu de navigation
Un autre des avantages du TS est le contrôle que nous avons sur les menus de navigation. Il faut savoir que tous les menus de navigation qui s’affichent sur un site Web sont codés entièrement via du TS. Entre 10 et 15 lignes grand maximum pour faire un menu.
En voici un exemple :
La plupart du temps, c’est à coup de copier-coller que vous faites tous vos menus, tant il est simple d’en monter par la suite. Un des avantages de faire les menus en TS c’est que l’on peut facilement le modifier sans allé dans du code PHP. Iil est rare de faire planter le site en procédant de même, même si un des désavantages est de ne pas avoir de débogueur lorsque l’on écrit notre code et si une accolade est manquante, cela pourrait désactiver une partie du code qui suit.
Conclusion
Bref, je pourrais en écrire encore beaucoup sur le TS, par exemple vous présentez les outils (constant editor, object browser, template analyzer) qui existent pour gérer notre code, car au fil des années ils sont devenus de plus en plus puissants et indispensables, mais je me réserve cela pour un autre billet.
Pour faire suite à ce billet, je pourrais également vous présenter ce qu’est le TSConfig, c’est du code TS pour influencer l’interface d’administration (rédacteurs ou administrateurs), mais ceci fera partie peut être d’un autre billet.
J’espère que ces quelques lignes vous seront utiles lorsque vous devrez défendre TYPO3 par rapport à d’autres outils, libres ou non. TYPO3 aura toujours un pas d’avance sur les autres CMS tant que ces CMS n’auront pas trouvé de solutions équivalentes.
S’il n’y avait qu’une chose à retenir : TYPO3 reste le CMS le plus flexible du marché grâce au Typoscript !
Catégorie(s) : CMS/SGC
Tag(s) : TYPO3, typoscript
























[...] Pourtant dans le cas d’Infoglobe, il semble qu’au final, l’investissement est payant : Le Typoscript, c’est quoi exactement ?. [...]
Pfff c’est nul ce charabia.
Drupal est mieux que Typo, plus simple et plus ouvert.
Deborah (avec une adresse jetable),
Typo (TYPO3 tu voulais dire ?), est moins ouvert que Drupal ! Ca veut dire quoi concrêtement, est ce qu’il faut un ouvre boite pour TYPO3 ?
Plus simple, peut être, Wordpress aussi il est plus simple, et c’est pas comme çà qu’on choisi un CMS.
Il nous faut plus d’argument si tu veux que les gens embarque dans ton sens.
A+
Bien vrai, j’ai testé Drupal, et au contraire, je trouve typo3 plus « ouvert ». En fait, il ne décide pas pour toi quoi faire, il permet de créer tes propres templates pour les extensions et de « parser » les contenus directement en TypoScript, et générer des contenus (ex: menus).
Alors qu’avec drupal, il décide du code HTML à générer pour tout, et ensuite, il faut overrider tout avec des fonctions PHP. Ce n’est vraiment pas pratique et amusant… Surtout quand on crée le template HTML avant, et non après…
Voilà mon grain de sel.
Apôtre de Drupal ici, mais surtout en opposition aux langages propriétaires dans les CMS (SPIP aussi est coupable).
[[ Que ce soit avec Wordpress ou Drupal, c’est flagrant quand vous jouer dans vos gabarits HTML, il y a plein de code PHP qui s’entremêlent avec le code HTML. ]]
Et dans votre code TS, y’a plein de code HTML qui s’entremêle avec votre TS
La plupart des éléments nécessaires à construire la page dans Drupal sont accessibles avec une simple déclaration (par exemple $node->title ou $node->body) et ça peut donc demeurer assez propre; du code malpropre, ça se peut dans n’importe quel langage.
[[ D'ailleurs à mon sens un client à plus d’avantages à aller modifier une constante quelque part dans le TS que d’aller jouer dans le code PHP, vous n’êtes pas d’accord ? ]]
Votre client moyen (sauf tout le respect que je lui dois, il paie mon salaire aussi) a de la difficulté à changer la taille des polices dans son navigateur web, vous voudriez qu’il se rende modifier un obscur paramètre au fond d’un menu? Et il va le trouver sans vous? J’ai de la difficulté à croire que votre client ne se jette pas au téléphone pour vous demander de faire la modification à votre place.
[[ TYPO3 aura toujours un pas d’avance sur les autres CMS tant que ces CMS n’auront pas trouvé de solutions équivalentes. ]]
En tout cas, dans Drupal, pour construire un menu, j’ai aussi besoin de moins de 10-15 lignes de code : en fait, zéro
Même si les avantages théoriques de l’esperanto sont énormes vis-à-vis le français, il n’en demeure pas moins que pour discourir en esperanto, faut chercher longtemps un partenaire. Votre « pitch de vente » ne cesse de répéter qu’il faut investir beaucoup de temps pour profiter de TS, eh bien, la journée où la firme qui développe mon site web en Typo3 ferme ses portes, je suis malpris : bien peu de programmeurs vont vouloir investir « plusieurs années » afin de pouvoir modifier un bête CMS.
Et une fois TS su du bout des doigts, je serais surpris de savoir combien de temps de développement est sauvé vs. le temps investi pour développer la même chose sous Drupal.
Salut Le pouce,
Ayé la guerre de cloché commence
- Pour ce qui est de l’entremelage entre le code HTML et le reste, je préfère nettement que celui se retrouve dans un fichier de configuration comme le Typoscript que dans un gabarit html ou une extension PHP. C’est justement un avantage de pouvoir modifier une partie du code HTML dynamiquement en l’ayant dans un fichier de configuration comme le TS que de le chercher dans le HTML et le PHP.
- Tu as tout fait raison, pour le client « Moyen », il nous appele malheureusement, mais peu importe le produit, il appelera quand même. Par contre le client qui veut être autonome, je trouve qu’il est plus facile de lui demander de modifier une constante dans l’interface de TYPO3 que d’aller fouiller dans du code PHP.
- Zéro ligne pour construire un menu ca ne se peut pas, sauf si tu utilises le code par défaut, mais dans ce cas là, autant prendre Wordpress si c’est pour faire des sites de 5 pages
Moi je pensais à des menus spéciaux du genre :
— Gérer l’etat actif (quand on est sur la page en cours et qu’on veut la mettre en évidence dans le menu)
— Quand on veut mettre en évidence un menu si les sous pages sont déployées
— Si on veut mettre en évidence une page externe dans un menu
etc..
Mon « pitch de vente » comme il dit, il tend à démontrer que dans le monde professionnel ou je travail, c’est bien plus pratique d’avoir un outil flexible comme TYPO3. C’est certain qu’a connaissance égal, je suis sur que tu irais aussi vite qu’un gars qui connait TYPO3 sur le bout de doigts. Tous les CMS se valent, mais pour ma part, je ne regrette pas d’avoir fait l’effort d’apprendre le Typoscript et si je devais recommencer, je prendrais cette voix. Le TS est un outil de configuration vraiment très puissant qui m’évite de développer des extensions PHP à tout va ou de gérer des exceptions dans le code PHP.
Et puis les ressources TYPO3 c’est pas çà qui manque, si demain Infoglobe ou tout autres entreprises devaient fermer ses portes, il y en a toujours une derrière pour offrir le support.
D’ailleurs si je veux, je peux changer le comportement d’un menu avec une seule ligne de TS dans une branche d’un site et pour moi c’est vachement pratique
Il faut bien prendre conscience que TYPO3 n’est pas le CMS pour toutes les situations ! Je déconseille TYPO3 pour faire un site perso ou un blogue. Mais si tu as la possibilité de te faire former et d’investir sur du long terme, alors TYPO3 est pour toi ! si tu fais un site de temps en temps, prend Wordpress. Et si tu as pas le gout ou pas la possibilité d’investir du temps dans TYPO3, il restera toujours Drupal, mais moi j’ai juste hate de voir comment on fait pour gérer un site avec 1000 ou 3000 pages dans Drupal !
Merci pour tes commentaires, je suis bien ouvert à découvrir les forces de Drupal !
Yannick,
[[ C’est justement un avantage de pouvoir modifier une partie du code HTML dynamiquement en l’ayant dans un fichier de configuration comme le TS que de le chercher dans le HTML et le PHP. ]]
Je pense que ça va rester kif-kif Typo3/Drupal, ça ne me convainc pas. La séparation MVC de Drupal est assez bien faite pour ne pas avoir besoin de chercher trop trop; à la limite je dirais qu’un grep dans un répertoire va plus vite que de parcourir des menus, mais je sais qu’un tel argument va pas convaincre bien des gens
[[le client qui veut être autonome, je trouve qu’il est plus facile de lui demander de modifier une constante dans l’interface de TYPO3 que d’aller fouiller dans du code PHP.]]
Le client qui veut être autonome, on lui fait une vraie interface de configuration personnalisée, n’est-ce pas? parce que la journée où il change quelque chose par erreur et appelle avec son diagnostique « ça marche pus », on est pas plus avancés.
[[Tous les CMS se valent, mais pour ma part, je ne regrette pas d’avoir fait l’effort d’apprendre le Typoscript et si je devais recommencer, je prendrais cette voix.]]
Je dirais plutôt qu’on échange présentement sur deux CMS dans le Top 3. Dans la plupart des cas, on se retrouve pris dans une situation où pour arriver à quoi que ce soit, il faut aller modifier le code directement (des patchs que les concepteurs appellent des « modules »), ce qui brise le cycle des mises à jour. À moins d’avoir un besoin très précis rempli très précisément par un CMS donné, il faut apprendre un engin. Bien qu’il faille apprendre TS pour harnacher Typo3, je ne cacherai pas qu’il faut investir du temps dans Drupal pour apprendre comment l’adapter à sa… euh… vision.
[[Zéro ligne pour construire un menu ca ne se peut pas]]
Je comptais pas le temps pour remplir le formulaire et ordonner ça avec du drag-n-drop! Sérieusement, état actif : déjà géré par Drupal. Sous-pages déployées : déjà géré par Drupal. Mettre en évidence une page externe : un sélecteur CSS de type a[href^="http"] suffit pour n’importe quel navigateur moderne. Pour supporter MSIE6, une quinzaine de lignes copiées/collées du site de drupal (premier hit quand on cherche « menu id »). Faudra donc expliciter le « etc. »
[[J’ai juste hate de voir comment on fait pour gérer un site avec 1000 ou 3000 pages dans Drupal]]
whitehouse.gov est capable. theonion.com aussi. Rendu là, je pense que ça passe le test.
Je gère une installation multi-site (±150) de Drupal, avec un seul codebase, des contenus distincts, des utilisateurs distincts (qui sont « admin » au niveau granulaire où je le permets), et ça a été relativement aisé à déployer, le plus long est le travail d’analyse pour décider de ce qui doit être partagé intra-site ou non. Alors, ça scale aussi dans cette direction-là, si la question venait à se poser!