Tag Archives

24 Articles
Mon retour sur le passage de PHP à Node.js

Mon retour sur le passage de PHP à Node.js

Cela fait maintenant depuis le mois de mai (si je me rappelle bien) que je travaille sur un projet Node.JS en lieu et place du PHP. Et cela fait un bout de temps que je me dis que je dois faire un article sur les différences entre ces deux technologies WEB. Ainsi que mon retour sur cette dernière.

Avant d’aller plus en avant, je tiens à préciser à quoi nous sert Node.JS au travail : Créer une API complète (comme l’api twitter). Nous ne nous servons donc pas du tout de Node.JS pour la partie templating.

PHP, Node.JS, qu’est-ce que c’est ?

PHP

PHP est arrivé comme une technologie novatrice au début des années 2000 comme étant le langage dans le vent grâce aux choses suivantes :

  • C’est un langage interprété à la différence du C++ ou du JAVA qui nécessitent de compiler les sources pour fonctionner.
  • Il a la particularité d’être utilisé directement au sein des pages HTML grâce aux balises <?php ?>.
  • Il utilise la programmation procédurale qui est plus facile à apprendre que la programmation orientée objet.
  • Il n’est pas typé et il n’y a pas besoin de déclarer les variables avant de s’en servir.

Depuis, le langage PHP a fait son petit bout de chemin:

  • On peut installer des packages au sein de ses projets avec Composer (compatible PHP 5.3.2+).
  • On peut développer en Objet et utiliser des Designs Patterns comme le Pattern MVC grâce à différents Frameworks (Zend, CakePHP, Laravel, …).

Malgré toutes ces améliorations et l’engouement assez fort, PHP est sujet à de nombreuses vulnérabilités (Injections SQL, …) et il n’a pas de réel gestionnaire de paquets (Composer est un projet indépendant et a été inspiré par le gestionnaire NPM de Node.JS). Il n’y a pas une réelle API au sein de PHP et les performances ne sont pas toujours au rendez-vous.

De plus, de meilleures alternatives ont fait leur apparition pour le web :

  • Ruby on Rails
  • Django
  • Node.JS

Node.JS

Cette technologie est assez jeune (environ 2 ans si je ne me trompe pas), et apporte des choses innovantes (comme pour PHP à l’époque)’

  • Il permet d’exécuter du JavaScript côté serveur en utilisant le moteur de Google : Google Chrome V8 engine.
  • Il intègre nativement un gestionnaire de packages : NPM. Ce gestionnaire permet d’installer des modules soit en global, soit dans un projet.
  • Les modules Node.JS globaux apportent le plus souvent des commandes système supplémentaires. Par exemple : lancer la conversion du Less vers le CSS ou la création d’un projet express directement hiérarchisé.
  • Vous pouvez créer vos modules en code natif (C/C++) et en JavaScript.
  • Il peut faire office de serveur web sans passer par Apache ou Nginx. Mais ces derniers peuvent être nécessaires si vous voulez accéder à différents projets Node.JS sur le même port (80 et 443 par exemple) ou pour utiliser les noms de domaine.
  • Il ne bloque pas les entrées/sorties grâce à l’asynchrone du JavaScript (je n’arrive pas à mieux tourner cette phrase). Ce qui permet un gain notable des performances.

J’ai oublié certainement d’autres points importants, mais ici, je ne cherche pas à montrer tout ce qu’apporte Node.JS, mais quelles sont les choses les plus notables qu’il apporte.

C’est une technologie assez récente et bas niveau. Est-ce que dans 10 ans une autre technologie va aussi le supplanter? Possible, mais nous n’y sommes pas encore.

Comparatifs

Certains d’entre vous sont friands de comparatifs en tout genre, voici les principaux listés ici:

Mon retour

Contexte

Il faut savoir que, comme dit en introduction, j’utilise Node.js uniquement comme API RESTFul. Pourquoi ce choix? Car une API permet d’avoir différents points d’entrée et permet un plus grand large choix de technologies pour ce qui va « consommer » l’API.

Dans mon cas, je n’utilise pas du tout le moteur de templating fourni par NodeJS. Je laisse cette partie au projet de frontend. Node.js permet, grâce à express, d’effectuer des retours JSON avec une facilité enfantine.

