Open bugs

Could someone please give some more details to this bug. I've not experienced it, and thusly can't fix it. --EvenHolen
Probably just a problem with his indexes.. Try a REPAIR TABLE efi_rate QUICK and it should be okay. --RandomAnonymousDude?
In my 4.0.0-version, (yes, I should upgrade), it works (and also on this site). In fact, this bug is dependent on the setting of a sql-mode variable, MAXDB. Will look into this, but the quick solution is not applicable to everyone, and it will also, most likely, break time zone issues. --EvenHolen
Which bad consequenses are you talking about? File redirection through an exceptionally bad setup web server? Or something else? Please ellaborate! --EvenHolen
Will look into this. I'm contemplating on a rebuild of all the code producing listings, but a main goal of Tavi has always been to be validating cleanly, so it will be fixed. --EvenHolen

Bugs on debate

Are these bugs, or merely features of Tavi? That's open for discussion. Either here on this page, or if lengthy discussions on a sub page. Please feel free to contribute with your opinion.

An experiment I'll try will be to store the links only in lower case and see if that helps. -JoelRicker
This is actually not in the given set of WikiNames. In 'Tavi we accept several uppercase characters later on, but not at the start. This is to not falsely identify company names (and similar) as WikiNames. But I'll look into this and see if we could get a better handling. Any suggestions on how? --EvenHolen
Anyway, that fixed my problem. Thought I should share in case the development team wanted to put in their own solution.
We thank you, and all other contributors, describing bugs (and providing solutions) so we are able to make 'Tavi better. --EvenHolen
The correct fix, as mentioned on TaviTranslation, is to change the line to if(defined('LANGUAGE_CODE')), and also to use define('LANGUAGE_CODE', 'de') in config.php. Issue will be adressed in version 0.26, when I get around to it... --EvenHolen 
Section Heading \\
*Topic 1
*Topic 2
"Topic 1" doesn't adopt the the indent and bullet I expect. Maybe there is an easy way around this I haven't yet discovered. - MikeWagner
Nope, it doesn't, and that's the correct behavious as of version 0.25. If you want to remove spaces between elements, then the correct approach is to change the css-stylesheets. Introducing the \\-operator at the end of a sectional heading, introduces strange coding. Remember that in a way using the \\-operator joins the two lines into a single paragraph, whilst inserting a symbol, <br />, to make a manual linebreak within this paragraph. This means that doing so on a heading, followed by a list item, is bound to have a strange behaviour. --EvenHolen
Ugh, this is infuriating. I really don't understand why this <p> tag thing had to be implemented. It worked wonderfully before, and now it's just plain difficult.

Editing some pages in our Tavi causes the wiki to lock up completely when saving your changes. The browser just waits and waits and waits for the page to be saved. This occurs everytime specific pages are edited. Restarting mysqld seems to be the only way to reboot the wiki and bring it back up. Upon restarting it the changes which were made are found to have been saved. This happens on a few pages in our wiki but never in others. Does anybody know why or how we can solve this problem??? We have a large investment in our 'Tavi with nearly a thousand relatively comprehensive pages. This is the only problem we've noticed with 'Tavi in over 2 years of solid use, any clues anyone????

MarkConstable: I just bumped into this at http://alsa.opensrc.org and I found that removing the nice rewrite rule in a .htaccess fixed it for me. Yes, the edit gets saved and it's just the returning altered page that gets hung for some as yet unknown reason.

MarkConstable: has anyone attempt to run Tavi under PHP5 yet ? :-)

While I'm here... this is broken in safe_mode. The default config setting of /usr/bin/diff will not work when safe_mode_exec_dir is set to some path (even /usr/bin) as the path that is actually looked up is then /usr/bin/usr/bin/diff. If $DiffCmd is set to just diff the first test will not work and I think the 2nd test will always fail because is_readable() doesn't seem to to be reliable under safe_mode.

#  if (ini_get('safe_mode') and
#     (ini_get('safe_mode_exec_dir') != dirname($DiffCmd)))
#    { $diff = LIB_NoDiffAvailableSafeMode; }
#  else if (!file_exists($DiffCmd) or !is_readable($DiffCmd))
#    { $diff = LIB_NoDiffAvailable; }
#  else {
    $output = array();
    exec("$DiffCmd $temp1 $temp2", $output);
    $diff = join("\n", $output);
#  }
I run it successfully on PHP6-dev. It works like a charm after fixing tavi/parse/macros.php because of a argument type complaint -AlanConnor?
However this cannot be the best solution as we just suppose the server is running PHP 5.0.
  • I'd suggest to add to instead of replace the PHP4 case: 
    function html_phpcode($text) 
{
//... 
// PHP 4.0:
  $search[0]  = '<font color="'.ini_get('highlight.html').'">';
  $search[1]  = '<font color="'.ini_get('highlight.default').'">';
  $search[2]  = '<font color="'.ini_get('highlight.keyword').'">';
  $search[3]  = '<font color="'.ini_get('highlight.string').'">';
  $search[4]  = '<font color="'.ini_get('highlight.comment').'">';
  $search[5]  = '</font>';*/
// PHP 5.0:
  $search[6]  = '<span style="color: '.ini_get('highlight.html').'">';
  $search[7]  = '<span style="color: '.ini_get('highlight.default').'">';
  $search[8]  = '<span style="color: '.ini_get('highlight.keyword').'">';
  $search[9]  = '<span style="color: '.ini_get('highlight.string').'">';
  $search[10] = '<span style="color: '.ini_get('highlight.comment').'">';
  $search[11] = '</span>';
// common
  $search[12] = '\r';
  $search[13] = '<br />';
  $search[14] = '&nbsp;';
  $replace[0]  = '<span class="html">';
  $replace[1]  = '<span class="default">';
  $replace[2]  = '<span class="keyword">';
  $replace[3]  = '<span class="string">';
  $replace[4]  = '<span class="comment">';
  $replace[5]  = '</span>';
  $replace[6]  = '<span class="html">';
  $replace[7]  = '<span class="default">';
  $replace[8]  = '<span class="keyword">';
  $replace[9]  = '<span class="string">';
  $replace[10] = '<span class="comment">';
  $replace[11] = '</span>';
  $replace[12] = '';
  $replace[13] = "\n";
  $replace[14] = ' ';

  return str_replace($search,$replace,$text);

}
I haven't tested it. Does it work for you? --hs
It's safer to add the following lines to check the server version: -- MiGi 
if (PHP_VERSION >= "5.0.0") {
...(codes for PHP 5.0 or up)
} else {
...(otherwise)
}
My final code: TaviBugs/PhpCode