History: Installation,fr

            ^La traduction n'est pas terminée^

!!# Install Tiki directly from the SVN repository

This method requires __a__. a server with shell (command line) access and __b.__ a running SVN instance on this server.

For the SVN part please review the page ((dev:Get+Code| Get Code on dev.tiki.org)). There and if necessary on the related pages you find notes about the SVN commands and the particular paths you need to use in the command line to automatically checkout or upgrade the Tiki into the intended installation directory (= tikiroot folder).

__Example for a fresh checkout (recommended also for major upgrades)__

__Method 1__
Checking out to a new folder (that you will specify)

{CODE()}
$: svn checkout https://svn.code.sf.net/p/tikiwiki/code/trunk mynewfolder
{CODE}

__Method 2__
Checking out to the current folder (when you created the intended tikiroot already and changed into this directory prior to the checkout):

{CODE()}
$: svn checkout https://svn.code.sf.net/p/tikiwiki/code/trunk .
{CODE}

__Example for a minor upgdate:__

Do not forget to switch into the tikiroot of the Tiki you want to update

{CODE()}
$: svn up
{CODE}

After SVN has downloaded the Tiki files, the Tiki is not yet complete. You have to run the composer
The composer automatically downloads and installs the so called 'vendor files' from ecternal sources.
Vendor files are external scripts and libraries, which we pack to the Tiki code on release time but we do not manage in our own repository.
Examples of those vendor files are the Bootstrap code, the jQuery library, Tablesorter, Elfinder etc..
Usually (= on most servers) you additionally have to fix certain file permissions.
Both can be accomplished by simply answering a number of questions after starting the setup.sh script in the shell (= command line).
This procedure is quite self-explaining. Just follow the instructions of the script.

Start setup.sh, after having switched into the tikiroot (in case you are not there anyway):

{CODE()}
$: sh setup.sh
{CODE}

For more information on using setup.sh see also the section 4.1 Troubleshooting below. In this section we treat only the composer part, which is only applicable when you use an installation from the repository.

To start the composer you have to confirm the option "c" after starting the setup.sh script:

{CODE()}
$: sh setup.sh
Your choice [c]? c
{CODE}

or

{CODE()}
$: sh setup.sh
Your choice [f]? c
{CODE}

__FAQ:__ On my server the composer script is not starting. What can I do, when I get the following error message?

{CODE()}
Wrong PHP version: phpABC < required PHP version.  A version >= phpXYZ is necessary.
{CODE}

The problem is, that many shared hosting providers keep the setting of the default local PHP version of the shell (command-line) to an outdated PHP version which does not match the PHP requirements of Tiki or of the composer. Alternativ PHP settings in the .htaccess or in the php.ini file or in the user.ini file have no effect to the PHP version in the shell (command line).

However most of these servers have newer PHP versions available in the shell (command line), which can be used alternatively.
For Tiki 16, likely soon backported to Tiki 15, we provide an option, which allows to run the composer with an alternative up-to-date PHP version, given any one is available on the particular server.

Another issue to be addressed is, that the providers have different naming conventions how to distinguish their available PHP versions. To address this issue we implemented the option "-p" for our setup.sh script to provide the option to manually change the PHP version used by the script:

{CODE()}
$: sh setup.sh -p PHPVERSION
{CODE}

In a first step, the setup.sh script automatically guesses three typically used namings of up-to-date versions, commonly used on many servers and uses the first one that matches:

{CODE()}
php55 php5.5 php5.5-cli
{CODE}

If the script finds one of these, you should get the following message prior to an autostarting composer:

{CODE()}
Wrong PHP version: phpABC < required PHP version.  A version >= phpXYZ is necessary.
Searching for typically named alternative PHP version ...
... correct PHP version phpDEF detected and used
Local PHP version >= required PHP version XYZ - good

Loading composer repositories with package information
Installing dependencies from lock file
(...)
{CODE}

Now you are done. Problem solved.

__But__ if none of these options work out, you will get the following error message:

{CODE()}
Wrong PHP version: phpABC < required PHP version.  A version >= phpXYZ is necessary.
Searching for typically named alternative PHP version ...
... no alternative php version found.
Please provide an alternative PHP version with the -p option.
Example: sh setup.sh -p phpXYZ.
You can use the command-line command 'php[TAB][TAB]' to find out available versions.
{CODE}

This should be quite self explaining. 
You simply have to use the php command in the shell, followed by twice typing the TAB key without any space or other key and enter. then the shell (command line) will provide you a list of the available PHP versions which you can use (obviously using the naming convention used on this particular server):

Example:
{CODE()}
$: php[TAB][TAB]
php    php-53  php-54  php-55  php-56  php-70
{CODE}

How to use this information:
Given the required PHP version would be php 5.5, but your provider uses php 5.3 by default, you simply need to type the following command to start setup.sh with the right PHP version for the composer (in this particular case php-55) ...

{CODE()}
$: sh setup.sh -p php-55
Your choice [c]? c
{CODE}

And swoooosh the setup.sh will start the composer with php 5.5 after the following message:

{CODE()}
Wrong PHP version: phpABC < required PHP version.  A version >= php55 is necessary.
Searching for typically named alternative PHP version ...
... correct PHP version php55 detected and used
Local PHP version >= required PHP version 55 - good
{CODE}

Now you need only to follow the setup.sh dialog to fix directory permissions (option [f] is reasonably secure works on most average servers. If you need a more secure setting or if your server needed a less restrictive setting (better change the server then), you can use another option. To find out which permission option is best n your server, you can use ((Permission Check)).

You are done now and can go to your website to run the installer.