Architecture / Installation

Architecture / Installation

Re-install all php on old database ?

posts: 36

Hello world and Happy Xmas to all!

Bad end of years for me, my site had been hacked and a lot of php file modified. But the database is safe.

May I repair only by deleting all files, unpacking the tikiwiki archive and copy all at the original place ? Is it possible ? Is there other way to recover my site ?

Thanx a lot!


posts: 36

Well, I test it and survive! :-)

In fact it was just as a update except it's to the same version.
- delete all old files
- copy the unziped files
- launch the install script and choose update an not install from the scratch.

Subject closed and solved.

posts: 1560

Hi Luc,

I just wanted to answer the same to you, but you already solved yourself - congrats!

Please mind, that it is strongly recommended to store your file-gallery files (for example everything you upload to provide for download) not in the database and not in the tiki root.

Instead you should create a directory at a higher level outside the tikiroot, where no domain points to ... example: ../files/gallery instead of /files gallery


posts: 36

Hi Torsten!

Thank you for the congrats! :-)
And for the pictures are not in the database but in the directory under the tikiroot level. Like: tiki-php-root-level/images/*

Is this a problem ? Why ?

posts: 1560

Hi Luc,

it is a matter of security and a matter of transparent structure (ex. for major upgrades, even if the Tiki runs from the repository, when several projects or various software runs in the same account of a server).

Everything where you point a domain to or where you point the domain to a higher level in the directory, files are generally accessible via the domain and have to be secured ... for example by a specific index file.

Better is to save the files outside the Tikiroot at a higher level and to not point domains above this level.

I do it this way:

account on shared hosting - customer-accessible standart document root:

Please mind, that I only point domains to the initial installation and never point any domain to the default document root (highest level where a providers customer can point a domain towards in a shared hosting or managed server).

static html/php:

/html/projectname/files <- files like what is needed for css or libraries
/html/projectname/web <- static website (html or php) <- point domain here
/html/projectname/download <- files provided for download

content management systems:

/allcms/readme-scripts-and-templates <- optional

containers for projects:


structure the containers:

/cms/projectname1/files <- might be different in detail, depending on the given software (drupal, typo3, tiki etc., in this text I refer to how I do it with Tiki )
/cms/projectname1/cms-version <- one folder per major upgrade - kept after upgrade as "running backup" <- point domain here
/cms/projectname1/backups <- optional, might be organised at a higher level
/cms/projectname1/readme-scripts-and-templates <- optional, might be organised at a higher level



* NO domain pointing here!

* NO domain poining here!
* used with the "upload from directory" option of file galleries
* subfolders optional, ftp access for workgroups to ./batch or to ./batch/subfolders optional

* point domain here
* one folder per major upgrade - kept after upgrade as "running backup" and archived or deleted lateron
* with svn repository each major upgrade get's an own database
* if downloaded releases are used (if no shell/svn on shared hosting or only limited amount of database), this rule must be adjusted.

* point a subdomain here (to temporarily access old installation)
* in this example this was a downloaded branch 12.1 and was kept as "running backup" for a while with the old database
* if used for longer time, the folder /tiki/myintranet/files should be backed up to for example to /cms/projectname1/backups/filesftp12/... and this particular change (only) updated in the old website. Otherwise there could be inconsistencies caused with the live files folder.
* if used only short term and then deleted (or archived), no change of the files allocation necessary

* point a subdomain here (to temporarily access old installation)
* in this example this was a version of the website, where a new boostrapped theme was developped and all issues regarding files have been resolved when upgrading from classic Tiki12 to bootstrapped Tiki14, examples are JavaScripts and themes, especially custom themes, including templates and css plus further adjustments, or grafics
* here it is aswell kept as "running backup" for a while with the upgraded version of the old database

/tiki/myintranet/svn14x <- point domain here
* in this example this the live website, which was finally upgraded smoothly from Tiki12.1 (downloaded branch) to Tiki14.x (kept up to date from the svn repository)

* point a temporary subdomain here, for example dev.example.com
* in this example, this is a new version of the website based on the next upcoming Tiki (trunk now is pre-15, runnng from the svnrepository, so I name it svntrunk15), for example to test before upgrade or to test new features etc.

* NO domain pointing here!
* this folder might contain the files of old versions, IF NEEDED as archive <-> likely not necessary /tiki/myintranet/backups/tikiversion
* this folder might contain database dumps, if not organised on a higher level of the server
* optionally dumps are automatically saved here with a script and a cronjob

/tiki/myintranet/readme-scripts-and-templates <- optional, might be organised at a higher level
* this could be an appropriate place to save shellscripts, templates or README files, which are used by a team of administratrs and used specifically used for this project. 
* before saving here, consider if the given information would be 
** necessary as a file, or better published to the team on a wiki page
** limited to the specific project or better allocated at a higher level, for example when relevant to several projects of the same software or even higher for cms projects in general.


/README <- general information for (new) admins

/_static/README <- general information on static coded project for (new) admins
/_static/html <- the static html/php projects
/_static/javascript <- if another language is used
/_static/python <- if another language is used

/_cms/README  <- general cms-specific information for (new) admins

or customer based, if customers would not have individual server-accounts or servers, maybe when developments made for various customers on a single own shared hosting, ...:

/README <- general information for (new) admins

/customerA/README <- customer specific information for (new) admins

/customerB/README <- customer specific information for (new) admins

/customerC/README <- customer specific information for (new) admins

posts: 36

Thank you very much and Xavier de Pedro too. I'll take time to understand and correct my site.

BTW: Happy new year tou you and everybody else too!

posts: 1811 Catalan Countries

Hi Luc:

An addition to Torsten's comments:

Upgrade to the latest stable version possible, and in case of doubt, stay within an LTS.

I.e.: You didnt' say which version you were using, but please, upgrade to latest Tiki 12.X LTS if possible.

And you might want to rescue any files you had customized on disk, before deleting everything.
There is a nice utility to help you doing that, not very much known, but you can reach it at:
Admin home > Tiki Cache/Sys admin > Save Directories


Additionally, if you customized any css or tpl files, you'd better copy them first to a safe place before deleting the tiki file tree. See also: