Quick links: Content - sections - sub sections
EN FR
The page corresponding to the latest stable release can be seen in the Jelix 1.6 Manual

project.xml

The file project.xml contains some informations on the application. Some of these are important because they are used by the installer.

It is an XML file with a <project> as root element, and which contains 4 elements:


<project xmlns="http://jelix.org/ns/project/1.0">
    <info id="testapp@jelix.org" name="testapp" createdate="2017-01-01">
     ...
    </info>
    <dependencies>
     ...
    </dependencies>
    <entrypoints>
     ...
    </entrypoints>
</project>

Note: in Jelix 1.6 and older version, there was a section <directories> which does not exists anymore.

info

In the element info, there are some purely indicative informations about the application, like its name, a description, the copyright, the creator name etc. Note that this element can be used also in module.xml files to identify a module. Here is an example:


<info id="testapp@jelix.org" name="testapp" createdate="2017-01-01">
    <version>1.0</version>
    <label lang="en_US">Testapp</label>
    <description lang="en_US">Application to test Jelix</description>
    <licence URL="http://www.gnu.org/licenses/gpl.html">GPL</licence>
    <copyright>2017 Laurent Jouanneau and other contributors</copyright>
    <creator name="Laurent Jouanneau" email="laurent@jelix.org"/>
    <contributor name="Superman" email="superman@superville.com"/>
    <homepageURL>http://jelix.org</homepageURL>
</info>

Only the <version> element and attributes id and name on <info> are required. Others are optionals.

The id attribute should be a unique identifiant. That's why it is recommended to use an email as an identifiant (or a UUID but it is less readable).

The attribute name should be a "technical" name (the name of the directory of the application or of the module for instance). The label element can contain a displayable name.

dependencies

The element <directories> should contain informations about dependencies of the application. For the moment, only the jelix version is required.


<dependencies>
     <jelix minversion="1.6.0" maxversion="1.6.*" />
</dependencies>

entrypoints

The entrypoints element list all entry points of the application (in www/ or scripts/), with their configuration file and their type.


    <entrypoints>
        <entry file="index.php" config="index/config.ini.php" />
        <entry file="soap.php" config="soap/config.ini.php" type="soap"/>
        <entry file="jsonrpc.php" config="jsonrpc/config.ini.php" type="jsonrpc"/>
        <entry file="cmdline.php" config="cmdline/config.ini.php" type="cmdline"/>
    </entrypoints>

module.xml

A module.xml file must be present in each directory of modules. It contains a root element module which should contain a <info> element and <dependencies> element. See above to know how to write these elements.


<module xmlns="http://jelix.org/ns/module/1.0">
    <info id="jelix_tests@testapp.jelix.org" name="jelix_tests">
        <version>1.0</version>
        <label>Jelix tests</label>
        <description>unit tests for jelix</description>
    </info>
    <dependencies>
        <jelix minversion="1.6.0" maxversion="1.6.*" />
        <module name="testurls" minversion="1.0.2" maxversion="1.1b1" />
        <module name="jauthdb" />
        <module name="jacl2db" />
        <module name="jacldb" />
    </dependencies>
</module>

In a module.xml file, the <dependencies> element can contain additionnaly one or more <module> elements, which indicate modules that the installer should install in order to execute correctly the module.

In the previous example, the installation of the module jelix_tests will trigger the installation of the modules jacl2db, jacldb, jauthdb and testsurls. And only version between 1.0.2 and 1.1b1 of testsurls are allowed.

Sometimes the module can be compatible with some modules that are similar but only one of them is allowed at a time. For example, jauthdb and jcommunity are modules providing same main feature, so your module could propose the choice between them. You use then the <choice> element to list of alternative modules:


  <dependencies>
      <choice>
         <module name="jauthdb" />
         <module name="jcommunity" />
      </choice>
  </dependencies>

It is possible to indicate modules that are in conflicts with the module. You should use the <conflict> element listing modules that cannot be installed with the module.


  <dependencies>
      <conflict>
         <module name="supertest" />
      </conflict>
  </dependencies>

Here, you try to install the module although the supertest is already installed, the installation will fail. Or if your module is already installed and you try to install supertest, the installation will fail too.

configuration ini files

They are files mainconfig.ini.php, <entrypoint>/config.ini.php localconfig.ini.php and liveconfig.ini.php.

You can set in them all parameters you find into the file lib/jelix/core/defaultconfig.ini.php. This file contains all parameters and their default values.

There can be also other parameters dedicated to some modules (see their documentation).

Below is a tour of all configuration sections.

global section

Usually its parameters are at the beginning of file. They define default or global values of the framework.


locale = "en_US"
charset = "UTF-8"
timeZone = "US/Pacific"

theme = default
use_error_handler = on

