EZpublish 4.0 sur un Pack Perso Initial 1and1
Ce site fonctionne sous EZpublish 4.0 et est hébergé sur un Pack Perso Initial de chez 1and1. Les performances ne sont pas forcément extraordinaires mais le site tourne et ca m’a permis de pratiquer un peu plus EZpublish sans dépenser une fortune en hébergement.
Voici quelques détails sur la manière dont j’ai configuré l’hébergement et installé EZpublish. Je ferai également un point sur les limitations que j’ai rencontré par rapport à la légèreté du serveur.
L’hébergement
Comme je l’ai déjà mentionné, ce site est hébergé sur un Pack Perso Initial de chez 1and1. C’est un hébergement mutualisé avec un espace disque de 2,5 Go qui fourni du PHP4 ou PHP5 / MySQL5 avec un memory_limit fixé par défaut à 40 Mo (Voir le phpinfo sans modification de la configuration). Par défaut, le PHP est exécuté en PHP4 pour les fichiers .php et PHP5 pour les fichiers .php5.
J’ai choisi volontairement d’installer EZpublish 4.0 car il est écrit en PHP5 pour des questions de ressources et de performances. Il faut donc forcer l’exécution de PHP5. On va donc commencer par mettre en place un fichier .htaccess à la racine de notre site avec la directive :
AddType x-mapp-php5 .php
Il s’agit ensuite de s’assurer que la configuration de PHP est conforme avec la configuration des hôtes virtuels recommandée sur le site EZ (Voir ez.no > Virtual host setup). Comme PHP est exécuté en mode CGI, la configuration n’est pas modifiable par le fichier .htaccess (cf. php_admin_value ou php_value) par contre, 1and1 permet de le faire au moyen d’un fichier php.ini placé à la racine du site. Ce fichier contient les valeurs suivantes :
# Voir ez.no > Virtual host setup
safe_mode = Off
register_globals = 0
magic_quotes_gpc = 0
magic_quotes_runtime = 0
allow_call_time_pass_reference = 0
# Timezone du serveur
# Permet de supprimer le message d’erreur strtotime()
date.timezone = Europe/Paris
# Augmentation du memory_limit
memory_limit = 64M
# Augmentation de la durée d’exécution des scripts
max_execution_time = 30000
# Taille autorisée pour l’upload de fichier
upload_max_filesize = 10M
post_max_size = 10M
La modification de ces différentes valeurs dépends de ce qu’autorise 1and1. J’ai par exemple fixé le memory_limit sur 64 Mo mais 1and1 précise dans sa documentation que la mémoire allouée ne peut en aucun cas dépasser 32 Mo (Voir FAQ 1and1). C'est assez étonnant puisque le memory_limit par défaut est fixé à 40 Mo. Il y a donc un léger flou sur ce point.
L’installation et la configuration d’EZpublish
Vu que la mémoire allouée pour l’exécution des scripts ne peut dépasser 32 Mo, il n’est pas possible d’installer EZpublish directement online via l’assistant. J’ai donc procédé à l’installation et au développement du site en local avant de transférer le tout sur le serveur.
Pour finir, j’ai passé un peu de temps à faire fonctionner correctement le site en mode host avec la réécriture d’URL même si cela n’est finalement pas compliqué.
Dans un premier temps, il faut compléter le fichier .htaccess en ajoutant quelques paramètres et les règles de réécriture :
Options -Indexes
Options +FollowSymLinks
DirectoryIndex index.php
RewriteEngine on
RewriteCond %{REQUEST_URI} !^/index.php
RewriteCond %{REQUEST_URI} !^/index_treemenu.php
RewriteCond %{REQUEST_URI} !^/var/storage/.*
RewriteCond %{REQUEST_URI} !^/var/[^/]+/storage/.*
RewriteCond %{REQUEST_URI} !^/var/cache/texttoimage/.*
RewriteCond %{REQUEST_URI} !^/var/[^/]+/cache/texttoimage/.*
RewriteCond %{REQUEST_URI} !^/design/[^/]+/(stylesheets|images|javascript)/.*
RewriteCond %{REQUEST_URI} !^/share/icons/.*
RewriteCond %{REQUEST_URI} !^/extension/[^/]+/design/[^/]+/(stylesheets|images|javascripts?)/.*
RewriteCond %{REQUEST_URI} !^/packages/styles/.+/(stylesheets|images|javascript)/[^/]+/.*
RewriteCond %{REQUEST_URI} !^/packages/styles/.+/thumbnail/.*
RewriteCond %{REQUEST_URI} !^/favicon\.ico
RewriteCond %{REQUEST_URI} !^/robots\.txt
RewriteRule .* /index.php [L]
RewriteRule content/treemenu/?$ /index_treemenu.php [L]
Pour finir, on force EZpublish à fonctionner en mode Virtual Host en ajoutant la directive ForceVirtualHost=true dans le fichier settings/override/site.ini.append.php
[SiteAccessSettings]
ForceVirtualHost=true
Il faut également penser à activer GD plutôt qu’ImageMagick puisque ce dernier n’est pas disponible sur ce type d’hébergement.
Limitations liées à l’hébergement
Logiquement, cette installation n’est destinée à supporter un gros trafic. Je n’ai aucune visibilité quant à la charge que mon site peut supporter mais on ne peut pas s’attendre à des performances olympiques. De plus, comme il s'agit d'une offre mutualisée, il vaut mieux se méfier des éventuels blocage liés à la consommation de ressources.
D’autre part, il n’est pas possible de vider tous les caches d’EZpublish via le backoffice. Si, à la suite d’un développement, il est nécessaire de les vider tous, il faut le faire par FTP. Il y a également fort à parier qu’il soit nécessaire de relancer plusieurs fois le site jusqu’à ce qu’il ait reconstruit les caches.
Toujours au chapitre des caches, les {cache-block subtree_expiry=…} ne fonctionnent pas sur mon site. Cela ne semble pas être en rapport avec une mauvaise utilisation. Je creuse, sans succès pour le moment.
Le redimensionnement des images ne fonctionne pas sur de gros fichiers ou sur un nombre important d’images dans une même page. Pour des raisons de performances, les galeries du site sont donc générées totalement offline. Les photos sont uploadées dans les différents formats et non pas redimensionnées à la volée par EZpublish.
Avoir recours à ce type d'hébergement me semble donc approprié pour mettre en ligne un site qui n'a pas vocation à accueillir un trafic intense, à avoir une grande quantité de contenus (ressources, espace disque et taille de la base MySQL) ou encore nécessitant l'utilisation du cron. Ce n'est pas mon cas, puisque ce site me sert surtout à m'amuser. Cet hébergement me convient donc parfaitement pour le moment.