Ensuite, notre API est RESTFul. Malheureusement, express ne suffit pas pour répondre à ce besoin. De plus, nous préférons utiliser un pattern structuré tels que le pattern MVC pour nos projets. Locomotive.js est parfait pour répondre à ce besoin.

Et pour finir, le passage à Node.JS seul ne suffit pas, un petit passage de MySQL vers MongoDB s’est avéré utile. Ça répondait à nos besoins puis les résultats de MongoDB sont directement utilisables par Node.JS vu que ce sont des objets/tableaux JSON.

Retour d’expériences

Le plus dur je trouve avec le passage de PHP à Node.js est ce principe d’asynchrone. Dès que vous appelez une fonction avec un callback, il faut bien penser à chaque cas de retour sans en omettre un seul sous peine de se retrouver avec la requête bloquée en attente d’une réponse.

De base, Node.js met en cache tout votre projet avant de l’exécuter. Vous devrez donc penser à bien le relancer après chaque modification de votre code. J’ai eu l’air fin à chercher pendant 15 minutes pourquoi mes modifications n’étaient pas prises en compte.

Sinon, en soi, Node.js est vraiment un plaisir à utiliser. Bien entendu, c’est du JavaScript et sans rigueur, on peut très très vite se retrouver avec du code sale.

Dernier point. Pour les développeurs sous Windows : changez d’OS. La plupart des modules utilisant des librairies natives ne fonctionnent pas chez vous et la ligne de commande étant quand même assez utilisée et aux vues de votre console assez préhistorique, je vous conseille de développer sous Linux ou Mac.

Utilisation de Zend REST : Partie 2

Utilisation de Zend REST : Partie 2

Comme promis, voici la partie 2 du tutoriel sur Zend REST. Dans celui-ci, nous allons aborder les choses suivantes :

  • Création et Utilisation d’une APIKEY
  • Utilisation des différentes méthodes http et test des retours JSON avec CURL.
  • Mise en place de codes retours http pour dire s’il y a eu une erreur ou non

Sachez que ce tutoriel est le dernier concernant Zend REST. Le prochain touchera à l’accès sur notre plateforme REST via Android.

I- Création et utilisation d’une APIKEY :

1 – Introduction :

L’APIKEY sert aux utilisateurs à s’authentifier sur votre application simplement, sans avoir quelque chose à taper. Vous pouvez avoir une APIKEY globale (ce que l’on va voir ici), une par utilisateurs, une par plateforme ou un mélange de tout ceci à la fois. A vous de voir ce qui vous convient le mieux. Pour notre exemple, nous allons choisir le plus simple, une APIKEY gobale. Si la requête n’est pas envoyée avec cette APIKEY, elle renverra une erreur. L’APIKEY de notre example sera la suivante :

6a0071dbe561c89581c56d1ecf3a4f54

Pour ceux qui aimeraient savoir ce que c’est, cette APIKEY n’est qu’un simple MD5 de throrinstudio. 

2 – Mise en place :

Maintenant, il faut peut-être dire à Zend que nous voulons utiliser cette APIKEY et, si elle est mauvaise, refuser la requête. Nous allons donc créer un plugin pour notre Controller. Si vous ne savez pas ce que c’est, voici un petit rappel de la documentation :

L’architecture MVC de Zend Framework propose l’injection de plugins de code, qui vont intervenir à différents niveaux dans le processus complet. Le contrôleur frontal enregistre des plugins, et utilise un gestionnaire de plugins (« plugin broker »), qui va se charger de faire intervenir chaque plugin, à chacun des instants clés à votre disposition.

Donc, nous allons créer le plugin RestAuth suivant :

class App_Controller_Plugin_RestAuth extends Zend_Controller_Plugin_Abstract{

    public function preDispatch(Zend_Controller_Request_Abstract $request)
    {
        $apiKey = $request->getHeader('Api-Key');

        //on récupère notre fichier de configuration
        //car notre apikey est stoquée dedans
        $config = Zend_Registry::get('config'); 


        //Si notre apikey est mauvaise alors qu'on essaie d'accéder à notre module rest et qu'on est pas sur la page d'erreur, 
        //on renvoie vers la page d'erreur
        if($apiKey != $config['tutorest']['apikey'] && $request->getModuleName() == "rest" && $request->getControllerName() != "error") {
            //Ici, on met le code 403 ACCES_DENIED à notre réponse HTTP
            $this   ->getResponse()
                    ->setHttpResponseCode(403);
            //Et on redirige vers le controller d'erreur
            $request->setModuleName('rest')
                    ->setControllerName('error')
                    ->setActionName('api')
                    ->setDispatched(true);
        }

    }
}

