Chapter: Install on a production server
|« Install an application||^ Installation||Migrating from jelix 1.0 to jelix 1.1 »|
− Table of content
We call production server, the server on which you will install your finished application, therefore accessible to the end-users. By opposition, the server on which you develop your application is called the development server.
There are certain different things to take in account for a production server, in order to optimize the execution of your application based on Jelix, and to protect your server.
Choosing the good edition of Jelix ¶
To develop, you use of course the "developer" edition of Jelix. This edition includes tools and scripts for the command line and other things for the development.
However, for the installation on a production server, it is preferable to install the "optimized" edition of Jelix. As its name indicates it, it is optimized, and the useless things in production are removed. Note however that your application will function exactly the same way as with one of the other editions of Jelix, except for one detail: there will be some light performance improvements with the "Optimized" edition!
If you choose to remain with the "developer" edition on your production server, there is no problem with that. However it is recommended to remove jelix command lines scripts (the whole
A "Gold" edition is also available, it is intended for the developers who can modify the php configuration, and especially install PHP extensions. Indeed, this edition uses some PHP extensions which are not available among all hosts, and this edition uses also a PHP extension especially dedicated to Jelix, which deals with certain treatments of the framework. The use of "gold" edition thus significantly improves the performances of your application. You have to compile the jelix extension yourself. Therefore, the source code of this extension is provided in the package of the Gold edition.
Installation process is identical to your development environment, including for the application.
To have better performance and more safety, here are however some additional advices.
About the server configuration ¶
- all directories, except the
wwwdirectory of your app, should be outside the document root of the web site. So you should set the root of your web site on this
wwwdirectory or move the content of www to the root of your web site. See the chapter on the application configuration for examples of such configuration.
- To specify the rights well on the
temp/your_app/directory. For example, the user which runs Apache should have write rights an this directory. It is not recommended on linux, to chmod 0777 on the temp directory ;-)
About the application ¶
Here some advices for the configuration of the application, in the
error_handling section ¶
In the section
error_handling, the following configuration is highly advised:
[error_handling] messageLogFormat = "%date%\t[%code%]\t%msg%\t%file%\t%line%\n" logFile = error.log email = root@localhost emailHeaders = "From: email@example.com\nX-Mailer: Jelix\nX-Priority: 1 (Highest)\n" quietMessage="A technical error has occured. Sorry for this trouble." showInFirebug = off ; keywords you can use : ECHO, ECHOQUIET, EXIT, LOGFILE, SYSLOG, MAIL, TRACE default = ECHOQUIET EXIT LOGFILE error = ECHOQUIET EXIT LOGFILE warning = ECHOQUIET LOGFILE notice = strict = ; for the exceptions, there is implicitly EXIT exception = ECHOQUIET LOGFILE
It is not advised to use the keyword
ECHO, which posts all the details of the errors on the website (information which could be useful for pirates), but rather
ECHOQUIET, which posts simply the message indicated in the parameter quietMessage.
However, it is useful to be informed of the errors and their details. Also, parallel to
ECHOQUIET, it is recommended to add one of these key words
LOGFILE: the errors are inserted in the file indicated in logFile.
SYSLOG: the errors are recorded on the level of the system.
Be careful with the use of
Be careful also with the use of
SYSLOG: put this option only if it is your own server (i.e. you are an administrator of the machine). Else the owner of the machine is likely not to appreciate.
LOGFILE is recommended instead of
compilation section ¶
In the section [compilation], you can deactivate the option checkCacheFiletime, and even more recommended, the option forces, if you activated it for the development.
[compilation] checkCacheFiletime = off force = off
The option checkCacheFiletime prevents Jelix from checking all the time that the cache (files generated by Jelix for the files of configurations, the DAO, templates, etc.) is up to date compared to the files in the application directory. This checking is generally useless in production, since the application is rarely modified, and each modification is usually meant to be activated as fast as possible. Of course, if you deactivate it, you should imperatively empty the directory of cache (
temp/myapp/) at each update of your application, so that your modifications are well taken into account.
mailer section ¶
Do not forget to update the parameters of the [mailer] section. Usually, the mailer parameters are different between your development server and your production server unless you use third party solutions.