Carnet d'un développeur

les pérégrinations d'un developpeur sur le Web

Sous ce titre barbare, je vais vous parler d’un petit problème très simple qui m’est arrivé récemment.

Je suis entrain de développer un datatype spécifique et j’ai eu besoin de faire une page d’édition d’un objet. Afin de faire cela je suis passé par un content_actionhandler qui se charge de gérer toute mes actions. Pour cette action je passe par le mécanisme standard, j’ai donc fetché un Template qui va afficher mon formulaire.
J’ai donc un code PHP comme ça :

$Result['content'] = $tpl->fetch( 'design:mondatatype/monobjet_editform.tpl' );
$Result['path'] = array( array( 'url' => false,
'text' => 'Edit object' ) );

Mon template inclus des scripts :

{ezscript_require(
array(
'ezjsc::jquery',
'ezjsc::jqueryUI'
)
)}

Et puis je me suis rendu compte qu’en terme d’affichage, c’était plutôt austère. En effet ce code affiche un formulaire dans l’admin d’ezpublish avec juste le header, mais aucun menu (en particulier le menu de gauche).

Je me suis donc demandé comment l’afficher et j’ai trouvé cette option à ajouter dans le code PHP :

$Result['content_info'] = array('persistent_variable' => array( 'extra_menu' => true,
'left_menu'  => true ));

Magnifique, ça marche !!!

Sauf que maintenant, les scripts inclus par ezscript_require ne sont plus inclus … Il semblerait que définir les persistent_variable par ce biais fasse sauter les inclusions.
Heureusement, il existe une solution que je vais vous donner tout de suite. Elle consiste à définir via le PHP les persistent_variable comme variable du Template :

$tpl->setVariable( 'persistent_variable', array() );

Puis définir dans le Template les variables en question :

{set scope=global persistent_variable=hash( 'extra_menu',  true(),'left_menu',true() )}

Puis au final, dans le code PHP on va extraire cette variable pour l’injecter dans $Result :

$contentInfoArray['persistent_variable'] = $tpl->variable( 'persistent_variable' );
$Result['content_info'] = $contentInfoArray;

Et là, miracle, le ezscript_require fonctionne et l’affichage du formulaire se fait accompagné de nos deux menus :)

Au final ça donne en PHP :

$tpl->setVariable( 'persistent_variable', array() );
$Result['content'] = $tpl->fetch( 'design:mondatatype/monobjet_editform.tpl' );
$Result['path'] = array( array( 'url' => false,
'text' => 'Edit object' ) );
$contentInfoArray['persistent_variable'] = $tpl->variable( 'persistent_variable' );
$Result['content_info'] = $contentInfoArray;
return $Result;

et en haut du tpl :

{set scope=global persistent_variable=hash( 'extra_menu',  true(),'left_menu',true() )}

 

mars 17th, 2015

Posted In: Developpement Web, eZPublish

Mots-clés : , , , ,

Laisser un commentaire2 commentaires

Infrastructure :
Un load balancer, un varnish et 4 frontaux dont un dédié au backoffice (le reste n’a pas grande importance).
L’accès à la plateforme se fait via un serveur cli qui sert aussi de worker. Le tout est géré par un prestataire. Donc pour aller voir ce qu’il se passe sur le frontal 1, il faut se connecter à la cli puis de là se connecter au frontal 1.

Le Problème :
Un beau jour on se rend compte que Google Analytics signale un grand nombre de 404. Surprenant, d’autant plus que en allant voir les adresses en question, elles répondent parfaitement bien. Enfin … en apparence :).
Evidemment tant qu’elles étaient servies par Varnish, pas de problèmes. Par contre quand le cache varnish expire et qu’il interroge un frontal, ben sur les 3, il y en avait un qui était moisi.
Là ou c’est vicieux, c’est que du coup varnish ne met pas en cache la page en question et à force on finit par tomber sur un frontal correct et la page finie par être correcte.
(Ce problème était présent depuis 6 mois et a bien pourri le référencement avant que quelqu’un ne signale une anomalie menant à une investigation …).

La solution :
Je me suis aperçu bien vite que le problème était isolé sur un frontal. A partir du moment ou on sait que c’est un frontal sur 3 qui provoque l’erreur, la solution rapide consiste à le retirer de la boucle de varnish le temps de voir ce qui se passe.
Et pour voir ce qui se passe, il faut pouvoir accéder au frontal comme si il était encore en prod.

Facile :
Un petit tour dans le fichier host de Windows (c:\windows\system32\drivers\etc\hosts) et on ajoute le nom de notre site avec une redirection sur localhost :  127.0.0.1   www.lenomdemonsite.com
Après on utilise putty pour se connecter à la cli en ajoutant un petit détail :puttyconftunnelIl faut donc aller dans Connection > SSH > Tunnels et ajouter un tunnel.
Globalement, on lui donne :

  • Source Port local : 80 (port http classique)
  • Destination : c’est l’ip interne du frontal sur lequel on veut taper. Ici j’ai mis au hasard 10.50.60.1:80 (il faut spécifier le port à mapper car on peut utiliser exactement le même principe pour se connecter à MySQL (3306), solr (8983), autre …).
  • On clique sur Add (faut pas oublier sinon il ne le fait pas tout seul).

L’idée c’est que le frontal n’est pas directement accessible publiquement, mais est accessible en passant par la cli, on va donc se servir du flux entre notre PC et la cli pour atteindre le frontal.
L’énorme avantage évidemment c’est que du coup il devient possible d’appeler des pages du serveur, de passer les settings en debug et de rechercher d’où vient le problème sans perturber le reste de la prod.
Et j’avoue que le deuxième avantage c’est de ne pas perdre un temps fou à tenter d’expliquer au presta infra le besoin qu’on peut avoir à accéder directement à un frontal en particulier et de faire des allers/retours pour trouver une entente.

 

février 22nd, 2015

Posted In: Developpement Web

Pour rester motivé à écrire des choses pouvant potentiellement être utiles à d’autres et aussi à moi même (c’est chouette finalement mon blog est aussi un peu mon wiki perso), je m’en vais écrire des billets sur les commandes systèmes qui me sont utiles dans ma petite vie de développeur.
Aujourd’hui j’ai voulu faire un petit test de nodejs mais comme je suis pauvre je n’ai qu’un serveur avec une debian sur laquelle je mets tout et n’importe quoi.
J’ai donc suivi la procédure d’install de nodejs pour debian (2 lignes de commandes trouvées ici https://github.com/joyent/node/wiki/Installing-Node.js-via-package-manager#debian-and-ubuntu-based-linux-distributions pour les curieux).
Et puis j’ai voulu lancer un script server.js. Et là c’est le drame, erreur, le script ne démarre pas. Je devais pouvoir y accéder via le port 8080.

Bon évidemment il suffit de changer le port et le tour est joué mais j’ai voulu savoir qui l’utilisait car je pensais n’avoir qu’un apache sur le port 80.

J’ai donc utilisé cette magnifique commande :

netstat -tulpn| grep :8080

Qui m’a permis de déterminer que j’avais gitlab qui utilisait ce port :)

 

 

février 18th, 2015

Posted In: Infrastructure et Système

Mots-clés : , ,

Page suivante »