Installer Odoo 8 sur Debian 7

Il existe plusieurs façons d’installer Odoo mais celle-ci est celle que je trouve la plus simple et ne l’ayant trouvé rédigée qu’en anglais, je vais la consigner ici au cas où un autre compatriote francophone en aurait besoin. Si vous êtes sur une distribution GNU/Linux Debian, la démarche est très simple grâce à l’équipe d’Odoo qui nous fournit tout ce dont nous avons besoin dans un dépôt officiel. En tant qu’utilisateur root, voici la liste des commandes à faire:

Installation de base

# wget -O - https://nightly.odoo.com/odoo.key | apt-key add -
# echo "deb http://nightly.odoo.com/8.0/nightly/deb/ ./" >> /etc/apt/sources.list
# aptitude update && aptitude install odoo

Ces commandes se passent d’explication pour les habitués de Debian mais je tiens à les détailler pour les novices: La première ligne consiste à télécharger le fichier https://nightly.odoo.com/odoo.key qui est une clée permettant de s’assurer qu’un paquet d’installation vient bien de chez Odoo et l’ajoute à la liste des clées connues. La suivante ajoute le dépôt officiel de Odoo à la liste des dépôts Debian dans lesquels notre système est autorisé à piocher. (Attention! Les dièses (#) ne comptent pas… Par convention, ils symbolisent l’invite de commande et indiquent que l’on doit être connecté en tant que root) Attention toutefois! Ce genre d’opération est à n’utiliser qu’avec modération car si nous utilisons Debian c’est justement pour la fiabilité de leur sélection de paquets logiciels. Or, si l’on s’amuse à ajouter plein de sources, on s’expose à des risques de bugs que l’équipe Debian ne peut pas résoudre. Cependant, c’est le seul moyen pour obtenir des mises à jours régulières d’un logiciel en particulier. Usez-en donc, mais avec parcimonie. Personnellement, j’utilise un serveur virtuel dédié à Odoo, ainsi je ne crains pas d’incompatibilité avec d’autres programmes. Je tiens à préciser que cette procédure n’est pas une bidouille mais la procédure officielle de la documentation pour les systèmes Debian: https://www.odoo.com/documentation/8.0/setup/install.html#deb

Génération de PDF

A ce stade vous devriez avoir déjà un Odoo fonctionnel sur <adresse_ip_de_votre_machine:8046> Aucune configuration de base de données n’est nécessaire. Malgré tout, vous aurez certainement un message d’erreur si vous souhaitez « imprimer » un document. En effet, Odoo génère des factures et des devis en HTML et utilise un programme appelé wkhtmltopdf pour le transformer en fichier PDF. Si le programme n’est pas installé, Odoo vous prévient et vous ouvre une fenêtre avec la version HTML du document. Si le programme est installé, mais n’est pas dans la bonne version vous aurez un fichier PDF vide. Or, la bonne version n’est pas disponible dans les dépôts de Debian 7 (pas même en backport, pour ceux qui connaissent) La solution est expliquée dans cet article: http://lolierp.blogspot.fr/2014/08/installation-odoo-80-sur-debian-73.html Il faut télécharger soi-même un fichier .deb (ce que fait la commande aptitude install automatiquement d’ordinaire) et l’installer. Tout d’abord on installe deux paquets nécessaires mais disponibles dans les dépôts Debian dont a besoin wkhtmltopdf:

# aptitude install xfonts-base xfonts-75dpi

Ensuite, si vous êtes sur une architecture 32bits:

# wget http://sourceforge.net/projects/wkhtmltopdf/files/0.12.2.1/wkhtmltox-0.12.2.1_linux-wheezy-i386.deb
# dpkg -i wkhtmltox-0.12.2.1_linux-wheezy-i386.deb

Sinon, si vous êtes sur une architecture 64bits:

# wget http://sourceforge.net/projects/wkhtmltopdf/files/0.12.2.1/wkhtmltox-0.12.2.1_linux-wheezy-amd64.deb
# dpkg -i wkhtmltox-0.12.2.1_linux-wheezy-amd64.deb

(pour le savoir, tapez uname -m, si cela affiche « x86_64 », vous êtes en 64bits) Là encore, ce n’est pas une bonne pratique. Mais c’est la solution la plus simple si vous souhaitez pouvoir générer des fichiers PDF.

Conclusion

