Upgrading Tiki is very similar to its installation. Upgrading is a one-way process. There is no way to downgrade, although you may revert to a previous version by restoring a backup. Before undertaking a major upgrade (e.g. from 21.x to 23.x) perform a test upgrade on a non-production site before proceeding with the real upgrade.

Do I need to upgrade?
It is recommended that you always upgrade to minor versions (e.g. from 22.0 to 22.1) of your current release to remove security vulnerabilities. Some versions of Tiki are listed as Long Term Support which means developers are continuing with security patches and bug fixes on that version for an extended period of time. Minor version upgrades are unlikely to cause problems.

Major upgrades introduce new features, but existing features, themes, plugins and modules may not function as they did before. A test upgrade is strongly recommended.

Do I really need to download and then upload the whole thing using FTP? - For some upgrades a "patch version" is available, if only a few files have been modified. Alternatively, there are some (tw:1-click installers|automated scripts)) which can take care of the upgrade process for you.

Other alternatives to FTP: Rather than downloading and re-uploading the whole package, use commands svn or wget (ask your hosting provider) to move the files directly from SourceForge to your server.

Keep in mind that Tiki21 and Tiki24 are versions kept as Long Term Support (LTS) and that it's always safer to upgrade to the latest release in that branch. And it's always safer to use current stable branch in version x.1 (i.e. 21.1 instead of 21.0) if you are running production sites with extensive usage of many features.

• Download Tiki

You will need to manually move and/or re-integrate any data that is not stored in the MySQL database, for example images and attachments saved as files. This is the recommended process, specially if you have a custom theme style, or one theme style not supported by the new tiki version you are going to use.

This will not delete any Tiki file which was used in previous versions, but are not longer needed. These files shouldn't do anything except waste a bit of disk space, except for the case of template files (.tpl files under ./templates or subfolders). You can use Security Admin to detect leftover PHP files.

This is not recommended because you are keeping all files from previous tiki versions, which may include old-fashioned tpl files, might conflict with the new version specially in theme styles which have changed or which are not supported any more in the new version of Tiki. That's why the best option to avoid any potential conflict is to install a new tiki on a new directory, and replace the old one with the new one, plus re-insert the custom files that you need (img/wiki_up, modified tpl files once you now that they are updated to the new Tiki version, etc). See below at "Fresh Install".

If it's a minor release (21.1 to 21.2), it's unlikely to cause any issues because templates don't change much and there are just bug fixes.

You need to backup

1. Your entire folder where Tiki is installed (and all subfolders)
2. Your MySQL database

See: Backup for details

Tiki files are distributed in a compressed archive (ex.: .zip). You need to unpack (unzip) the files and upload them to your web server.

Instead of copying over your old files, you can make a fresh install.

Things that you may need to copy from your old site to your new site:

• img/wiki_up folder content (uploaded wiki images)
• img/trackers folder content (uploaded images to tracker items)
• any customized *.tpl files
• any customized styles ( *.css )
• any file gallery directories if using the file system to store the files
• any image gallery directory if using the file system to save the images
• Any customized code
  • If you make changes which can be useful to others, please consider joining the Tiki community and sharing your enhancements. Beyond helping others, you no longer will need to re-instate and maintain your enhancements at each upgrade. Please see How to get commit access. 😀

Database Collation

In case you are upgrading but in a new server, and thus, you need to create a new database first, please ensure that you create your new database with utf8mb4 collation.

• Note: By default, Tiki uses UTF-8 (mb4) for your database encoding. We strongly encourage you to select "utf8" in the "collation" drop-down box in phpmyadmin (or similar), in the field shown in the following image:
  

To upgrade, copy or upload all the files of the newer version onto the files of the older version so any older ones are replaced (FTP with "overwrite if source is newer").

