Archives par mot-clé : php

Vagrant : Le développement sur VM

par

Nous nous sommes tous heurter à la difficulté de mettre en place son environnement de développement, surtout dans le cadre de la mise en place d’une plateforme homogène entre plusieurs postes sans ajout de logiciels tiers et le plus proche possible de l’environnement de production.

– Exemple : une plateforme PHP, MySQL, Postgres dans le cadre de la migration d’un application PHP de MySQL vers Postgres.

Au fil de mes recherches sur le net et surement avec beaucoup de retard je suis tombé sur Vagrant. (https://vagrantup.com)

Vagrant a pour but de rendre plus simple l’utilisation de machine virtuelle dans le cadre de l’environnement de développement. On peut le dire le but est atteint pour la facilité de développement entre la machine hôte et la VM.

Le plus compliqué avec Vagrant va être de créer sa propre machine proche des habitudes de développement de l’équipe. Car Vagrant n’est pas là pour cela, il est juste là pour le montage de la machine et son utilisation au quotidien.

Heureusement, la communauté est très active sur le sujet et des outils sont là pour simplifier la création de sa propre Box avec quelques connaissances. Je pense notamment à Veewee (https://github.com/jedi4ever/veewee) qui est vraiment un outil à s’accaparer pour la création de sa propre Box, n’hésitez pas à dupliquer le projet et pusher vos modifications pour mettre à disposition vos Box, c’est d’ailleurs ce que je vais faire.

Mais, ne vous inquiétez pas, je vous prépare un petit tutoriel pour l’utilisation de Veewee avec une Box en français.

Et, important à savoir tout cela, c’est en Ruby.

PHP, la serialization et les classes

par 
OTHER Error: [2] unserialize() expects parameter 1 to be string, object given
Voici l’erreur que nous avons eu sur notre site pendant un bon moment, sans réussir à la résoudre.
Il s’agit d’un formulaire de souscription banal, en plusieurs étapes, avec à chaque fois des validations nécessaires. A chaque étape, notre objet « contrat » est serializé puis enregistré dans une variable de session, que nous déserializons un peu plus loin et ainsi de suite…
Jusque là, rien de bien compliqué, c’est comme ca que marche PHP… Cependant, cette erreur est apparue… Mais uniquement sur le serveur de production, pas en environnement de développement.
Nous nous sommes donc penché sur le php.ini allant même jusqu’à comparer les fichiers ligne par ligne. la première solution que nous avons trouvé était de désérializer sur TOUTES les pages (y compris les vues donc…). Un problème se posait lorsque le client quittait l’espace de souscription… Nous n’allions tout de même pas déserializer la variable sur tout notre site…
A trop vouloir fixer des règles, on en oubli parfois le principal. On m’avait appris « Quand tu utilises les sessions, commence par le session_start()« . Très bien… On m’aurait expliqué ce que cette fonction réalisait réellement, je n’aurai peut être pas eu ce problème…
En effet, pour que la déserialization se passe correctement, il faut que lorsque la session est initialisée sur chaque page (donc le fameux session_start()), elle ait connaissance de la classe. Il faut donc inclure les classes AVANT le session_start(). Tout fonctionne très bien maintenant… (En passant, la fonction serialize() ne sert plus à rien. On peut directement écrire $_SESSION[‘****’] = $objet;)