A supposer que vous puissiez vous passer de la génération de PDF, vous disposez maintenant d’une méthode assez simple, qui tient en 3 lignes, pour installer un Odoo fonctionnel. C’est suffisant si vous souhaitez faire quelques tests ou utiliser Odoo sur votre réseau local. Mais attention! Quelques opérations supplémentaires de sécurisation sont nécessaires pour une installation accessible en ligne. Celles-ci feront l’objet d’un autre article.

Comment se débarrasser des gateway timeout de Odoo

Si vous avez installé le superbe ERP libre qu’est Odoo, vous l’avez peut-être installé derrière un proxy Nginx afin de pouvoir utiliser le chiffrement SSL. Et comme moi vous avez peut-être été frustré de tomber sur des erreurs 504 (Gateway Timeout).

Ce problème est particulièrement gênant car, lorsque l’on souhaite installer un module tel que celui de comptabilité/finance, l’assistant d’installation est interrompu et même si l’installation se termine correctement la configuration automatique de certains paramètres ne peut pas se faire. On doit alors la terminer à la main. (Pratique lorsque l’on est débutant!)

Étant plus habitué à configurer des serveurs Apache que Nginx, j’ai galéré un moment. Mais j’ai finalement réussi à trouver une solution sur serverfault.com. Il suffit de rajouter les lignes suivantes dans le fichier /etc/nginx/nginx.conf, dans la section http:

http {
...
proxy_connect_timeout 600s;
proxy_send_timeout 600s;
proxy_read_timeout 600s;
fastcgi_send_timeout 600s;
fastcgi_read_timeout 600s;
...
}

Ces paramètres étendent la patience d’nginx à 10minutes ce qui est plus que suffisant.

A noter que comme les fichiers situés dans /etc/nginx/sites-enabled/ sont inclus dans la section http du fichier /etc/nginx/nginx.conf, vous pouvez insérer ces lignes directement en tête de votre fichier /etc/nginx/sites-enabled/mon_fichier_de_configuration.conf si vous en avez créé un (même si ce n’est pas très logique étant donné qu’il s’agit d’une configuration globale que vous insérez alors dans un fichier de configuration spécifique)

Pourquoi mon .phar ne fonctionne pas

Introduction

Les « PHP Archives »  alias « PHAR » introduites dans PHP depuis 2006 peinent toujours à se démocratiser. Et pour cause! Documentation succincte,  peu de projets porteurs… Cependant certains utilitaires PHP utilisant ce format de fichier commencent à voir le jour tels que Composer ou PHPMetrics.

Si vous avez commencé comme moi à vous pencher sur ce type de fichier, vous avez sûrement pu vous retrouver face à un problème très frustrant: ça marche en local mais pas sur le serveur. Et bizarrement aucun message d’erreur n’apparaît. Le script s’arrête net!

Méchant Suhosin!

Il peut y avoir différentes raisons à ce problème mais celle qui peut nous faire perdre le plus de temps est celle du patch « Suhosin« .

Suhosin est un patch de sécurité pour PHP qui peut, lorsqu’il est actif, interdire l’exécution d’un fichier PHAR. Bloquant ainsi l’exécution du script au moment où l’on importe le fichier.

La solution à ce problème est de rajouter la ligne suivante au fichier de configuration de Suhosin (/etc/php5/cli/conf.d/suhosin.ini pour Debian):

suhosin.executor.include.whitelist = phar

Si vous n’utilisez votre_fichier.phar qu’en tant que script indépendant, vous pouvez l’exécuter avec la commande suivante:

$ php -d suhosin.executor.include.whitelist=phar votre_fichier.phar

Identifier le problème

Si vous avez un doute, vous pouvez tenter l’installation de composer avec la commande suivante (nécessite d’avoir curl d’installé) :

curl -sS https://getcomposer.org/installer| php

Dans le pire des cas, vous vous retrouverez avec un fichier composer.phar à supprimer dans le dossier courant, ce qui signifiera que votre bug n’est pas lié à Suhosin. Dans le meilleur des cas, un message d’erreur vous indiquera les éventuels problèmes de compatibilité de votre système.

Conclusion

Voilà, j’espère que ce billet vous aura fait gagner un temps précieux que je regrette moi-même d’avoir perdu sur ce genre de bêtise, mais c’est en forgeant que l’on devient forgeron…

