Upgrade your WackoWiki from 5.5.x to 6.0.x.
- Check Release Notes for requirements.
- Back up your data:
- your wiki database (e.g. via phpMyAdmin or the backup module in the Admin Panel),
- your wiki folder.
Backup your data! Before doing anything, backup your existing database and files. Also ensure that during migration nobody uses the database, because it may cause loss of data.
- It is imperative that you make a backup of your WackoWiki database before you upgrade.
- The upgrade procedure transfers your installation instance data from the old version to the new version. Migration from the new version back to the old version is not supported.
If you have existing MyISAM tables, you have to convert them to InnoDB with the following routine.
- Admin Panel -> Database -> Convert
You should run the the first part of the routines prior to your upgrade to R6.0.x.
- Download wacko.6.0.x.zip
- Extract the archive
- Delete all wacko folders and files from you current installation, except
- replace old
.htaccessfiles from existing folders with the new ones from the archive
- Copy the new wacko.6.0.x files in your WackoWiki installation folder
- Check file permissions
If in the old version of WackoWiki you've created custom themes, actions, handlers or formatters, then you will have to restore them from the backup created at the beginning. Check their compatibility and fix them if necessary.
Call the URI of your Wiki in your browser. The installer starts and tells you (IMPORTANT) that you are upgrading from 5.5.x to 6.0.x
- go through all steps
- Screenshots from Upgrade procedure
The migration to Unicode is a process. It may require manual adjustments over a longer period of time. Below we will share our experience, findings and possible solutions.
If you've had set custom values in
csp_custom.conf or elsewhere, you must set or merge these values again.
After successful upgrade you can perform a re-rendering for all intrasite links to rebuild the records of the
- Admin Panel -> Synchronizing data -> Wiki-links
You can tune the re-rendering settings to avoid timeouts or reaching the memory limit. This is mostly interesting for shared hosting or servers you do not manage. The server terminates then the script without further notice.
If the re-rendering fails just reduce the number of pages it renders per turn, the redirect LIMIT is set to 10. If you reach the redirect limit the script will provide you with a link Next », which you have to click to render the next batches of pages. Furthermore avoid possible session timeouts while the script is running.
UPDATE prefix_page SET body = REPLACE(body, '/Doc/Русский/Obnovlenie', '/Doc/Русский/Обновление');
((!/el ÅëëçíéêÜ @@el)) -> ((!/el Ελληνικά))
((/Doc/Русский/Obnovlenie ru)) -> ((/Doc/Русский/Обновление ru))
file:/forum/discussion/ifmodifiedsinceheaderdoesnotworks/403_network_analysis.png -> file:/Forum/Discussion/IfModifiedSinceHeaderDoesNotWorks/403_network_analysis.png
NoteFurthermore look out for broken internal or incoming links. The page
tagis now accent and case-sensitive, what worked before with the supertag may now result in 404er.
body_rafterwards, so the parser re-renders the pages with the changed content.
UPDATE prefix_page SET body_r = '';
- Leave a comment here if something is not clear or you have further questions.
- Do not hesitate to improve this instruction and the wording.