From Limbas Wiki
<-- backt to Main Page
- limbas_src: Here are the LIMBAS source files, which can be overwritten in the event of an update, without any individual settings being lost.
- Independent: This is where stand-alone external applications are used by LIMBAS. An update of these applications, which is separated from LIMBAS, is possible, but not recommended, since the interaction is only tested with the versions included in the LIMBAS installation.
- Public: Here is an example of a SOAP application. The files from this directory are not required for the functionality of LIMBAS.
- Dependent: This is the actual working directory, in which individual settings are stored. The directories and files of the limbas_src directory must be represented here as symbolic links.
- If the files and directories from "<DocumentRoot>/openlimbas/limbas_src" are copied into "<DocumentRoot>/openlimbas/dependent" instead of being symbolic links (on some systems there might be problems with extracting symbolic links), then proceed as shown in Known Solutions:
- To allow individual settings to be saved in LIMBAS, LIMBAS must be able to write to "./openlimbas/dependent" and all subdirectories.
The update from an older Version 2.x to a new Version 2.x is quite easy. The following steps are necessary for the update:
- download the new Limbas Source
- overwrite the old source (only the "limbas_src" not the "dependent" directory)
- in case there is no “between” release (2.1.17 to 2.1.25) also overwrite the “independent” directory (does no harm)
- register as “admin” (one is automatically taken to the update-script)
- in the update-script (Tools->System) select and execute the current update under “Systemupdate”.
- return to Limbas main page.
- make sure that the new system tables in “admin/UPDATE/tables” have been imported. This can be carried out by hand as Administrator with the Limbas-Import function, or automatically carried out before the update through commenting out the line with the variable "$impsystables" at the end of the respective Update-scripts (e.g.: up_2_3.php).
Because ones own changes to these System Files can be overwritten one should decide for oneself which tables should be imported. New functions possibly cannot be introduced without updating. “lmb_field_types”, “lmb_umgvar” and “lmb_action” are system critical tables. With 'No import' the content of these tables should in any case be equalized. The Table “lmb_lang” contains the up to date language data records.
- reset der session and reload. Sometimes it is helpful to delete the browser cache in order to update .js or .css files.
The file lib/version.inf must be writable for the Apache-User otherwise the Version number must be correctly entered by hand. If the file lib/version.inf from the update-script is not edited, then the Update-script adjustment will continue until the version number agrees with that of the Tables Version.
Update over Multiple Versions
The procedure is basically the same as described above. Please note the following:
- Read the top guide!
- Into the old system as admin login
- Overwrite the source
- Edit the last update script (only the one with the highest version number) in admin / UPDATE / up_2_X and at the end the commented line "$impsystables = ..."
- In the point (and nothing else!) Admin-> tools-update. (Possible ODBC errors about missing fields can be ignored, they are created automatically)
- Now each update script in succession (necessarily starting from the own version!). While the individual updates do not leave the page and do not click "back to mainpage .."!
- After the last update script (this should now also have imported some tables) press "reset" to clear the browser cache and reload the page