Tiki saves most (but not all) of the data and the settings in the database. It is possible to configure Tiki to save certain things to the file system instead.
Data: text, files, images, users, etc
Settings: all the TikiAdminSettings (What features are activated)
- When all the data is saved in the database, it makes it a lot easier to make "snapshots" of your data. For example, you can setup a regular dump, compress and ftp to have a daily or weekly snapshot of all your data in one nice file.
- It makes it easier to migrate your tiki site to a new server. From one version to the next your tiki data, a .sql script insures the data is in the correct format.
- Once Tiki, is installed, there is no need to edit text files by FTP. (which is too often the case in similar open source software)
- Presumably, it will make it easier to implement versioning. (I would like an AuditTrail of all TikiAdminSettings like tutos
- Security: You cannot read the content if tiki don't let you read the content. Some data (webmail attachments!) is stored in the filesystem, but probably accessible by apache, and therefore, if someone guesses the filename (or directory listing allowed), everybody can read the content.
However, some data can currenlty (as of 1.7.2) only be stored in the filesystem. We need to make it possible to store this data also in the database.
Admin Setting to store in database or filesystem for the following features:
- Trackers (files attached to trackers)
- Wiki (files attached to wiki pages)
Only stored in filesystem: (you must make sure to migrate these files folders)
Unsure (please confirm)
- webmail file attachments?
- wiki structures (I'm pretty sure)
- /module/cache/ (why are there cache files here?) ex.: mod-application_menu.tpl.cache
- custom themes?
- custom modules
- /lib/Galaxia/processes ?
It must possible to use the database for 100% of the settings and data. Only database backups and Wiki dumps should be in the file system.
We need a clean & robust way to migrate data from database to filesystem and vice-versa.
no one has volunteered to improve this feature
This page was originally prepared by UserPagemarclaporte