Out of Plutohttps://www.outofpluto.com/blog/2019-06-28T16:52:04+00:00Une startup pluridisciplinaire qui rapproche les mondes de l’art, de la science et de la technologie.Hop-by-hop !2019-06-28T16:52:04+00:00Anthony Baillardhttps://www.outofpluto.com/blog/author/ab/https://www.outofpluto.com/blog/hop-by-hop/<p style="text-align: justify;"><img alt="Hops" src="https://www.outofpluto.com/media/uploads/hops.jpg" width="100%"/>Les en-têtes HTTP <em>hop-by-hop</em> ou "comment on découvre des informations techniques insoupçonnées et essentielles".</p>
<p style="text-align: justify;">Contrairement à ce que suggère l'illustration de cet article, les en-têtes HTTP <em>hop-by-hop</em> n'ont aucun lien avec le houblon (<em>hop</em> en anglais). C'est plutôt dans le sens de "saut" qu'il faut comprendre <em>hop.</em> Mais le houblon, c'est beau et puis ça sert à faire la bière !</p>
<p style="text-align: justify;"> </p>
<h4>La découverte (par l'erreur)<a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.6242"><br/></a></h4>
<p style="text-align: justify;">Alors,comment découvre-t-on les en-têtes point-à-point (pour utiliser la traduction correcte) ? Pour ma part, par hasard, en écrivant un proxy en Python vers un de nos services HTTP générant des pdf.</p>
<p style="text-align: justify;">Le code suivant :</p>
<pre style="text-align: justify;">response = HttpResponse(document.read())<br/><br/>for (key, value) in document.headers.dict.items():<br/> response[key] = value<br/><br/>return response</pre>
<p>provoquait systématiquement une exception :</p>
<pre>Traceback (most recent call last):
File "/home/ab/work/django/venv-django/local/lib/python3.7/site-packages/django/core/servers/basehttp.py", line 283, in run
self.result = application(self.environ, self.start_response)
File "/home/ab/work/django/venv-django/local/lib/python3.7/site-packages/django/contrib/staticfiles/handlers.py", line 68, in __call__
return self.application(environ, start_response)
File "/home/ab/work/django/venv-django/local/lib/python3.7/site-packages/django/core/handlers/wsgi.py", line 285, in __call__
start_response(status, response_headers)
File "/home/ab/work/django/venv-django/local/lib/python3.7/site-packages/django/core/servers/basehttp.py", line 373, in start_response
assert not is_hop_by_hop(name),"Hop-by-hop headers not allowed"
AssertionError: Hop-by-hop headers not allowed </pre>
<h4><br/>La compréhension (et la résolution)</h4>
<p style="text-align: justify;">Ces en-têtes, peu nombreux, s'opposent à la grande majorité des en-têtes HTTP 'end-to-end', i.e., bout-à-bout. Leur but est somme toute assez simple : éviter de transmettre sur tout la chaîne de communication Internet entre le client et le serveur des informations qui ne sont utiles que pour une connexion entre deux nœuds de la chaîne. Economiser quelques kilo octets sur chaque paquet HTTP, ça n'a l'air de rien, mais grâce à ce genre de détails qu'Internet fonctionne aussi bien à grande échelle. Les ingénieurs qui ont pensé cette architecture, ses standards et ses protocoles ont vraiment fait du bon travail, rien n'est négligé, à aucun niveau.</p>
<p style="text-align: center;"><img alt="Schéma de transfert des en-têtes HTTP" src="https://www.outofpluto.com/media/uploads/hop-by-hop.png" style="display: block; margin-left: auto; margin-right: auto; padding: 10px; border: 1px solid black;" width="80%"/><em>Les en-têtes de type </em>end-to-end<em> sont mis en cache et transférés par les proxy.<br/></em><em>Les éventuels en-têtes de type </em>hop-by-hop<em> ne sont pas mis en cache et ne sont pas transférés.<br/>De nouveaux en-têtes </em>hop-by-hop<em> peuvent être créés par le proxy.</em></p>
<p style="text-align: center;"> </p>
<p style="text-align: justify;">Après un peu de lecture sur le sujet, le message d'erreur devient très clair, mon proxy ne doit pas transférer les en-têtes point-à-point :</p>
<pre style="text-align: justify;">response = HttpResponse(document.read())<br/><br/>for (key, value) in document.headers.dict.items():<br/> if not is_hop_by_hop(key):<br/> response[key] = value<br/><br/>return response</pre>
<p style="text-align: justify;"> </p>
<h4>En savoir plus<a href="http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.38.6242"><br/></a></h4>
<p><span class="s1">Lien : <a href="https://www.freesoft.org/CIE/RFC/2068/143.htm" target="_blank">Connected Internet Encyclopedia article</a> (anglais)</span><span class="s2"><br/></span> </p>Un outil d'environnement de développement WordPress2017-09-26T11:35:32+00:00Anthony Baillardhttps://www.outofpluto.com/blog/author/ab/https://www.outofpluto.com/blog/un-outil-denvironnement-de-developpement-wordpress/<p><img alt="" src="https://www.outofpluto.com/media/uploads/wp-config.png" width="100%"/></p>
<p>Depuis un certain temps, même si nous sommes inconditionnellement fans de <strong>Django</strong> (<a href="https://www.djangoproject.com">https://www.djangoproject.com</a>), nous développons et maintenons plusieurs installations <strong>WordPress</strong> pour des clients. Nous avons plusieurs fois perdu du temps ou gaspiller des efforts dans l'installation ou la récupération d'une vieille installation de développement. <em>Situation intolérable !</em></p>
<p>La question était donc :</p>
<h4><em>Comment créer facilement et rapidement de nouveaux environnements de développement WordPress ?</em></h4>
<p>Tout en prenant en compte que certains plugins sont systématiquement utilisés et qu'il serait intéressant de pouvoir utiliser la même installation globale pour tester et développer en parallèle les différents thèmes et sites des clients.</p>
<p><strong>La solution ?</strong> Un script shell s'occupant de modifier les environnements de WordPress grâce à des liens symboliques depuis une seule copie d'une archive WordPress. Nous l'avons appelé <code>wp-env</code> et vous pouvez le trouver ici: <a>https://github.com/gotsunami/wp-env.</a></p>
<p><strong>Quelques explications ?</strong><br/>L'idée générale est de conserver l'intégralité des fichiers à l'exception des répertoires servant au développement : <code>wp-config.php</code>, <code>wp-config/themes</code>, <code>wp-config/plugins</code>.<br/>Pour ce faire, il faut tout d'abord suivre les étapes d'une installation normale de WordPress <a href="https://fr.wordpress.org/txt-install/" target="_blank">comme indiqué ici.</a><br/>Configurez un utilisateur MySQL et une base de données. Installez ensuite les plugins et les thèmes que vous souhaitez voir systématiquement.<br/><strong>Ceci constituera votre environnement par défaut et servira de base à tous vos autres environnements.<br/></strong>Vous pourrez à tout moment le réactiver pour le compléter ou le modifier.</p>
<p>Viens ensuite l'utilisation de <code>wp-env</code> à proprement parler.<br/>Après <code>wp-env init</code>, un répertoire <code>wp-envs</code> est créé à la racine de l'installation WordPress. Ce répertoire contiendra les différentes configurations de WordPress (et notamment <code>wp-envs/default</code>).<br/>Lors de la création de nouveaux environnements, un utilisateur MySQL est créé dans le fichier wp-config.php mais il vous faut le créer vous-même dans votre base de données.<br/>Chaque environnement possède donc un fichier de configuration <code>wp-config.php</code>, une base de données, des thèmes et des plugins distincts. Génial !</p>
<p><strong>Juste une remarque : </strong>basculer d'un environnement à l'autre peut poser quelques problèmes avec l'accès aux pages et à l'administration le temps que le cache du navigateur, les cookies et d'autres systèmes équivalents soient mis à jour.</p>
<p><strong>Compléter <code>wp-env</code> avec d'autres outils de développement ?</strong><br/>Pour notre part, nous utilisons notamment <code>git</code> pour suivre les évolutions de nos thèmes. Ce qui fonctionne très bien avec <code>wp-env</code>, en initialisant des répertoires <code>git</code> à la racine de chaque thème.<br/>Afin d'éviter les erreurs de manipulation, vous pouvez également modifier votre prompt pour vous indiquer quel est la configuration active (voir <code>prompt.bashrc</code> dans le repo du projet pour quelques idées).</p>
<p>Et pour le reste, il y a le README !</p>
<p> </p>
<pre><code>./wp-env
Usage: ./wp-env <command> [<env_name>]<br/><br/>Available commands:<br/>- init: Create the wordpress 'default' environment.<br/><br/>- create: Create a new wordpress environment in <env_name>.<br/> If a 'default' environment exists, the newly created environment <br/> is copied from it. Else, it is created from current WP installation.<br/><br/>- activate: Activate an existing wordpress environment.<br/><br/>- list: List the available wordpress environments.<br/><br/>- current: Display currently active wordpress environment.<br/><br/>HOW TO:<br/> 1. Start with './wp-env init'. This will create and activate a 'default' environment equal to your current working WordPress.<br/><br/> 2. Use './wp-env create <env_name>' to create a new environment copied from 'default'. Then edit './wp-envs/<env_name>/wp-env.php' if necessary. You also need to create a new database to match your new settings.<br/> CREATE database <env_name> CHARACTER SET utf8mb4<br/> GRANT ALL PRIVILEGES on <env_name>.* to <user><br/><br/> 3. Use './wp-env activate <env_name>' to load a environment<br/></code></pre>