Note de ce sujet :
  • Moyenne : 0 (0 vote(s))
  • 1
  • 2
  • 3
  • 4
  • 5

gabarit et blocs hérités et balise html5 header
#1

Citation :#~~~~~ DEBUT BLOC A NE PAS SUPPRIMER ~~~~~
#~ Version du CMS: 1.11.4
#~ Url du site : none
#~ Hébergeur / Soft : sme en local et host
#~ Informations Système :
#~ testé en local et en host php 5.3.x et 5.4.x
#~~~~~ FIN BLOC A NE PAS SUPPRIMER ~~~~~

Bonjour, j'ai un soucis avec la balise <header> html5 avec l'utilisation de gabarits et blocs extensibles et je voudrai savoir si quelqu'un les utilise et s'il a ou n'a pas ce problème.

Le gabarit de base "tpl_base"

Code :
[== HTML ==]

{* gabarit de base tpl_base *}

...

{block name="test"}

contenu par defaut du bloc test

{/block}

...

Le gabarit étendu "tpl_base_ext"

Code :
[== HTML ==]
{* extension du gabarit tpl_base *}

{extends file='template:tpl_base'}

...

{block name="test" append}

<header>test inclusion balise html5 header </header>

{/block}

...

seule l'inclusion de la balise html5 header génère une erreur de gabarit en sortie.

unmatched {block} {/block} pairs

Pourtant pas d'erreur de ce côté, sinon j'aurai la même erreur sans ajouter la balise header...

Etrangement, si je place cette balise en dehors d'un bloc étendu mais toujours dans le gabarit étendu tpl_base_ext, comme ceci


gabarit étendu "tpl_base_ext" modifié


Code :
[== HTML ==]

{* extension du gabarit tpl_base *}

{extends file='template:tpl_base'}

...

<header>test inclusion balise html5 header </header>

{block name="test" append}


{/block}
...

alors pas de code d'erreur de sortie, mais la sortie des gabarits est alors empilée et non compilée ?!

Je pense que l'erreur doit provenir de la génération de la balise <head> par cmsms (d'après la première erreur...)

ou erreur de compilation (d'après la seconde erreur...).

note : tests effectués sur plusieurs sites, et toujours la même erreur.

Alors je voudrai avoir un retour avant de remettre le nez dans cette fonction pour ne pas perdre trop de temps.

Surtout si cela fonctionne chez quelqu'un autre, pour alors chercher l'erreur dans le reste de mon code.

Merci.
Répondre
#2

Peut-être une piste par là :

Changelog

Version 1.11.2 - Isabela

- Minor adjustment to page template parsing to detect <head instead of <head>


...
Répondre
#3

J'ai tenté une parade en utilisant un replace dans les blocks, mais ça ne semble pas fonctionner...

par contre ça fonctionne avec les variables, comme ceci :

Dans le gabarit de base, je défini une variable (en dehors des blocks) avec pour valeur "header".

Dans le gabarit étendu je remplace les balises <header>...</header> par <{$ma_variable}>...</{$ma_variable}>

C'est un peu de la bidouille, mais bon ça fonctionne

si quelqu'un a mieux je suis preneur.
Répondre
#4

Ok, j'ai trouvé.

Cela viens bien d'un changement effectué depuis la révision 1.11.2

La solution tient a vraiment pas grand chose mais vu qu'il faut modifier une classe du corps, j'indique rien ici et je préviens la team.

Je donnerai pour info, les retours de la team.
Répondre
#5

Citation :j'indique rien ici et je préviens la team.
Comment et de quelle façon ??
mais
avant cela tester en version SVN 1.11.5 pour assurer Wink

J-C Etiemble v 2.2.xx
Répondre
#6

J'ai eu un retour de calguy1000: il compte régler cela dans la 1.11.5

Trop fort, vu que pour obtenir ce bug, il faut le chercher et comme je lui ai dit, je doute qu'il gène beaucoup de monde.

Pour Jce76350 : je comprends pas ce que tu me demandes ...

Tu veux savoir comment je préviens la team ?
Répondre
#7

bien joué Phil Wink
Répondre
#8

Citation :>Pour Jce76350 : je comprends pas ce que tu me demandes ...

Tu veux savoir comment je préviens la team ?

La Team c'est pas calguy seul et calguy ce n'est pas la Team Wink
Ce que je voulais dire est que si l'on trouve un bug, avant tout, il est indispensable de passer par Submit New Bug
- d'abord c'est acté et donc le (les) développeur(s) sont avertis
- ensuite ça permet de savoir qu'il y un possible problème (et de le résoudre provisoirement si il y a une solution proposée par l'émetteur du bug).

J-C Etiemble v 2.2.xx
Répondre
#9

J'ai fait comme d'habitude,
J'ai vérifié plusieurs fois ce bug,
je l'ai ensuite signalé sur le blog de Goran Iilic pour vérifier s'ils obtenaient la même chose, (bug confirmé)
j'ai ensuite cherché d'où venait l'erreur pour la résoudre ,
et je l'ai enfin déclaré par le bug tracker.

Je te rassure jce76350, je n'oublie pas les autres membres de la Team... dont la partie FR Wink

Pour mettre une deuxième couche sur la manière de déclarer un bug pour ceux qui passeraient pas ici.

1-essayer de reproduire le bug sur différentes plateformes, sur version cmsms native
2-essayer de se faire confirmer le bug par qqun d'autre ...voir plus.
3-essayer de résoudre le bug
4-déclarer le bug par la section "bug tracker" avec un max d'infos (en anglais...hum)
5-informer des retours d'informations reçus
6-remercier tout le monde

et si ce n'est pas un bug mais une amélioration possible ou une demande spécifique: section "feature requests"

comme par exemple :

suggérer de remplacer les /tmp... du code source par les constantes déjà existantes

ça simplifiera la tache de certains :p
Répondre
#10

Citation :4-déclarer le bug par la section "bug tracker
Et si possible indiquer le lien du bug pour le suivi

J-C Etiemble v 2.2.xx
Répondre
#11

Effectivement, c'est nettement plus facile avec le lien... Rolleyes

bug report
Répondre


Atteindre :


Utilisateur(s) parcourant ce sujet : 3 visiteur(s)