Parameters in details :

  • locale, charset : default language and encoding of responses
  • timeZone : set the time zone for every date and time functions
  • theme : default selected theme. Read theme system description.
  • use_error_handler : this option shoud stay on for Jelix to return useful and detailed errors or exceptions.

modules section

Contains the list of all enabled modules, parameters for their installers, and other informations when needed.

coordplugins section

List all coordinator plugins Jelix has to activate. They will be loaded from the list of path declared with jApp::declarePluginsDir() in the file application.init.php.

The example below demonstrates the activation of an authentication plugin. Its own set of options are defined in auth.coord.ini.php file. Learn more about authentication.


[coordplugins]
auth = "auth.coord.ini.php"

responses section

this section allows to customize each response type and its alias. each line consists of a couple <response alias>=<response class>.

As for example, it is usual to overload html default response (jResponseHtml) by such a line html=myhtmlresponse. Find more details in customizing common response

Below are the default alias and response types:


[responses]
html = jResponseHtml
redirect = jResponseRedirect
redirectUrl = jResponseRedirectUrl
binary = jResponseBinary
text = jResponseText
jsonrpc = jResponseJsonrpc
json = jResponseJson
xmlrpc = jResponseXmlrpc
xml = jResponseXml
zip = jResponseZip
rss2.0 = jResponseRss20
atom1.0 = jResponseAtom10
css= jResponseCss

compilation section

Defines the behavior of some components which "compile" some files into the temp directory. This is the case of the template engine (Find in-depth details in templates), but also jDao, jForms...


[compilation]
checkCacheFiletime  = on
force  = off
  • checkCacheFiletime : if on the source file will be compiled if its file modification date is more recent than its already PHP compiled file.
  • force : if on, template is systematically compiled

section zone

There is an option to globally disable zone caching. It is useful during development environment but should be set to off in production.

To disable zone caching :


[zones]
disableCache = on  # default to off

urlengine section

Configuration du moteur d'urls


[urlengine]

multiview = off

scriptNameServerVariable =
pathInfoInQueryParameter =

basePath = ""
jelixWWWPath = "jelix/"

Détails des paramètres :

  • multiView: if the parameter multiview or acceptpathinfo is activated into the Apache configuration, est activé dans Apache, vous ne devez pas indiquez le suffix ".php", alors activez ce paramètre
  • scriptNameServerVariable: contain the variable name $_SERVER that contain the script name. Example: if you call http://mysite.com/foo/index.php, this is the variable which contain /foo/index.php. This name could be SCRIPT_NAME, ORIG_SCRIPT_NAME, PHP_SELF or REDIRECT_SCRIPT_URL. Most of time it is automatically detected by Jelix, but sometime it could fail, so you must indicate the name here.
  • pathInQueryParameter: if you are using some rewrite rules that move the pathinfo into a query parameter, like RewriteRule ^(.*)$ index.php/?jpathinfo=$1 [L,QSA] then you should indicate into pathInfoInQueryParameter the name of the parameter, here jpathinfo. Keep empty if you are not using such rewrite rules.
  • basePath: this parameter is the web path to your index.php. Example: if you access to your application by http://foo.com/aaa/bbb/www/index.php then your base path is /aaa/bbb/www/. Or if the url is http://foo.com/index.php, then just indicate /. Keep empty to let Jelix to detect it automatically.
  • jelixWWWPath : contains web path to web ressources of Jelix, those which are stored into lib/jelix-www/.

notfound

You can indicate the action which display a specific page for 404 errors, when Jelix doesn't find the controller corresponding to a given URL. By default it is jelix~error:notfound.

Use the selector syntax, without forgeting to use double quote:


notfoundAct ="mymodule~main:errornotfound"

logfiles section

This section defines how log calls through jLog api will be output.

Log files are created and stored in var/log/ application folder. A per-module log file can be defined by setting a couple <module name>=<log filename> and calling jLog methods with <module name> as last argument.


; default log
  default = messages.log

; log for "news" module
  news = news.log

Another example shows how you can use firebug extension as a log output (useful for quickly debugging). Still you can log to a classic file calling jLog methods with file as last argument (for dumping huge content for example).


[logfiles]
default="!firebug"
file = "messages.log"

Learn more about Jelix debugging through jLog documentation.

mailer section

Contains parameters required to send mails through application scripts.

See the chapter about jMailer.

acl section

Defines options of access control list (ACL) or rights management. See rights management. You can use jAcl ou jAcl2, but not both at the same time. Indicate a driver to enable it.


[acl]
; example of driver : "db"
driver =

[acl2]
; example of driver : "db"
driver =

sessions section

Determines how PHP sessions are stored (file or databse). Find more details in sessions documentation.


[sessions]
shared_session = off
; Use alternative storage engines for sessions
;
; usage :
;
; storage = "files"
; files_path = "app:var/sessions/"
;
; or
;
; storage = "dao"
; dao_selector = "jelix~jsession"
; dao_db_profile = ""