Chapter: Configuring a production server
|^ Deploying a Jelix application||Installing an application »|
− 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.
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. See the chapter about the server configuration for examples of such configuration.
- Specify the good rights on the
temp/directory. For example, the system user which runs Apache or PHP-FPM (or the user of your hosting account) should have "write" rights on this directory, and nobody else. It is not recommended on linux, to chmod
0777on the temp directory for example ;-)
- Same rights on directories like
var/mails/etc.. of your application.
About the application ¶
Here some advices for the configuration of the application, in the
section jResponseHtml ¶
Deactivate the debugbar plugin if it is activated in your main configuration.
configuration du logger ¶
Unless you want to log all SQL queries and SOAP requests (it may generates huge log files!),
remove the line
soap=... and other type of log that you think it isn't
relevant. And remove the logger "memory" in each type of log. It will save some
memory and the "memory" logger is only useful for the debugbar.
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. You should also activate the option
[compilation] sourceFileResolutionInCache = on 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.
sourceFileResolutionInCache avoid for Jelix to search the
source file to compile at each requests. Some kind of file, like template,
can be stored in different directories, and searching into all these directories
may take time.
Of course, if you configure these options as indicated,
you should imperatively empty the directory of cache (
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.
If your server is behind a reverse proxy ¶
In some networks, the web server that run Jelix is behind a reverse-proxy (a load balancer, HaProxy or an other web server configured as a reverse-proxy like Nginx). So the web server is not configured as a frontal web server: it hasn't the domain name of the web site, it may not listen on standard port or the reverse proxy communicate HTTPS request as HTTP request to the web server, etc.
In this case Jelix may not have the ability to guess the real domain name,
the http port, the protocol etc, and so may generates wrong URLs. (It
does not support yet headers like
that some reverse proxy may communicate to the web server).
If your server is not listening on a standard port (80 or 443), you should indicate to jelix that it should generate urls with standard port (for the proxy). In the general section:
forceHTTPPort = true forceHTTPSPort = true
And you should probably indicate the real domain name of the site (so the domain name of the reverse-proxy), else Jelix uses the web server name.
domainName = www.example.com
If the "basePath" value of the web server does not correspond to the
"public" basePath as requested to the reverse proxy, you have to indicate the
"public" basePath and the backend base Path. For example, the proxy redirects
http://example.com/index.php to your web server as
In this case you configure Jelix like this:
[urlengine] basePath= / backendBasePath = /foo/bar
If the reverse proxy redirect HTTPS request to HTTP, you must deactivate the HTTPS check made by Jelix:
[urlengine] checkHttpsOnParsing = off
Since Jelix 1.6.16, you can indicate to force all generated URL with the HTTPS protocol, because it doesn't know what it the protocol used by requests on the reverse proxy:
[urlengine] forceProxyProtocol = https