Before overwriting the files, remove the non-customized style-specific templates (templates/styles/*, and templates/yoursite/* if any). Previous versions often contained per-style modifications. Those files have since been removed from standard distribution, leaving the old files intact and not taking advantage of enhancements.

If you install using Git or SVN, you can easily update with them. See Get Code

If your server is unhappy with Tiki file and folder permissions (this is dependent on server configuration), you may get an error message or blank pages. These failed attempts are typically in the error log (ask your web host to know where they are as it's different depending of your setup)

Too few permissions
If a message appears indicating that specific directories are not writable, you will need to change the permissions on the indicated directories. Tiki will attempt to verify that it can read (and write) to all necessary directories. This error message will include instructions about how to resolve the issue.

Too many permissions
If you are getting Internal Server Error 500, blank pages or similar, it could be that the permissions on the files are not appropriate for your webhost.

If your permissions are currently at "777", use your FTP client to change the files to "755". If Tiki is installed in a directory, make sure to also change the permission of the folder which contains the tiki files.

If you have shell access, you can run:

sh setup.sh

and answer any questions. If you don't know what to answer, just click "enter" to keep the defaults.

root@yourserver:/var/www/tiki# sh setup.sh

 Tiki setup.sh - your options
 ============================

Composer: If you are installing via a released Tiki package (zip, tar.gz, tar.bz2, 7z), you can and should skip using Composer. If you are installing and upgrading via SVN, you need to run Composer after 'svn checkout' and 'svn upgrade'. More info at https://dev.tiki.org/Composer
  
 c run composer and exit (recommended to be done first)

For all Tiki instances (via SVN or via a released package):

 f fix file & directory permissions (classic default)          o open file and directory permissions (classic option)
 S clear screen

 predefined Tiki Permission Check models:
 ----------------------------------------

 1 paranoia
 2 paranoia-suphp                        w suphp workaround
 3 sbox                                  W sbox workaround
 4 mixed
 5 worry                                 6 moreworry
 7 pain                                  8 morepain
 9 risky                                 a insane

 q quit                                  x exit

There are some other commands recommended for advanced users only.
More documentation about this: https://doc.tiki.org/Permission+Check

Your choice [f]?

The option preselected in "Our choice" will initially be "c", to run "composer" script and get the required php dependencies for you. and in a second step, it will suggest "f", to fix file and directory permissions (classic default option). You can choose at any time the letter that best suits your needs, among the options offered.

If "sh setup.sh" doesn't work for you, you may try, in your ./tiki/ directory

chmod -R 777 ./db ./dump ./img/wiki ./img/wiki_up ./img/trackers ./modules/cache ./temp ./temp/cache ./temp/templates_c ./templates ./styles ./whelp/

Another way is to set permissions for all directories and then set permissions for all files. For example, to set the permissions for all directories to 777 and the permissions for all files to 644, use the following separate commands through shell access:

find [YOURDIR] -type d -exec chmod 777 {} \;

find [YOURDIR] -type f -exec chmod 644 {} \;

After correcting any directory or file permission problems, visit tiki-install.php to continue.

Systems with SuPHP need permissions 755 at maximum. Group must not be allowed to write. This includes the complete path in the filesystem, not only document root of the webserver. Wrong permissions may lead to 500 Internal Server Error here. On the other hand less permissions (namely 750 without x/execute/subdir entry for webserver) may lead to 403 Forbidden Error.

Several usecases and minimum to maximum permissions you may try if something doesn't work properly. Permissions refer to data directly accessed by the webserver (files included by Tiki itself may and should have less permissions):

1.6.3.1. Option

find . -type d -exec chmod 755 {} \; ; chmod 755 . ; find . -type f -exec chmod 755 {} \; ; chmod 751 db/local.php

1.6.3.2. Option

The following commands might be useful. In particular, it might help you use an IDE (PhpStorm), etc:

$ export PathToTiki="/var/www/tiki"
$ export WebServerOwner="www-data"
$ sudo usermod -aG ${WebServerOwner} $(whoami)
$ sudo chown -R ${WebServerOwner}: ${PathToTiki}
$ sudo chmod -R g+rw ${PathToTiki}

In English, the above code adds you to the web-server group; forces the tiki tree to be owned by the web-server user and group; and then makes sure the tiki tree is readable and writable by the web-server group (you). Suggestions welcome!

After correcting any directory or file permission problems, visit tiki-install.php to continue.

On the tiki-install.php page of this new site, connect to the same database as your old site (you can find this info in the file db/local.php of your old site) and follow the instructions to upgrade your site. Make sure to click upgrade and not install, else you wipe out your database.

Then, go to tiki-install.php and click the "upgrade" button, which will update the database. Tiki can read your previous db/local.php file and use this information.

If the installer was previously locked (which it should be), you will need to unlock it by deleting db/lock file.

There are a couple of important security choices during upgrade/installation as follows:

Secure login

When configuring general settings during installation, there is an option to "Require secure (https) login". It is recommended to select this option so that data sent between the browser and the site server is kept private.

In order to implement secure logins, in addition to selecting this option, you will need a security certificate and a dedicated IP address for your domain. These can be obtained or purchased from your web hosting company or, in the case of the security certificate, from third parties.

Locking in the installer

In the last step of the installer, the installer is locked by default once you click the button to enter your Tiki. There is an option to elect to not lock the installer in that last step of the installation. It is highly recommended that you lock the installer for any production site. The option is provided for convenience for development sites only. The installer allows a user to change or destroy the site's database through the browser so it is very important to keep it locked once the installation or up

Hopefully you see the Upgrade Complete message and there may be a list of operations that failed (common for older versions). If these all say something about a column, row or table that doesn't exist, you can try ignoring it. Copy and paste the list of errors for future reference, check the ignore boxes and cross your fingers. When in doubt, refer your questions about upgrade errors to the friendly folk on the tiki-develop list.

At the end, proceed as usual to the Tiki site while disabling the tiki-install.php script.

Tiki ships with a _htaccess file. It needs to be renamed to .htaccess and replace the one from the previous version. If you made any customizations, you should redo them in the new file. See: Apache Clean URLs

Go to the search control panel and rebuild your search index, and it's a good idea usually to clear your Tiki caches. You can find more details here

• Changes in behavior
  • A feature was activated but no longer is (ex. default behavior has changed). You need to go to the admin panel and activate it.
• Bugs
  • Each Tiki version brings loads of new features. However, sometimes, enhancements can bring new bugs as well 😊
• If you customized your themes, they may come out weird
  • You should plan a bit of time to re-integrate your customizations in the new theme.
• If you've upgraded your MySQL server from 4 to 5, when you login for the first time, you may get an "Account disabled" error. To repair this:
  Copy to clipboard

  mysql -u user_dbuser -p user_dbname -B -e "update users_users set waiting=NULL where waiting is not NULL and valid is NULL;"

Look in the release notes of your version for any specific things to look for, and to the documentation pages of each new release (i.e. Tiki24 LTS, Tiki25, Tiki26 LTS, ...)

• If you need help, visit Tiki chat room Chat or forums
• If you found a bug, please report it (and fix if you can!) at https://dev.tiki.org

Check if your new web site contains everything from the old website.

More specifically, structures, search, individual plugins, and some other features may have to be activated in the admin panel.

As of tiki 4, a new system of managing tiki plugins was added to require the authorization of some plugins. Potentially unsafe wiki plugins then had to be validated by users with the new permissions related to approving plugins. If you were using such plugins they will now not function until someone with sufficient permissions approves them.

Now, any user that attempts to use a plugin, including iframe, dbreport, tag, sql, snarf, regex... which would need to be validated by some trusted users/editors/admins later on in order to approve or reject them.

A list of plugin calls pending revision can be found at any time here: tiki-plugins.php

Revise the notes at
https://themes.tiki.org/Upgrading

For a more detailed description, read Styles and Themes

If you need further instructions, ask in the Chat or in the forums, and please, come back here and upgrade the documentation with what you learned. This is a way for you to help and make it easier for new users .

• Upgrade trunk
• Upgrade from unmaintained versions
• Upgrade 3.x to 3.latest
• Upgrade 2.x to 3.x
• Upgrade 1.9.x to 2.x
• Upgrade 1.9.x to 1.9.y
• Upgrade 1.8.x to 1.9.y
• Upgrade 1.7 to 1.8
• Upgrade
• Manual upgrade
• Archives Upgrade

When you are happy with the result delete the directory structure of the old site and move the directory of the new site in place. In fact on GNU/Linux or other Unix based servers you can usually use a symlink instead, making the upgrade easy.

ln -s tikiwiki-3.0 tiki

If you manage many tiki sites in the same tiki instance ( MultiTiki ) but having them in subdirectories, you can follow also the instructions at the Manual Installation page.

If you have shell access and Git or SVN: dev:Get Code

If you manage many instances, you should consider the Tiki Manager.

Please see: Manual Upgrade

Please see: Upgrade from unmaintained versions

Update 2016 - Got it working this time using the dotglob option
If you have your new tiki all set up and ready to go in path_to_your_site/tiki15, and a new directory ready to put the old one in called tiki12 for example, here is the command to move everything except them into the tiki12 dir, and then move everything out of tiki15 into your site root:

# go to your tiki root
cd path/to/your/tiki/install
#first back everything up off you have room
tar -cvzf ~/backups/htdocs-pre-update-to-15.tar.gz ./
#make a dir to put the old version in while testing
mkdir tiki12
shopt -s dotglob  # sets * to include hidden files
# move all the old files into tiki12
find . -maxdepth 1 -not -name 'tiki12' -not -name 'tiki15' -not -name '.'  -not -name '..' -exec mv {} ./tiki12 \;
# move the new tiki15 site out into the doc root
mv tiki15/* ./