Hi!
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";
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:
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.
The installer empties body_r and body_toc because the toc and the headings along with other markup has changed. So every page must be recompiled, parsed again.
The show handler recompiles a page if body_r and body_toc is not available (empty).
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);
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
Fixes
I fixed some issues, excluded all system pages, but it should exclude only the pages failing to parse, and disabled the redirect action again.
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:
PATCHED: Not optimal DB request during upgrade from 5.4.3
Thanks.
I know the current moderated Registration process seems confusing.
Impossible to change properties of the user in Admin panel
PATCHED: Impossible to change properties of the user in Admin panel
Thanks again.
The user section is more a Mock-up, it needs a total rewrite. I'm just saying.
Empty body_r and body_toc
Re: Empty body_r and body_toc
body_r
andbody_toc
because the toc and the headings along with other markup has changed. So every page must be recompiled, parsed again.show
handler recompiles a page ifbody_r
andbody_toc
is not available (empty).built_toc
function$page = $this->load_page($tag);
body_r
andbody_toc
fields, as mentioned in the upgrade guide. However there are some open issues:foreach
usingcontinue
Diag::dbg('GOLD', $record, $page['tag']);
shows the last failing pageFixes
Debugging:
changepassword
and theregistration
action causes the routine to fail. WHY?login
works. I assume both actions trigger a redirect.