Raccourcis : Contenu - rubriques - sous rubriques
EN FR

On appelle serveur de production, le serveur sur lequel sera installé votre application une fois terminée, donc accessible aux utilisateurs finaux. Par opposition, il y a le serveur de développement, celui sur lequel vous développez votre application.

Il y a certaines choses différentes à prendre compte dans le cas du serveur de production, afin d'optimiser l'exécution de votre application basée sur Jelix.

Choisir la bonne édition de Jelix

Pour développer, vous utilisez bien sûr l'édition "developer" de Jelix. Le code source de cette édition contient des instructions aidant au déboggage, pour la debugbar par exemple.

Cependant, pour l'installation sur un serveur de production, il est préférable d'installer l'édition "optimized" de Jelix. Comme son nom l'indique, elle est optimisée, et débarrassée des choses inutiles en production. Notez toutefois que votre application fonctionnera à l'identique avec l'une ou l'autre des éditions de Jelix, à un détail près : on pourra observer de légères améliorations de performance avec l'édition "Optimized" ;-).

Si vous choisissez de rester avec l'édition "developer" sur le serveur de production, cela ne posera aucun problème.

Une édition "Gold" est disponible en téléchargement, pour les développeurs qui peuvent modifier la configuration de php, en particulier, installer des extensions PHP. En effet, cette édition repose sur certaines extensions PHP qui ne sont pas disponibles chez tous les hébergeurs, mais aussi sur une extension PHP spécialement dédiée à Jelix, qui prend en charge certains traitements du framework. L'utilisation de l'édition GOLD améliore ainsi sensiblement les performances de votre application.

Configuration

Au niveau du serveur

  1. Tous les répertoires autre que le www de votre application devraient être en dehors du "document root" du site web. Voir le chapitre sur la configuration d'un serveur pour des exemples.
  2. Bien spécifier les droits sur le répertoire temp/, en particulier, que le propriétaire soit l'utilisateur qui exécute apache (ou celui de votre compte, chez certains hébergeurs) et qu'il ait les droits en écriture. Par exemple, sur linux, il n'est pas recommandé de mettre les droits 0777 sur le répertoire temp/ ;-)
  3. Idem pour les répertoires var/log/, var/mails/ etc de votre application

Au niveau de l'application

Voici quelques conseils au niveau de la configuration de l'application, donc les modifications à faire au niveau du fichier var/config/defaultconfig.ini.php .

section jResponseHtml

Désactivez le plugin debugbar.

configuration du logger

Si vous gardez l'édition "dev" en production, mettez en commentaire la ligne sql=... et peut être aussi soap=.. et autre type de log qui ne vous semble pas pertinent. Et supprimez "memory" pour chaque type de log, cela économisera de la mémoire (n'est utile que pour la debugbar).

Section compilation

Dans la section [compilation], vous pouvez désactiver l'option checkCacheFiletime, et encore plus recommandé, l'option force si vous l'avez activé pour le développement.


[compilation]
checkCacheFiletime  = off
force = off

L'option checkCacheFiletime évite à Jelix de vérifier tout le temps que le cache (les fichiers générés par Jelix pour les fichiers de configurations, les DAO, templates etc) est bien à jour par rapport aux fichiers de l'application. À priori, cette vérification est inutile en production, puisque l'application est rarement modifiée. Bien sûr, si vous la désactivez, il faudra impérativement vider le répertoire de cache (temp/votre_appli/) à chaque mise à jour de votre application , pour que vos modifications soient bien prises en compte ! (surtout quand il s'agit de modifications dans la configuration, des daos, locales, templates..)

Section mailer

N'oubliez pas de mettre à jour les paramètres de la section [mailer]. En effet, les paramètres pour envoyer des mails ne sont pas toujours identiques entre le serveur de développement et le serveur de production.

Si votre serveur est derrière un proxy

Il va falloir indiquer de forcer les ports aux valeurs standards, quand Jelix gènère des urls. Cela se passe dans la section générale :


forceHTTPPort = true
forceHTTPSPort = true

Et indiquer le vrai nom de domaine du site (sinon jelix prend le nom de domaine du serveur derrière le proxy)


domainName = www.example.com

Si le "basePath" du serveur derrière le proxy n'est pas le même que le basePath public (ex: le proxy redirige les urls http://example.com/index.php vers http://backend.example.com/foo/bar/index.php), il faut indiquer le basePath public et le basePath "backend" :


[urlengine]
basePath = /
backendBasePath = /foo/bar

Et si le proxy transforme les requêtes HTTPS en HTTP vers votre serveur web, il faut désactiver la vérification HTTPS de jelix


[urlengine]
checkHttpsOnParsing = off