Comme on peut le voir, on redirige en cas d’erreur sur un controller d’erreur créé pour l’occasion. Voici son code :

class Rest_ErrorController extends Zend_Controller_Action{

    public function init()
    {
        $bootstrap = $this->getInvokeArg('bootstrap');
        $options = $bootstrap->getOption('resources');

        $contextSwitch = $this->_helper->getHelper('contextSwitch');
        $contextSwitch  ->addActionContext('api', array('json'))
                        ->initContext('json');
    }

    public function apiAction(){
        $this->view->error = "APIKEY is wrong";
    }
}

Et maintenant, nous allons dire à Zend de charger notre plugin pour faire le test. Nous allons l’initialiser dans le Bootstrap de notre module Rest :

class Rest_Bootstrap extends Zend_Application_Module_Bootstrap
{
    protected function _initAutoload()
    {
            $moduleLoader = new Zend_Application_Module_Autoloader(array(
            'namespace' => 'Rest',
            'basePath' => APPLICATION_PATH . '/modules/rest'));
            return $moduleLoader;
    }

    protected function _initPlugins(){
        $bootstrap = $this->getApplication();
        $bootstrap->bootstrap('frontcontroller');
        $front = $bootstrap->getResource('frontcontroller');

        $front->registerPlugin(new App_Controller_Plugin_RestAuth());
    }
}

Maintenant, si vous essayez d’accéder au site via http://votresite/rest/ vous devriez avoir le JSON suivant :

{"error":"APIKEY is wrong"}
Attention, il se peut qu’à la place vous ayez le message suivant :  Fatal error: Uncaught exception ‘Zend_Exception’ with message ‘No entry is registered for key ‘config »… Si vous avez ce message, rien de grave, c’est que vous n’avez pas initialisé la variable de registre config à partir du Bootstrap principal. Si c’est votre cas, voici la fonction à rajouter :

protected function _initConfig()
{
Zend_Registry::set(‘config’, $this->getOptions());
}

Maintenant que nous avons mis en place l’apikey, nous allons voir comment la renseigner à notre requête.

3 – Utilisation :

Pour cette partie, nous allons effectuer nos requêtes via curl en ligne de commande linux. Ici j’utilise putty connecté sur mon serveur de test. Avant de pouvoir utiliser CURL, vous devez l’avoir d’installé sur votre machine. Si ce n’est pas le cas, faites le :

sudo apt-get install curl

Ensuite pour interroger le serveur comme le fait votre navigateur, vous aurez juste à taper la commande suivante. Attention, elle vous retournera la même erreur que par le navigateur.

curl http://localhost/tutosite/rest/tuto -v

Si vous avez bien regardé le plugin de vérification de l’apiKey, vous pouvez voir que l’on récupère cette clé directement dans le header HTTP de la façon suivante :

$apiKey = $request->getHeader('Api-Key');

Nous allons donc dire à CURL de rajouter une nouvelle en-tête à la requête HTTP du nom ‘Api-Key’ et contenant notre clé :

curl http://localhost/tutosite/rest/tuto -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

En retour vous devriez avoir le bon JSON. Voilà, maintenant vous savez comment renseigner votre api-key directement dans les headers HTTP. Maintenant nous allons passer aux différents types de requête.

II- Méthodes HTTP et REST :

1 – index et GET :

C’est la méthode la plus courante pour demander une ressource. Une requête GET est sans effet sur la ressource, il doit être possible de répéter la requête sans effet. la méthode getAction() sera appelée lorsque l’on cherche à récupérer une ressource en particulier. Si nous ne demandons rien de particulier, c’est la méthode indexAction() qui est appelée à la place. Par exemple pour récupérer une liste, on va dans index, pour récupérer un livre en particulier, on va dans get. 