Vous pouvez aussi en apprendre plus sur la création d’archives .phar grâce à l’excellent  article d’Abdullah  Abouzekry: Packaging your apps with phar

Editer des fichiers Word®©™ avec PHP

S’il est bien une erreur de la nature que j’aimerais voir disparaître du net, c’est bien ce foutu format « Word »! Pourtant, même si cela fait un moment que l’OpenDocument est devenu une norme ISO et que même Microsoft s’est résigné à rendre sa suite Office compatible avec ce format libre, il restera toujours des gens pour nous demander des CV en .doc ou nous envoyer du contenu à intégrer à partir d’un .docx ou d’un .xls.

A cause de cela, l’import automatisé de document bureautique dans les plateformes web tournant sous PHP a toujours été un véritable casse-tête à mettre en place!

Cependant, il se pourrait que cela change grâce au projet PHPOffice : une suite de bibliothèques permettant la lecture et l’écriture de document bureautiques dans les formats Microsoft mais aussi dans des formats libres.

Hélas, tout n’est pas encore fonctionnel et il reste encore pas mal de développement pour bénéficier de toutes les fonctions avancées. Mais pour l’avoir déjà utilisé dans un projet, je dois dire que les fonctions de base me rendent déjà un grand service.

Comment développer sous GNU/Linux tout en épargnant son système

Avant, il y avait ceux qui compilaient tout, tout le temps. Pour avoir la dernière version de tel ou tel logiciel ou juste par habitude. Puis il y a eu ceux qui ne juraient que par le système de gestion de paquets de leur distribution (j’en fais partie). Le résultat, c’est que dans un cas ou dans un autre, si l’on est développeur et que l’on a tendance à travailler sur des projets en PHP, Python, Ruby ou autre… On se retrouve avec des incompatibilités et des problèmes de dépendances car notre système peut très bien exploiter une bibliothèque qui n’est pas la même que celle sur laquelle on développe. Heureusement il y a des solutions pour chaque langage et je mettrai ce post à jour au fur et à mesure de mes découvertes sur le sujet.

Ruby et Gem

Le premier qui m’a vraiment mis le boxon sur mon système Ubuntu! Car j’ai tendance à utiliser différents outils codés en ruby et qui ne sont pas forcément à jour dans les dépôts de la distribution. Quand il m’est arrivé de vouloir  installer des versions plus récentes en utilisant le gestionnaire de paquet gem en tant que sudo, je me suis retrouvé avec quelques petits problèmes à devoir régler. Rien de bien méchant, mais quand il s’agit d’aller trifouiller dans les fichiers de la distrib en tant que root, ça sème toujours un petit doute sur la stabilité du système après coup. Et, en ce qui me concerne, ça me dérange. Heureusement, il y a une solution très simple pour installer des programmes et bibliothèques en ruby via gem en tant que simple utilisateur. Un exemple avec l’installation de vagrant :

Avant

sudo gem install vagrant

Après

gem install --user-install vagrant

Cela va installer le logiciel vagrant dans un répertoire .gem dans votre dossier personnel. Pour lancer l’exécutable il suffit alors de le lancer à partir du dossier ~/.gem/ruby/1.9.1/bin

Python et PiP

Il y a des programmes vraiment très pratiques en python tels que flickrbackup qui permet de rapatrier automatiquement les photos de son compte flickr sur sa machine. Ou bien youtube-dl qui permet de télécharger une vidéo youtube sur sa machine pour pouvoir la voir dans un vrai lecteur vidéo plutôt que de se farcir les écrans de type : « vous n’avez pas la bonne version de flash ». Le premier étant très jeune il y a beaucoup de fonctionnalités qui sont ajoutées sur le dépôt des programmeurs par rapport à la version proposée sur Ubuntu. Pour le deuxième, on se retrouve souvent avec des vidéos qui n’arrivent pas à être téléchargées car Youtube – évidemment –  ne facilite pas le travail et doit surement modifier la structures de ses pages régulièrement pour éviter l’utilisation de ce genre de programme. Dans tous les cas il devient intéressant d’avoir une version toujours à jour, et cela se fait en utilisant PiP. L’usage est très proche de celui de gem:

Avant

sudo pip install flickrbackup

Après

pip install --user flickbackup

Les exécutables se trouvent alors dans ~/.local/bin/

PHP et Composer

(en cours de rédaction)

NodeJS et NPM

(à venir)

