WikiDB/Bugs

From TestWiki
< WikiDB
Revision as of 00:34, 16 January 2008 by HappyDog (Talk | contribs) (Internal error deleting a page - Fixed)

Jump to: navigation, search

Open Bugs

Error in Normalise

I noticed a bug:
If the criteria attribute results in zero rows being returned from PerformQuery, the call to NormaliseData is resulting in 1 row for each column in the table. After a bit of investigation, it turns out that Normalise is creating an empty array, but with the column names as tags inside the array, causing the loop to loop through the tags, rather than the rows (as would be expected). This is pretty easily fixed. I placed the following at the beginning of NormaliseData, and it fixed the issue for me: 

if(!is_array($Data) || count($Data) == 0)
{
    return $FormattedData;
}

-Jacob 23:22, 8 April 2007 (BST)

I have been unable to replicate this. The most I have managed to get is that there is a header row (with the correct column headings) and then a single blank row. I get the same results regardless of whether the table is defined (although if it is undefined the header row is also empty, resulting in a table with two rows, but no cells in either row). Can you (or anyone else?) provide a more detailed example of how to replicate the problem as described? --HappyDog 01:05, 13 July 2007 (BST)

Error when using repeat in a template

  • If I use a <repeat>-tag in a template and then use a template-parameter in the criteria-clause, then the parameter-value in the criteria-clause is not replaced by its value first. (Stephanvaningen, 23 May 2007)
  • Like this: <repeat table="handelaars" criteria="id={{{templateparametername}}}">{{{tablefield}}}</repeat>
  • After that, I tried this:
    • <repeat table="handelaars" criteria="id=50">{{template}}</repeat>, with in the template then direct use of the field names from the table. This seems not to work
    • This I tried because I wanted to prevent writing *all* the table fields each time when calling the template: are there any possibilities there?
      • Hey, I actually got this to work. I was able to use the <repeat> tag inside a Template using template parameters to feed the fields of the <repeat> tag using a MediaWiki Extension called ExpandAfter. Follow the link to learn how to install it. Once installed, use it like this in your template: {{#expandafter|repeat|table="handelaars" criteria="id={{{templateparametername}}}">{{{tablefield}}} }} What this extension does is parse out the template parameters BEFORE calling the WikiDB code for the <repeat> tag. What's really cool about this ExpandAfter extension is that it works for ANY <xxx> tag in MediaWiki, not just the <repeat> or <data> tags for WikiDB, but for others too, such as any tags introduced by other extensions. -- Mdrayman 04:35, 3 July 2007 (BST)

BUG: data tag still creates records inside of nowiki tags

If I put the following code in a wiki page, the table referenced in the <data> tag still makes a record show up in that table. Is there any way to illustrate to a user in a wiki page how to use the <data> tag without it adding records to the real table? 

<data table="ServiceCustomerJobs">
job_num=
account_num=
description=
date_called=
date_serviced=
completion_time=
job_page=
satisfaction=
complaint_page=
</data>

I bet that if you go look at the Special:UndefinedTables special page, there will be a new table called "ServiceCustomerJobs" because the <nowiki> tags didn't prevent WikiDB from using the <data> tag as a new record declaration.

-- Mdrayman 04:35, 3 July 2007 (BST)

I just checked the Special:UndefinedTables on this wiki and sure enough, even though I used the <nowiki> tags, the table still showed up with the record defined above.

Any clues as to what's going on here?

-- Mdrayman 04:37, 3 July 2007 (BST)

Hmmm... well I'm not sure if there's anything I can do about that, but I will check. I may be doing something funky like manually parsing the page - in which case this is definitely something that needs fixing. If not, then it is a problem in MediaWiki itself. I suspect the former, however, and will look into it. In the meantime, an easy workaround is to use &gt; instead of > and &lt; instead of < when creating your example data tags. --HappyDog 13:28, 4 July 2007 (BST)
Thanks. I'll use those special codes in the meantime. Good luck figuring out what's really going on. -- Mdrayman 20:02, 5 July 2007 (BST)

Is your $pRegexDataTag ignoring the <nowiki> tags? The reason I ask is because I noticed that the table data entered into a page is saved ONLY when the article is saved, using the ArticleSave hook in MW that calls your wfWikiDB_ArticleSave() function. The <nowiki> tags do prevent MediaWiki from using any of the WikiDB functions to render a table entry or <repeat> tag filter result, so at least they are somewhat functional. So this seems to indicate that something in WikiDB is saving the table entry specified inside of the <data> tags regardless of the presence of the <nowiki> tags. -- Mdrayman 08:12, 6 July 2007 (BST)

BUG: data tag does not create new table entry when using ExpandAfter MW extension

I mentioned above about using the ExpandAfter MediaWiki extension to populate fields of the <repeat> tag inside of a template. Now, this extension works with the <repeat> tag, however, it does not work quite right with the <data> tag. Below are two attempts to add a table entry to a new table called ExpandAfterTable.

Not using ExpandAfter: 


<data table="ExpandAfterTable" template="default">
value1=nothing
value2=something
value3=everything
</data>

Using ExpandAfter: 


{{#expandafter:data|table="ExpandAfterTable" template="default"|
value1=nothing
value2=something
value3=everything
}}

Now, what happens when I use the <data> tag by itself in the above manner, the new table entry shows up in the Table:ExpandAfterTable page and in the page it was added shows the normal table printout of the single entry.

When I use the ExpandAfter extension to do the same thing, which, by the way, does work for the <repeat> tag, the table printout appears on the page containing the <data> tag instance, however, the Table:ExpandAfterTable page does not show a record for this entry.

My question is, given that the ExpandAfter extension works correctly to recreate the wiki text shown in the first example above AND WikiDB does print out the table entry in the page it was entered, why then does WikiDB not add this table entry to the table itself?

You may need to install the ExpandAfter extension to test this out. When you do, you'll see what I mean, and, I think you'll like using this extension since it will allow you to use the WikiDB tags inside of templates and pass template parameters to the WikiDB tags inside of those templates.

Thanks! -- Mdrayman 20:02, 5 July 2007 (BST)

During my investigation of the <repeat> tag bug below, I think I might know why the <data> tag successfully displays the table entry in a page, however, does not save that data into the real MySQL tables. I noticed that the action of saving data into the MySQL tables takes place in the wfWikiDB_ArticleSave() function as a result of the ArticleSave MW hook. Now, what I think is happening is that when the article is saved, there is no <data ...> ... </data> text in the page because it is hidden inside either the ExpandAfter extension's markup or a template. Since WikiDB looks for the <data ...> ... </data> only when the ArticleSave hook is used, these tags are not recognized by WikiDB anywhere in the article at the time of saving the page text and therefore no data is saved in the MySQL tables. In order to enable <data> tags to be used inside of templates and other extensions' markups like ExpandAfter, I think the wfWikiDB_ArticleSave() function should probably be called sometime during the page rendering process AFTER templates and other extensions are processed through MediaWiki's parser. Perhaps the wfWikiDB_ArticleSave() function could be called at the time the <data> tag is rendered with the wfWikiDB_DataTag() function; either before or after should do the trick. The only downside to this is that this will cause saves to the WikiDB MySQL tables everytime a page is rendered. Would there be some way to detect if data changed and save it during a render only if data changed? -- Mdrayman 08:40, 6 July 2007 (BST)

BUG: Using Repeat tag on a Table where the filter results in Zero results yields ERROR

I have been making heavy use of WikiDB in the past couple of weeks and I found that with any WikiDB table that not even need be empty, when using the <repeat> tag to filter the table's contents for a particular value of one of the fields, WikiDB reports some bad errors when there are ZERO results returned from the use of the filtering via the <repeat> tag.

300px

At the right is a screenshot of my Firefox browser window in the wiki page using the <repeat> tag to filter contents of the table when the filter returns zero results. If I then change a single table entry on another wiki page where it is defined to then make the filter results non-zero, these errors go away completely.

Any idea what's going on here? Let me know if you have any questions about what I'm trying to do.

-- Mdrayman 21:27, 5 July 2007 (BST)

Ooops, I guess I didn't know I couldn't upload images. Well, if you could enable me to upload images, that would be great, but in the meantime, I'll just describe what the error says in the wiki page. As soon as I refresh the wiki page in the browser, I see nine (9) of these error messages repeated down from the top of the page (I stripped out my wiki path from between the two slashes "/"): 

Warning: Invalid argument supplied for foreach() in /.../WikiDB.php on line 587

Also, an OK box pops up and says "Error: Failed to derive URL prefix for Timeline API code files", I click OK and the rest of the page renders in the browser window. Further down the page where I actually use the <repeat> tag to generate filtered table results, nine (9) bogus lines are printed out instead of what I'd expect a zero results filter response would be: no lines printed, or a message that says "No results". These bogus lines look like this:

  1. {{{job_page}}} : {{{description}}}
  2. {{{job_page}}} : {{{description}}}
  3. {{{job_page}}} : {{{description}}}
  4. {{{job_page}}} : {{{description}}}
  5. {{{job_page}}} : {{{description}}}
  6. {{{job_page}}} : {{{description}}}
  7. {{{job_page}}} : {{{description}}}
  8. {{{job_page}}} : {{{description}}}
  9. {{{job_page}}} : {{{description}}}

Here, the job_page and description identifiers are fields in the table I defined using the WikiDB interface.

I'll take a look at the WikiDB.php file on line 587 to see if I can figure out what's happening. I'll post what I find, if anything.

-- Mdrayman 21:40, 5 July 2007 (BST)

After experimenting a bit with different tables trying to figure out this bug, I did notice that the number of bogus lines printed out from a <repeat> tag is exactly equal to the number of fields in the table specified in the <repeat> tag.

In the WikiDB.php file centered around line 587 was this php function: 

581 // TODO - this is VERY crude at the moment, and may well fail in certain edge cases 
582 // (or even, certain 'non-edge' cases!)
583     function pWikiDB_ExpandVariables($Input, $Data) {
584         if (count($Data) > 0) {
585         // Substitute variables.  Note that we need to replace $ with \$ within $Value, to stop it being
586         // interpreted as a PHP variable reference.
587             foreach ($Data as $Key => $Value)
588                 $Input = preg_replace("/{{{" . $Key . "}}}/", str_replace('$', '\$', $Value), $Input);
589         }
590         return $Input;
591     }

I see this is commented as crude, but I'm wondering since the error above mentioned an invalid argument for the foreach() construct, why would the $Data variable contain ANYTHING if the table is completely EMPTY? Apparently, an EMPTY table is somehow passing the if (count($Data) > 0) test. Any ideas as to what's going on? -- Mdrayman 06:47, 6 July 2007 (BST)

After digging into the WikiDB.php PHP code and playing around with some print() statements inside of the pWikiDB_ExpandVariables() function as well as its calling function, wfWikiDB_RepeatTag(), I decided to take a chance and make one small change. I changed line 587 above to if (count($Data) > 1) because I noticed that the actual result of count($Data) was 1 when $Data was an empty row from an empty table. This change made ALL of the Warnings about the foreach() invalid argument go away.

I still saw the bogus lines printed from using the <repeat> tag, so I moved the if (count(... check out of the pWikiDB_ExpandVariables() function and into the wfWikiDB_RepeatTag() function right where it would be about to call the pWikiDB_ExpandVariables() function so that it is not even called if the $Row variable is found to have a count($Row) equal to 1. Here is the new snippet of code. Notice that the if (count(... is on line 575 now instead of line 586, where it is now commented-out. 

...
567         $Data = $Table->PerformQuery($Where, $Sort);
568         if (trim($Input) == "")
569             $Output = $Table->FormatTableData($Data);
570         else {
571            $Output = "";
572            $Data = $Table->NormaliseData($Data);
573 //            print_r($Data);
574             foreach ($Data as $Row)
575             if (count($Row) > 1) {
576                 $Output .= pWikiDB_ExpandVariables($Input, $Row);
577             }
578 //            print($Output);
579         }
580         return WikiDB_Parse($Output, $Parser);
581     }
582 
583 // TODO - this is VERY crude at the moment, and may well fail in certain edge cases 
584 // (or even, certain 'non-edge' cases!)
585     function pWikiDB_ExpandVariables($Input, $Data) {
586 //        if (count($Data) > 1) {
587         // Substitute variables.  Note that we need to replace $ with \$ within $Value, to stop it being
588         // interpreted as a PHP variable reference.
589             foreach ($Data as $Key => $Value)
590                 $Input = preg_replace("/{{{" . $Key . "}}}/", str_replace('$', '\$', $Value), $Input);
591 //        }
592         return $Input;
593     }

So, what do you think? This fixes my problem, and my other <repeat> tag uses all seem to be working fine, but since I don't know the code base anywhere nearly as well as you do, could there be some other problems created by this hack?

-- Mdrayman 07:44, 6 July 2007 (BST)

I think this might be the same bug as reported by Jacob on the Talk:WikiDB/ToDo page. -- Mdrayman 06:20, 10 July 2007 (BST)

It may be the same bug (I have moved that bug to the top of this page), but I'm not sure. The problem you originally reported (error on line 587) is because counting a non-array variable returns 1 (if the variable is set). E.g. count(false) = 1. The fix is to modify line 584 so that instead of if (count($Data) > 0) {, we have if (is_array($Data) && count($Data) > 0) {, which I have done in the current live version. Please can you tell me if this fixes all, some or none of the above problems! --HappyDog 01:56, 13 July 2007 (BST)
PS - Image uploads are now enabled. I thought I had them setup, but they weren't enabled for the users group (only admins). Fixed now. --HappyDog 01:58, 13 July 2007 (BST)

Complex Templates Fail

When using the "template" parameter of the data tag, if i point it to a complex template that makes use of things such as those provided by the ParserFunctions extension, those functions do not get executed, and the code for them is displayed as text on the final rendered page.

After looking into the code a bit, my guess is that the code for the data tag is being executed *after* the page has been processed by the code for ParserFunctions.

Has anyone gotten this working or have any ideas for a work-around?

For me.. the other option was to put the data tag in the template itself.. but that doesn't work either (ie, you get {{{varname}}} as the data in the tabe instead of what you wanted).

If i figure something out i'll submit a patch or description here.

--Quasar 19:26, 25 July 2007 (BST)

Thanks - I will look into this. If you find anything out in the meantime then please post it here. Cheers --HappyDog 12:51, 26 July 2007 (BST)
I think this bug is somewhat related to the one I posted a little while ago, but I haven't found a solution for it yet. See the bug posting above. In order to get his second option working, we'd have to enable WikiDB to save data table information from data tags whenever a page is rendered and not only when it is saved after editing. -- Mdrayman 15:07, 28 July 2007 (BST)

Nesting repeat statement via templates

Template 'A' uses a repeat statement to pull all people from a table. Article 'B' uses another repeat statement to select a single person and display their details, through template 'A'. However it appears the nested repeat statement are getting confused. Hard to explain so created a demo here:

Is this a bug or am I just missusing the repeat statement?

Thanks Cocjh1 12:40, 11 December 2007 (GMT)

Fixed Bugs

Miscellaneous quickies

  • On table display, the definition is currently above the page title and sitenotice. This only seemed to happen since I set 'MediaWiki:Sitenotice', so maybe has something to do with that - or maybe I just never noticed it for some reason? --HappyDog 00:00, 6 January 2007 (GMT)
    • It was to do with the site notice. ParserBeforeStrip is being called once for each interface message that uses wiki text (I assume - it's being called for that one, anyway!). I now use a flag so that the code in my hook only executes the first time it is called for a page. This will only work if (a) the hook is called for every page view (i.e. it is not avoided by caching) and (b) it is always called first. I don't know the answer to either of these, so if the bug resurfaces please let me know! --HappyDog 03:30, 23 January 2007 (GMT)
  • If a table doesn't have a definition, the 'data' tab is not displayed in 1.6.8 (it's ok in 1.5.6). --HappyDog 03:33, 23 January 2007 (GMT)
    • FIXED - In 1.5.6 the first tab is always 'nstab-main' - at some point this changed to include the namespace (e.g. nstab-table). Now I just check the first 6 characters equal "nstab-".

Internal error deleting a page

I went to delete a page from my wiki and got the following error: 

Internal error
Detected bug in an extension! Hook wfWikiDB_ArticleDeleteComplete failed to return a value; should return true to continue hook processing or false to abort.

Backtrace:

#0 /html/w/includes/Article.php(2075): wfRunHooks('ArticleDeleteCo...', Array)
#1 /html/w/includes/Article.php(1864): Article->doDelete('not used in Wik...')
#2 /html/w/includes/Wiki.php(397): Article->delete()
#3 /html/w/includes/Wiki.php(48): MediaWiki->performAction(Object(OutputPage), Object(Article), Object(Title), Object(User), Object(WebRequest))
#4 /html/w/index.php(89): MediaWiki->initialize(Object(Title), Object(OutputPage), Object(User), Object(WebRequest))
#5 {main}

--AFCGOC 21:01, 15 January 2008 (GMT)

Well spotted! This bug exists because MediaWiki now requires that hooks always return a value - previously it assumed that no value meant 'continue' - now it realises that this is a potential source of confusion and programmer error, so the value is required. Fixed in WikiDB.php, r59. --HappyDog 23:34, 15 January 2008 (GMT)
Retrieved from ‘https://www.kennel17.co.uk/testwiki/index.php?title=WikiDB/Bugs&oldid=1988’