La commande curl précédente nous permettait d’aller dans notre méthode index. Pour accéder dans la méthode get, il suffit juste d’effectuer la commande suivante en renseignant dans le lien l’id de l’élément à chercher :

curl http://localhost/tutosite/rest/tuto/1 -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

En réponse vous devriez avoir le JSON correspondant à celui de getAction.

2 – POST :

Cette méthode doit être utilisée pour soumettre des données en vue d’un traitement à une ressource (typiquement depuis un formulaire HTML). L’URI fournie est l’URI d’une ressource à laquelle s’appliqueront les données envoyées.

Le résultat peut être la création de nouvelles ressources ou la modification de ressources existantes. À cause de la mauvaise implémentation des méthodes HTTP par les navigateurs, cette méthode est souvent utilisée en remplacement de la requête PUT, qui devrait être utilisée à la fois pour la création et la mise à jour de ressources.

Voici la commande permettant de tester le POST :

curl -d "article=myarticle"   http://localhost/tutosite/rest/tuto/ -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

3 – PUT :

Cette méthode permet de remplacer ou d’ajouter une ressource sur le serveur. L’URI fourni est celui de la ressource en question. PUT et POST pourraient être tous les deux utilisés pour effectuer la même chose. Normalement j’utilise POST pour la création et PUT pour la modification. Après à vous de voir ce que vous préférez. Voici la commande permettant de tester le PUT:

curl -d "article=myarticle" -X PUT  http://localhost/tutosite/rest/tuto/ -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54 -v

4 – DELETE :

Cette méthode permet de supprimer une ressource du serveur. Normalement, après exécution de cette requête il ne devrait pas y avoir de réponse HTTP mis à par le status HTTP. Ici nous allons avoir un retour car nous n’avons pas établis les codes retours :

curl -X DELETE  http://localhost/tutosite/rest/tuto -H Api-Key:6a0071dbe561c89581c56d1ecf3a4f54

III- Codes retours :

Afin de savoir si nos requêtes se sont bien passées ou pas, nous regarderont le code retour HTTP avant de traiter le JSON de retour. Comme cela, nous saurons s’il s’agit d’un JSON de ressources à traiter, de confirmation, d’erreur, … Pour faire ceci, nous rajouterons à chacune de nos fonction la commande suivante :

$this->getResponse()->setHttpResponseCode($code);

