Upgrade to 5.5

If you have questions or problems upgrading your previous version to WackoWiki 5.5.x

Release Notes


  1. Not optimal DB request during upgrade from 5.4.3

    I have WackoWiki 5.4.3 under CentOS 7.4 x64, PHP 5.4 and MariaDB 5.5. The database has about 4000 pages and 50000 revisions. During upgrade to WackoWiki 5.5.5 (PHP 7.1, MariaDB 10.2) the script setup/database_mysql_updates.php worked more one hour! This is too slow for such amount of records. Request $update_revision_r5_4_0 must be changed as:

    --- setup/database_mysql_updates.php.orig
    +++ setup/database_mysql_updates.php
    @@ -133 +133 @@
    -$update_revision_r5_4_0 = "UPDATE {$pref}revision AS r, (SELECT page_id, page_lang FROM {$pref}page) AS p SET r.page_lang = p.page_lang WHERE r.page_id = p.page_id";
    +$update_revision_r5_4_0 = "UPDATE {$pref}revision AS r, {$pref}page AS p SET r.page_lang = p.page_lang WHERE r.page_id = p.page_id";
    After that the script worked about 2 minutes.

  2. Impossible to change properties of the user in Admin panel

    One more bug: it is impossible to change properties of the user in Admin panel. It occurs because integer parameter user_id is quoted before transformation to int. It can be fixed as:

    --- user_users.php.orig
    +++ user_users.php
    @@ -218 +218 @@
    -				"AND user_id <> " . (int) $engine->db->q($_POST['user_id']) . " " .
    +				"AND user_id <> " . (int) $_POST['user_id'] . " " .

    • Mangalor
    • 26.04.2018 15:03 edited
  3. Empty body_r and body_toc

    After upgrade body_r and body_toc in 'page' table are empty. When the wiki-page with {{toc}} is being opened first time after upgrade the table of contents on the page is empty too. Only second opening of the page fills the TOC section. Is any way to refill cleared body_r and body_toc automatically? Othewise it is need to fix show method when body_r and body_toc are empty.

    • Mangalor
    • 10.05.2018 15:34 edited
  4. Re: Empty body_r and body_toc

    The installer empties body_r and body_toc because the toc and the headings along with other markup changed. So every page must be recompiled, parsed again.

    1. The show handler recompiles a page if body_r and body_toc is not available.
      • add a page reload condition, object cache issue?
      • need to test some cases to get a bigger picture
      • seems an object cache issue in built_toc function
        • $page = $this->load_page($tag);
    2. The Wiki-links option under Re-Synchronize data in the Admin panel re-parses all pages and updates the emptied body_r and body_toc fields, as mentioned in the upgrade guide. However there are some open issues:
      • the routine fails to continue if it can't parse a particular page or triggers an unwanted redirect
      • the page redirect may exceed the allowed value of your browser
      • the used routine settings may exceed your allowed system resources
      • the Wiki-links re-rendering option needs more testing and tuning, so far you can
        • tune max records per turn
        • add an array to exclude failing pages in foreach using continue
        • turn on debugging, e.g. Diag::dbg('GOLD', $record, $page['tag']); shows the last failing page

    1. I fixed some issues, excluded all system pages, but it should exclude only the pages failing to parse, and disabled the redirect action again.
    2. added option to re-compile all pages

    1. It seems that the changepassword and the registration action causes the routine to fail. WHY?
      • login works. I assume both actions trigger a redirect.

    • WikiAdmin
    • 13.05.2018 19:12 edited
  5. Session duration problem

    There is annoying problem with session duration in WackoWiki 5.5.5 – if duration of page editing is pretty long then results of editing are not saved, the banner "Welcome back, User" appears on the top and content of the page is as before editing. Session duration in the user profile is a month. By default editing duration without results saving (EDWORS) is about a half of hour. I changed $cf_gc_maxlifetime and $cf_max_idle in class/session.php from 1440 to 43200 but it increased EDWORS to about one hour, not 12 hours. How can I make EDWORS and the banner "Welcome back, User" appearing equal to session duration in the user profile?

    • Mangalor
    • 24.07.2018 07:53 edited
  6. So why does the server choose to arbitrarily forget about you in an hour?

    The issue is known and multiple times mentioned in the TODO list. The main issue here is, how we retain the POST data after a forced logout (session timeout) with or without a following auto-login. There are some possible options, but I have to look into the issue more in detail for a workaround.

    I wish more developers would test their web applications for session timeout issues. Despite all rumors to the contrary, your users will not be dedicating their entire lives to using your web application in a punctual and timely manner. They have phone calls to take, meetings to go to, other websites and applications to attend to.

    Is it really fair to kick users all the way out of your web application, or worse, blindly reject data they've submitted — just because they were impudent enough to wait a few hours since their last supplication to the web server gods? In most web apps, the penance is awfully severe for such a common sin.


    • WikiAdmin
    • 28.07.2018 11:26 edited
  7. Changing session duration

    For the meantime you can of course try to raise the session related time values. Guess you should add a factor to the following :

    * FACTOR

    public $cf_nonce_lifetime	= 7200*FACTOR;
    public $cf_gc_maxlifetime	= 1440*FACTOR;
    public $cf_max_idle		= 1440*FACTOR;
    public $cf_max_session		= 7200*FACTOR;		// time to unconditionally destroy active session
    public $cf_regen_time		= 500;		// seconds between forced id regen
    public $cf_cache_expire		= 180*60;	// ttl for cached session pages in seconds

    I did not test if it works, does it?

    • WikiAdmin
    • 26.07.2018 11:00 edited