Déboguer l’envoi d’e-mails sur un serveur Linux

L’envoi d’e-mail à partir d’une application web est généralement un processus très compliqué à déboguer. L’accès au serveur d’envoi de mail est supposé être restreint aux serveurs de production (donc injoignable depuis un serveur de développement) et quand bien même ce ne serait pas le cas, il reste toujours cette épée de Damoclès au dessus de nos têtes, nous rappelant qu’au moindre faux pas, un mail ayant pour contenu « tu vas marcher saloperie? » pourrait être envoyé à des gens haut-placés chez le client.

Chers amis, n’ayez plus peur! Une simple ligne de commande et les bibliothèques python vont vous sauver :

# python -m smtpd -n -c DebuggingServer localhost:25

Si vous ne pouvez pas lancer ce script en tant que super-utilisateur, il vous faudra utiliser un port supérieur à 1024. Par exemple :

$ python -m smtpd -n -c DebuggingServer localhost:25000

(Je rappelle que, # et $ sont la marque du prompt et ne font pas partie de la commande)

Si vous avez les bonnes bibliothèques python d’installées, cette commande va instancier une classe DebuggingServer qui va afficher dans la console tous les mails qui lui seront transmis, au lieu de les envoyer aux destinataires.

Il vous suffit donc de faire pointer la configuration de votre application sur le bon hôte et le bon port (au besoin, adaptez la commande pour choisir autre chose que localhost) et tous les mails qu’enverra votre application se retrouveront affichés dans votre terminal.

Evidemment, vous pourrez agrémenter cette commande d’une redirection de sortie pour écrire dans un fichier :

$ python -m smtpd -n -c DebuggingServer localhost:25000 >> emails.log

Pour information, j’ai tout piqué sur cette page-ci : https://muffinresearch.co.uk/fake-smtp-server-with-python/

Installer un serveur de messagerie instantanée sur un RaspberryPI

En entreprise, la confidentialité des échanges est primordial. Or comment être sûr de celle-ci lorsque l’on passe par MSN, Facebook, Skype ou autre pour échanger en temps réel avec ses collègues? Pourtant s’affranchir de ces services ne représente pas un investissement colossale. Il suffit d’un RaspberryPI à 30€ et de 10 minutes.

Ce tutoriel n’est qu’un premier pas dans l’installation et l’administration d’un serveur de messagerie. D’autres suivront pour avoir une installation complète mais j’ai préféré décrire ici le chemin le plus court pour commencer à discuter avec des amis ou des collègues en dehors de tout réseau privateur.

Installation de ejabberd

En partant d’une installation de Raspbian standard, connectez-vous avec l’utilisateur pi et tapez les commandes suivantes :

$ sudo aptitude install ejabberd

(Si vous ne l’avez pas fait depuis longtemps, n’oubliez pas de taper sudo aptitude update d’abord)

Cette commande va installer le serveur ejabberd. Il s’agit d’un serveur de messagerie instantanée implémentant le protocole XMPP. La particularité de ce protocol, outre le fait que ce soit un standard ouvert (ce que ne sont pas MSN ou Skype), est de permettre à des comptes enregistrés sur différents serveurs de communiquer entre eux. Tout comme pour les e-mails, bob@toto.fr peut dialoguer avec alice@tata.com sans avoir à s’inscrire sur tata.com (cette fonctionnalité fera l’objet d’un autre tutoriel)

Il existe différents serveurs XMPP mais ejabberd étant présent dans les dépôts raspbian, il est très rapide à installer. Libre à vous d’en utiliser un différent.

La première étape est de créer un nouvel utilisateur que l’on nommera administrateur du service.

Création d’un premier utilisateur

Pour créer un utilisateur, on utilise la commande suivante:

$ sudo ejabberdctl register <user> <host> <password>

En premier lieu vous pouvez donc taper:

$ sudo ejabberdctl register toto localhost monpass

Ensuite éditez le fichier /etc/ejabberd/ejabberd.cfg (je pars du principe que vous savez éditer un fichier)

et cherchez

%% Admin user
{acl, admin, {user, "", "localhost"}}.

Et modifiez-la en conséquence:

%% Admin user
{acl, admin, {user, "toto", "localhost"}}.

Redémarrez le serveur via la commande suivante :

$ sudo service ejabberd restart

Vous pouvez dès à présent vous connecter à l’interface d’administration à partir d’une autre machine à l’aide de n’importe quel navigateur web via l’URL: http://adresse_de_votre_raspberry:5280/admin mais pour l’instant, nous ne l’utiliserons pas vraiment.

Vous pouvez aussi installer un logiciel client comme Pidgin sur n’importe quelle machine et y ajouter un compte.

Les informations de compte à préciser sont les suivantes :

Protocole: XMPP
Utilisateur: toto
Domaine: localhost
Mot de passe: monpass
Serveur: <adresse_de_votre_raspberry>

Normalement Pidgin vous demande d’accepter un certificat. En effet lors de l’installation de ejabberd un fichier /etc/ejabberd/ejabberd.pem est créé (vous évitant au passage d’avoir à le faire vous même). Comme il n’a été validé par aucun organisme, Pidgin n’y fait pas confiance et vous demande votre avis. Ce n’est pas le cas de tous les logiciels de messagerie instantanée. D’autres refusent catégoriquement de fonctionner sans autre forme de procès. Donc réjouissez-vous du travail des développeurs de Pidgin et acceptez le certificat.

Ajouter d’autres utilisateurs

Normalement, vous devriez être connecté maintenant, mais vous êtes tout seul. Réutilisez la commande de création de compte pour ajouter de nouveaux utilisateurs sur votre serveur. Comme nous l’avons vu, la commande nécessite de fournir un mot de passe à l’utilisateur lors de sa création. Prenez bien garde à considérer ce mot de passe comme un simple mot de passe temporaire! Une fois connectés, vos amis pourront le changer via Pidgin dans le menu « Comptes ».

Pour ajouter un ami « titi » à votre liste de contact il suffit de cliquer sur Contact>>Ajouter un contact et entrer titi@localhost.

Configurez votre parefeu

Si vous et vos contacts êtes tous en local, tout devrait déjà fonctionner correctement. Si vos contacts sont à l’extérieur de votre réseau, il faudra configurer le NAT de votre « bidulebox » ou routeur en tout genre pour faire pointer le port 5222 sur l’adresse ip locale de votre raspberry. Je vous laissez le soin de vous renseigner sur la marche à suivre pour configurer votre NAT.

Conclusion

Il nous reste pas mal de choses à voir pour disposer d’un système de messagerie instantanée digne de ce nom. Pour l’instant nous avons des comptes en <user>@localhost, au lieu de <user>@maboiteamoi.com, nous n’avons pas vu comment connecter notre système à celui de nos partenaires, ou faire de la visioconférence et échanger des fichier. Tous ces points feront l’objet d’autres articles.

Pour l’heure, il vous est déjà possible d’échanger en direct avec vos collègues sans dépendre d’un système externe, privateur et opaque.

Nota bene: cet article est orienté pour le RaspberryPI mais la procédure est évidemment identique à peu de chose près avec n’importe quelle distribution GNU/Linux proposant ejabberd dans ses dépôts.


Installer un serveur de messagerie instantanée sur un RaspberryPI par Charles-Edouard Coste est mis à disposition selon les termes de la Licence Creative Commons Paternité – Pas de Modification 3.0 France

Licence Creative Commons

Développer en Qt sous Ubuntu

Bien qu’il existe des paquets pour installer QtCreator et plein de bibliothèques de développement pour Qt, il peut arriver que l’on souhaite utiliser une version plus récente que celle proposée par sa distribution.

Par exemple, à l’heure où j’écris ces lignes, il n’est pas vraiment possible de tester le développement d’applications pour Android (disponible à partir de Qt 5.1) si l’on se limite aux dépôts officiels d’Ubuntu.

De plus, il existe différentes variantes du SDK de Qt. Pour ce qui est de toutes les variantes, je ne saurais vous dire comment faire mais pour le kit officiel et celui de Nokia, j’ai essuyé les plâtres pour vous.

En premier lieu, il suffit de télécharger le fichier correspondant au SDK que vous souhaitez. Il peut être pour Linux, Windows ou MacOS; pour un processeur 32bits (x86) ou 64bits (x86_64); avec tout dans un fichier (offline) ou avec une installation par le réseau (online); et pour du développement standard ou android (a priori les versions pour android sont des versions standards avec des modules en plus).

Pour installer le kit, on donne les droits d’exécution au fichier et on l’exécute :

$ chmod +x ./qt-linux-opensource-5.2.0-rc1-android-x86_64-offline.run
$ ./qt-linux-opensource-5.2.0-rc1-android-x86_64-offline.run

Alors pourquoi avoir écrit un billet sur le sujet si c’est aussi simple?

Et bien pour deux raisons:

La première, étant de rassurer ceux qui comme moi sont réticents à installer des applications en *.run plutôt que de passer par le système de paquets. N’ayez pas peur! La version officielle comme la version de Nokia s’installe sans besoin des droits root, dans un dossier dont vous choisirez le chemin lors de la procédure d’installation.
Il n’y a donc pas de conflit avec votre environnement global ni avec d’autres SDK.

Le deuxième raison est que, sous Ubuntu, j’ai galéré un moment pour pouvoir installer la version de Nokia à cause de bugs graphiques dans l’assistant d’installation (liés à l’interface Unity, semble-t-il). Si cela vous arrive aussi, sachez que vous pouvez lancer l’installation avec un style graphique différent. Par exemple le style « motif », plus sommaire mais qui pose moins de problèmes.

Auquel cas, la commande à taper ressemblera à ça:

$ ./QtSdk-offline-linux-x86_64-v1.2.1.run -style motif

Par ailleurs, avec la version officielle, j’ai eu quelques messages d’erreurs me proposant « retry », « ignore » et « abort » mais rien de bien méchant visiblement. Il m’a suffit de cliquer à chaque fois sur « retry » pour que la procédure se poursuive et à première vue, tout semble fonctionner correctement.

Nota bene: Pour lancer QtCreator il vous faudra aller chercher l’exécutable. A partir du dossier d’installation, il vous faudra donc exécuter ./Tools/QtCreator/bin/qtcreator pour le SDK officiel et ./QtCreator/bin/qtcreator pour celui de Nokia


Développer en Qt sous Ubuntu par Charles-Edouard Coste est mis à disposition selon les termes de la Licence Creative Commons Paternité – Pas de Modification 3.0 France

Licence Creative Commons

Extraire la palette de couleur d’un CSS

Que cela soit pour réaliser une documentation ou pour optimiser son code en fusionnant les couleurs proches, il peut s’avérer utile (voir indispensable) de se munir d’un outil permettant d’extraire la liste des couleurs utilisées dans un fichier CSS.

Vous êtes donc peut-être déjà tombé sur le HexTractor de CorvidWorks. Le problème de ce dernier est qu’il ne prend pas en charge les couleurs RGBA (RGB avec transparence).

Sachez donc qu’il existe un autre outil du même type: le CSS Color Palette Extractor de Maurice Svay. Et pour ceux qui voudraient pouvoir changer la mise en forme de cette palette, sachez que le code est tout simplement ici: https://github.com/mauricesvay/css-color-palette-extractor libre à vous de l’adapter selon votre bon plaisir.

Debug, emails, et eZPublish

Ca y est! Vous avez mis en production votre site sous eZ Publish !

Comme tout site web digne de ce nom, vous avez intégré whatmille connecteurs pour envoyer des emails à tire larigot du genre « bienvenue chez nous », ou « votre mot de passe a été réinitialisé ».

Et là, c’est le drame!

Pour développer une nouvelle fonctionnalité vous devez faire une copie de la base de données de production sur votre environnement de développement. Forcément, vous entrez alors en catatonie, et ne pouvez vous résoudre à tester la moindre fonctionnalité de peur que les utilisateurs se mettent à recevoir des infos bizarres dans leur boîte mail et ne commencent à contacter votre client.

Voici la solution

Si vous jetez un œil dans le fichier settings/site.ini vous decouvrirez dans le groupe [MailSettings] deux lignes de configuration fort intéressantes:

DebugSending=disabled
DebugReceiverEmail=

Il suffit donc de rajouter dans le fichier settings/override/site.ini.append.php de votre environnement de dev :

[MailSettings]
DebugSending=enabled
DebugReceiverEmail=monadresse@mondomaine.tld

Ainsi, tous les mails envoyés via l’API d’eZ Publish seront modifiés pour être envoyés à monadresse@mondomaine.tld


Debug, emails, et eZPublish par Charles-Edouard Coste est mis à disposition selon les termes de la Licence Creative Commons Paternité – Pas de Modification 3.0 France

Licence Creative Commons

"Quand on fait tout pour que ça plante… faut pas s'attendre à ce que ça fonctionne…"