Nous nous baserons sur les codes retour HTTP. Ce sera plus simple pour les traiter et en même temps ça servira de piqûre de rappel pour certains 😉 :

  • 200 : Requête traitée avec succès (utilisée pour index et GET
  • 201 : Requête traitée avec succès avec création d’un document (utilisée pour PUT et POST)
  • 204 : Requête traitée avec succès mais pas d’information à renvoyer (utilisée par DELETE)
  • 400 : La syntaxe de la requête est erronée (peut être utilisée si vous passez les mauvais paramètres de recherche et/ou d’ajout)
  • 403 : L’authentification est refusée. (utilisée quand APIKEY est invalide)
  • 404 : Ressource non trouvée (peut être utilisée dans GET et PUT/POST quand la ressource à récupérer/modifier n’existe pas)
  • 500 : Erreur interne du serveur (utilisée pour toute erreur PHP ou tests invalides autre que ceux gérés au dessus)
Après à vous de décider. Je n’ai pas mis toute la liste mais seulement l’énumération et les Use Cases des principaux codes de retour.

Le code de retour 204 ne retournera aucun contenu même si vous en renseignez un. Donc pour vérifier que l’action DELETE s’est effectuée avec succès, testez juste le code de retour. Si c’est 204, tout s’est bien passé.

Conclusion Partie 2.

Dans cette partie vous aurez vu comment toucher au header HTTP, comment modifier le code de retour et comment vérifier tout ceci sous Zend. Vous aurez aussi appris à vous servur de curl en ligne de commande (peut être un tutoriel sur curl et Zend dans un prochain tutoriel ?). Avec ceci vous avez toutes les bases pour créer votre propre service REST. La prochaine fois nous verrons comment consommer ce service grâce à une application Android. Sur ce, je vous souhaite une bonne fin de semaine.

Utilisation de Zend REST : Partie 1

Utilisation de Zend REST : Partie 1

Bonjour, aujourd’hui nous allons voir comment créer un service REST avec Zend et comment signaler à Zend que nous attendons la réponse dans le format JSON.

Ce tutoriel n’est que le premier d’une série d’autres tutoriels permettant d’aller plus loin dans Zend REST à savoir :

  • Présentation de REST et configuration de Zend
  • Utilisation d’une APIKEY et des différentes méthodes HTTP
  • Utilisation de notre service REST à partir d’Android

Comme vous devez vous en douter, aujourd’hui nous allons attaquer Présentation de REST et configuration de Zend.

I- Présentation de REST :

Et nous allons commencer par une petite définition Wikipedia de ce qu’est un service REST :

REST (Representational State Transfer) est une manière de construire une application pour les systèmes distribués comme le World Wide Web.

L’application de cette architecture au Web se comprend sur quelques principes simples :

  • l’URI est important : connaître l’URI doit suffire pour nommer et identifier une ressource
  • HTTP fournit toutes les opérations nécessaires (GET, POST, PUT et DELETE, essentiellement) 
  • chaque opération est auto-suffisante : il n’y a pas d’état ;
  • utilisation des standards hypermedia : HTML ou XML qui permettent de faire des liens vers d’autres ressources et d’assurer ainsi la navigation dans l’application REST sont souvent utilisés. Néanmoins, l’utilisation d’autres formats comme JSON ou autres est possible.

Nous allons donc utiliser cette architecture afin de, au final, proposer un service Web pour une application Android. En fonction des choses demandées par notre application, nous effectuerons l’une des requêtes http existantes (GET, PUT, POST, DELETE) afin d’accéder à l’une de nos actions. Lorsqu’une action est effectuée, notre application recevra une réponse au format JSON.

II- Configuration de votre projet Zend :

Je pars du principe que vous avez un projet Zend existant et modulaire. Si vous n’avez pas cela, je vous invite à suivre ma suite de tutoriels sur Zend : Introduction au Framework Zend – Partie 1.

Nous allons placer toute la partie REST dans un module du même nom et nous allons créer le controller TutoController :

class Rest_TutoController extends Zend_Rest_Controller
{
    public function init(){
        $bootstrap = $this->getInvokeArg('bootstrap');
        $options = $bootstrap->getOption('resources');

        $contextSwitch = $this->_helper->getHelper('contextSwitch');
        $contextSwitch  ->addActionContext('index', array('json'))
                        ->addActionContext('get', array("json"))
                        ->addActionContext('post', array("json"))
                        ->addActionContext('put', array("json"))
                        ->addActionContext('delete', array("json"))
                        ->initContext('json');
    }

    public function deleteAction() {
        $this->view->retour = "deleteAction";
    }

    public function getAction() {
        $this->view->retour = "getAction";
    }

    public function indexAction() {
        $this->view->retour = "indexAction";
    }

    public function postAction() {
        $this->view->retour = "postAction";
    }

    public function putAction() {
        $this->view->retour = "putAction";
    }
}

Comme vous pouvez le voir, notre Controller n’étend pas du tout de Zend_Controller_Action mais de Zend_Rest_Controller. Ce controller marche pareil que Zend_Controller_Action à la différence près qu’il implémente chaque action utile à chaque requête HTTP.

Faire ce controller ne suffit pas à faire que Zend_Rest marche. Normalement, en saisissant simplement l’adresse suivante : http://votresite/rest/tuto et en fonction de la requête que vous avez (POST, …) vous devez tomber automatiquement sur l’action associée. Pour que Zend fasse justement le routage adéquat, nous devons le lui signaler dans le Bootstrap principal :

protected function _initRestRoute()
{
    $this->bootstrap('Request');
    $front = $this->getResource('FrontController');
    $restRoute = new Zend_Rest_Route($front, array(), array(
        'rest' => array(
                    'tuto',
                  )
    ));
    $front->getRouter()->addRoute('routerest', $restRoute);
}  

Comme vous pouvez le voir, on demande de charger la fonction initRequest de notre Bootstrap grâce à la commande 

$this->bootstrap('Request');

Et si vous essayez d’accéder à votre site, vous devriez avoir l’erreur suivante si vous n’avez pas défini la fonction initRequest :

Fatal error: Uncaught exception 'Zend_Application_Bootstrap_Exception' with message 'Resource matching "Request" not found' in ...

Pour remédier à cela, voici une la fonction initRequest que j’utilise, elle me permet d’avoir tout le temps un objet Zend_Controller_Request_Http dans mon entité $this->_request de mes controllers :

protected function _initRequest()
{
    $this->bootstrap('FrontController');
    $front = $this->getResource('FrontController');
    $request = $front->getRequest();
    if (null === $front->getRequest()) {
        $request = new Zend_Controller_Request_Http();
        $front->setRequest($request);
    }
    return $request;        
}

Bien, maintenant toute la configuration dite, de base, a été faite. Maintenant, si vous essayez d’accéder à votre action index (appelée par défaut si aucun paramètre GET et si requête de type GET), vous devriez avoir une erreur typique de vue non existante sur votre serveur. C’est normal, nous allons justement voir comment obliger un retour JSON grâce aux Contextes.

III – Les Contextes :

Afin d’expliquer ce que sont les contextes, je vous invite à lire le paragraphe associé dans la documentation Zend :

Les Contextes sont des conditions de formatage pour une ou plusieurs requêtes en fonction de leur type (requête AJAX ou non) le retour des actions appelées. Zend fournit deux aides d’action afin de nous simplifier la tâche : ContextSwitch et AjaxContext. Voici ce que nous dit justement la documentation Zend :

L’aide d’action ContextSwitch est destinée à faciliter le retour de différents formats de réponse à une requête.L’AjaxContext est une aide spécialisée de ContextSwitch qui permet le renvoi de réponses à XmlHttpRequest.

Pour l’activer, vous devez indiquer à votre contrôleur quelles actions répondent à quel contexte. Si une requête d’entrée indique un contexte valide pour une action, alors l’aide d’action en charge :

  • Va désactiver les layouts, si elles sont activées.
  • Va changer le suffixe de la vue à rendre, il faudra donc créer une vue par contexte.
  • Va envoyer les bons en-têtes de réponse en fonction du contexte désiré.
  • Va éventuellement en option appeler des fonctions pour configurer le contexte, ou des fonctions de post-processing.

Normalement, nous devons signaler dans l’url le format de retour de la requête entre JSON et XML de la façon suivante : /module/controller/action//format/<json|xml>. Je vais vous montrer comment configurer nos Contextes pour qu’ils prennent toujours le format JSON par défaut.

Vu que nous allons requêter directement via une application Android (et notre navigateur pour les tests de départ), nous allons utiliser l’aide de vue ContextSwitch. AjaxContext ne nous sert à rien ici car il regarde si la requête est une requête AJAX pour utiliser les contextes alors que ContextSwitch le fait tout le temps.

Pour ce faire, nous allons définir tout ceci dans la fonction init() de notre controller de la façon suivante :

public function init(){
    $bootstrap = $this->getInvokeArg('bootstrap');
    $options = $bootstrap->getOption('resources');

    $contextSwitch = $this->_helper->getHelper('contextSwitch');
    $contextSwitch  ->addActionContext('index', array('json'))
                    ->addActionContext('get', array("json"))
                    ->addActionContext('post', array("json"))
                    ->addActionContext('put', array("json"))
                    ->addActionContext('delete', array("json"))
                    ->initContext('json');
}

La seule contrainte de ces aides de vue, c’est qu’il faut renseigner les formats possibles pour chaque action concernée grâce à la fonction addActionContext() et nous définissons le format choisi par défaut grâce à initContext().

Maintenant, si vous allez sur votre site http://votresite/rest/tuto vous devriez avoir la réponse suivante au format JSON :

{"retour":"indexAction"}

En fonction de votre navigateur il vous sera demandé soit de télécharger un fichier JSON, soit le résultat sera affiché directement dedans.

Le retour JSON n’est qu’une sérialisation PHP vers JSON de toutes vos variables de vues. Si vous avez des tableaux, ils seront convertis en tableau JSON, des objets PHP : en objet JSON si c’est possible. Pour plus d’information, regardez comment marche Zend_JSON_Encode car c’est basé dessus.

Conclusion de la partie 1 :

Voilà, ici nous avons pu voir comment utiliser les contextes, configurer Zend pour REST. Vous pouvez dès maintenant créer une application Zend basique utilisant les contextes. Mais pour ce qui est de REST, il nous manque à voir les différentes requêtes HTTP ainsi que l’utilisation d’une APIKEY pour sécuriser à minima tout ça. Mais pour ceci, nous le verrons dans le prochain tutoriel. 

Sur ce, je vous souhaite de bonnes fêtes de fin d’année et surtout, profitez bien.

Nouveautés

Nouveautés

Bonjour à tous,

Je viens vous annoncer les prochains tutoriaux à apparaître sur le site. Tout d’abord, je pense vous parler des context sous Zend qui permettent de formater le type des actions en fonction de ce que vous voulez (JSON, HTML, Text, XML, …) et nous verrons la différence entre AjaxContext et contextSwitch qui font la même chose mais pas selon les mêmes conditions.

Ensuite, je vais certainement faire une introduction sur JQuery Mobile afin de voir ce qu’il est possible de faire ainsi que les limites. Cela fait 1 semaine que j’y passe mes journées dessus et j’ai envie de vous faire partager cette expérience.

Pour finir, une rubrique Divertissements va voir le jour. Cette section regroupe tout ce qui ne fait pas partie du développement et qui se rapproche, pour la plupart, de jeux ou de hobbies.

Sur ce, passez un très bon week-end d’Octobre de fin d’été (sisi, vu le temps qu’il fait).

Utiliser un serveur SMTP externe dans WordPress 3.2+

Utiliser un serveur SMTP externe dans WordPress 3.2+

by Throrïn 3 Comments

Bon, cet article sera fait à chaud après avoir bataillé entre WordPress et un tutoriel existant mais pas à jour. Nous allons donc voir comment utiliser un serveur SMTP externe pour l’envoi d’emails avec WordPress.

Pourquoi faire cela quand WordPress doit normalement tout gérer seul (en théorie). Et bien car parfois, il arrive qu’un serveur n’ai pas de serveur de messagerie installé. Dans ce cas, il se peut que WordPress ne vous renvoie pas d’erreur lors de l’envoie du mail et que celui-ci soit perdu avant d’avoir quitté le serveur.

Pour ce faire, il est possible de modifier le comportement de WordPress et de lui obliger de passer par un serveur SMTP externe à votre serveur Web. Après les explications de base, ouvrez votre WordPress et rendez-vous dans le dossier /wp-includes/. Nous allons enfin mettre les mains dans le cambouis.

Tout d’abord ouvrez le fichier pluggable.php et allez jusqu’à la ligne 462. Vous devriez avoir ceci :

$phpmailer->IsMail();

Nous allons la remplacer par cela :

$phpmailer->IsSMTP();

Cette modification va tout simplement changer la méthode d’envoie des mails par WordPress. Nous lui indiquons ici de passer par les réglages SMTP.

Maintenant, nous allons toucher au fichier class-phpmailer.php. Ce fichier contient la classe PhpMailer qui s’occupe d’envoyer les e-mails. Qu’allons-nous faire dans ce fichier ? Juste renseigner les informations de notre serveur. Tout ceci se déroule entre la ligne 180 et la ligne 217 :

public $Host          = 'adresse de votre serveur';

/**
 * Sets the default SMTP server port.
 * @var int
 */
public $Port          = 25; //port de votre serveur

/**
 * Sets the SMTP HELO of the message (Default is $Hostname).
 * @var string
 */
public $Helo          = ''; //perso je ne m'en sers pas

/**
 * Sets connection prefix.
 * Options are "", "ssl" or "tls"
 * @var string
 */
public $SMTPSecure    = ''; //Si vous avez besoin d'une authentification SSL ou TLS, renseignez le.

/**
 * Sets SMTP authentication. Utilizes the Username and Password variables.
 * @var bool
 */
public $SMTPAuth      = false; //Metre à true si vous devez vous identifier dessus

/**
 * Sets SMTP username.
 * @var string
 */
public $Username      = ''; //login du serveur SMTP

/**
 * Sets SMTP password.
 * @var string
 */
public $Password      = ''; //Mot de passe du serveur SMTP

Voilà, normalement avec tout ceci, vous pouvez maintenant envoyer convenablement des e-mails avec WordPress via un serveur SMTP externe.