WikiDB/Bugs

PLEASE ADD NEW BUGS TO THE TOP
(note that this hasn't always been how we've done it, so bugs aren't necessarily in reverse-date order!)

Move page problem

(Moved from Talk:WikiDB#Move page problem)

Hi! I tried to move the page that contains the data for WikiDB from one namespace to another. The result was that I received the same data three times in the WikiDB. Using the {{_SourceArticle}} parameter indicates that the data are represented in the WikiDB database as being on the former, deleted page, on the new page and even on the special:Rename page. Of course, the later two cannot be edited or deleted and I cannot get rid of the redundant data. Can I delete them directly from the WikiDB database? And what rows in what tables shall I delete/change? Thanks a lot. --Okino 21:34, 12 September 2014 (UTC)

WikiDB & Cite Extensions

Hi,

I have installed WikiDB (r816 version) and Cite extensions. From some reason, Using the <repeat> tag within the Cite tags (ref and references) on same page causes the reference section to disappeared. My "workaround" is to locate the <repeat> after the reference section. Any idea what can be the reason?

TNX. (79.177.198.151)

Hi there. Could you please re-test with the latest version, as there were a couple of internal changes that may have fixed the problem. If it is still an issue, please post back here and I will investigate further.

Thanks for taking time to report the issue. --HappyDog 20:10, 5 September 2013 (UTC)

Hi, Thanks for the quick response! I have Mediawiki 1.16.2 installed (& PHP 5.4.6). I understood that I have to upgrade before installing the WikiDB latest version. Yes? --79.177.198.151 14:25, 6 September 2013 (UTC)

The latest version of WikiDB should run fine on MW 1.16 - it is 1.6 that support has been dropped for! I have updated the release notes to make this clearer, as I'm sure you're not the only person who will read it as 16! --HappyDog 15:47, 12 September 2013 (UTC)

I've installed the latest version and unfortunately the problem is still occurring  :(( --109.65.215.231 17:55, 17 September 2013 (UTC)

Thanks - I will look into it and see if I can figure out what's going on. --HappyDog 08:44, 18 September 2013 (UTC)

I have made a major update to WikiDB, which hopefully resolves this issue. I have not been able to install the Cite extension yet to test it, however. If you are able to download the latest version (v4 r906) and let me know if the problem remains, then that would be very useful. Otherwise I will try and install the Cite extension myself when I get some free time, and see what happens (though I'm not sure I know enough about the extension and how you are using it to really understand whether the issue is fixed). --HappyDog 21:31, 2 November 2014 (UTC)

BUG: Unwanted HTML <P>aragraph Settings (FIXED?)

The extracted field ($Input) is parsed with <p> xx </p> resulting in HTML displaying the field on a separate line.

utility.php
// Wrapper function to simplify text parsing.
 function WikiDB_Parse($Input, &$Parser, $LineStart = true) {
   $LocalParser = new Parser;
   $Output = $LocalParser->parse($Input, $Parser->mTitle, $Parser->mOptions, $LineStart, true);
   // print_r($Output);
   return $Output->getText();	
   }

ParserOutput Object
(
   [mText] => <p>lindsay 
   </p> 
   [mLanguageLinks] => Array 

Sorry, no Perl skills what-so-ever. --Lindsay keir 05:43, 26 November 2008 (GMT)

Can you please give me a bit more information. It would be useful to have the wikitext for the page that you entered, if that is possible. I can't tell much from the above. --HappyDog 14:21, 27 November 2008 (GMT)

NOT<repeat table="Companies3" criteria="Company name=Microsoft">'''{{{Founded}}}'''</repeat>IN-LINE

• NOT1492IN-LINE
• I just created a new page, enabled the // print_r($Output); and did a Firefox > View > Page Source

Why use a repeat tag when you already know the data that you want to display in it? Why not just use BEFORE'''Microsoft'''AFTER? --HappyDog 19:36, 27 November 2008 (GMT)

• Just an example - simpler the better.
• FIX(?)

  A quick test shows this didn't affect anything else - but I'll let you know if it turns bad --Lindsay keir 21:03, 28 November 2008 (GMT)

utility.php
// function WikiDB_Parse($Input, &$Parser, $LineStart = true) {
   function WikiDB_Parse($Input, &$Parser, $LineStart = false) {

OK - I see what you're trying to do, however the behaviour you describe is deliberate, as results are expected to be block-level elements rather than in-line (a bit like the way <pre> tags work, which is like

this

example). I can see the utility of making them inline (more like <code> tags) in the special case you have given above (i.e. where only a single row with a single field is returned), so perhaps the solution is to provide a dedicated tag for that, e.g. <fieldvalue table="Companies3" field="Founded" match="CompanyName" value="Microsoft">, which implicitly has a "LIMIT 1" clause (so we guarantee a single field from a single row). Or perhaps it would be better to make it an option to the <repeat> tag to specify whether to render the contents in-line (default being block output, as current), and maybe add a LIMIT argument to that? What are your thoughts? --HappyDog 23:25, 9 December 2008 (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)

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 > instead of > and < 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)

The code was indeed parsing the whole page manually on save, in order to extract the data, and therefore ignoring any tags it didn't recognise, including <nowiki> tags. I have fixed this in v1 r87 by running the page text through Parser::strip() before parsing it manually. It will upload the fix to this wiki shortly once a few other things I've been working on have been sorted out. Thanks for your patience. --HappyDog 13:26, 5 February 2008 (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)

I now also pass the page text through $Parser->replaceVariables() to expand parser functions such as the {{#expandafter:}} function. I'm not sure whether there are any negative side-effects of this (i.e. other elements that might be parsed which shouldn't be) so let me know if it throws anything up. Also not sure how compatible it is with newer versions of MW (only tested on 1.6.10). The update (r107) is not live yet - it will be included as part of the v2 update (coming soon!) but when it is I would appreciate if you could test this functionality properly. Cheers. --HappyDog 03:43, 18 February 2008 (GMT)

Error during installation

I'm running MW 1.13.1 and WikiDB v2 r136. After following the install scripts, I get the following error:

Warning: Cannot modify header information - headers already sent by (output started at /home/web/public_html/dev/wiki/extensions/WikiDB.php:7) in /home/web/public_html/dev/wiki/includes/WebResponse.php on line 10

Any thoughts as to what I am doing wrong? Is this a bug or a user error?

Thanks, Msa11usec 01:40, 29 September 2008 (BST)

This error is given when you try to set an HTTP header when some output has already been sent to the browser. The header contains information about the content, e.g. the type of character encoding, or whether to redirect to another page, and it must be sent before the content.

In this case it is likely to be cause by one of two things - either an error occurring causing a message to be output before the headers (though would I expect you to see that output too if that were the case) or (more likely) you have included some whitespace after a closing ?> tag (possibly in LocalSettings.php, or in one of the WikiDB files that you have downloaded - though I removed this from the source files to avoid this kind of error...). There are other things that could cause this, but those are the two most likely. Let me know if you need any more help. --HappyDog 10:34, 29 September 2008 (BST)

HappyDog, thanks much for addressing my question and I was able to solve it. I was doing something really, really dumb! Rather than copy and pasting from each .php file that needed to be in the extensions folder (and WikiDB.php), I was saving the HTML files and calling them php files. Once I copied and pasted, things worked much better. Thanks again for your help :) --Msa11usec 01:32, 30 September 2008 (BST)

No probs - glad I could help! :-) --HappyDog 12:51, 30 September 2008 (BST)

Can't apply templates at all on any page

I'm running MW 1.13.1 and WikiDB v2 r136. I am finding this to be a very useful extension. However, I can't seem to apply templates to any of my pages now. When I do add a template (such as {{test}}), I get the following error:

Fatal error: Call to a member function matchStartToEnd() on a non-object in /home/mpdadmin/public_html/dev/wiki/includes/parser/Parser.php on line 2788

If I go back to edit the page, the template is there. So I suppose really, the error is not that template use doesn't work, but that the adding of a template to any page causes an error. Any thoughts as to what I am doing wrong? Is this a bug or a user error?

Please let me know if you would like a test account on my wiki to see this behavior.

Thanks, --Msa11usec 13:58, 30 September 2008 (BST)

A little googling led me full circle to another user's inquiry. --Msa11usec 04:28, 2 October 2008 (BST)

I have finally gotten an update working, which seems to fix the problem. Please let me know if you encounter any further issues, and thanks for the bug report! --HappyDog 02:21, 23 October 2008 (BST)

Not heard anything, so resolving as FIXED. --HappyDog 01:55, 2 February 2011 (GMT)

Error on page save

I'm running MW 1.12 and WikiDB v2 r136. On pages that use the <data> tag, when editing, if I click the save button, instead of refreshing and showing the new / current version of the article with the applied edits, there appears to be a server side processing problem and the browser displays a blank page (all white, no text displayed). If then I go to the page by direct link, the newest version, including my changes, are displayed correctly. If I remove the <data> tags the entire problem is circumvented. Any ideas? Has anyone else seen this problem? -Alex.eisenhart 19:09, 28 August 2008 (BST)

Try adding the following line to the top of your LocalSettings.php file.

    ini_set("display_errors", true);

The blank page is because an error is occurring, but no errors are currently being displayed. Adding the above line tells PHP to display details of any errors that occur. Perform the same actions as described above and hopefully this time PHP will give you its error message - let me know what it says, and I'll try and sort out a fix. Remember to remove the line once things are working properly so errors are hidden, as occasionally error messages can give away information that could be used to compromise your site. --HappyDog 20:35, 28 August 2008 (BST)

Don't worry - I've managed to reproduce it locally and found a clumsy workaround - looking for a proper fix... --HappyDog 01:17, 10 September 2008 (BST)

Sorry, I thought I was watching this page. Just to confirm that my bug is the same as the one you located:

Notice: Undefined property: Parser::$mUniqPrefix in C:\Inetpub\wwwroot\includes\Parser.php on line 3223

Notice: Trying to get property of non-object in C:\Inetpub\wwwroot\includes\Parser.php on line 3281

Fatal error: Call to a member function setPair() on a non-object in C:\Inetpub\wwwroot\includes\Parser.php on line 3281

I had difficulty reproducing the error, just now. Playing in the sandbox, I was unable to cause this exception to occur - it was only when re-enabling the tags on a Wiki Cheatsheet page (for the casual users) was this exception generated. -Alex.eisenhart 16:50, 11 September 2008 (BST)

Might be related, might not be, at least I present a possible fix that should be applied either way:

Fatal error: Call to a member function addTemplate() on a non-object in /usr/share/mediawiki/includes/Parser.php on line 3050

happened all the time when trying to save an article with the WikiDB extension active, even if it didn't include any WikiDB stuff. I fixed it by calling $Parser->clearState(); directly after the $Parser = new Parser(); line in the code. No more errors now. I suggest adding this to trunk.

I have applied a fix to trunk which seems to solve the problem, can you please test using the latest version.

btw - the fix you described might well be tidier and more future-proof than the one I have used (though it should have the same effect), so I will try incorporating that method instead next time I work on the code. --HappyDog 02:21, 23 October 2008 (BST)

I'm the guy that wrote the addTemplate() comment and it seems that your changes fixed my problem, yes.

Sorry, I spoke too soon: Fatal error: Call to a member function setPair() on a non-object in /usr/share/mediawiki/includes/Parser.php on line 3281

My $Parser->clearState(); fixes it, again.

Fatal error: Call to a member function mergeArray() on a non-object in /usr/share/mediawiki/includes/Parser.php on line 651

• MediaWiki: 1.11.2 (the latest Debian version) popped up with this on a page save (view worked OK), and the data was saved. I used the sample

<data table="Companies" template="default">
name=Microsoft
founded=1492
revenue=$8
</data>
<repeat table="Companies"></repeat>

• Looks like the bug still continues; however, maybe, if someone would tell me where to put the My $Parser->clearState(); ? Thank you to whoever it was who replied

--Lindsay keir 00:27, 25 November 2008 (GMT)

Answer: In Hooks.php, directly after the $Parser = new Parser(); statement.

I have added the clearState() call to the current version of Hooks.php, so hopefully the problem is fixed now. Please let me know whether this solves the problem or not. I am still going to look into a better way of handling this, as the current method is still too fragile and may well break again in future versions of MW! --HappyDog 14:23, 27 November 2008 (GMT)

The parser was rewritten in version 3, so this kind of problem should be gone for good now! --HappyDog 01:55, 2 February 2011 (GMT)

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)

No further information provided. The bug as I described it has been FIXED, and I have never been able to reproduce the bug as initially described, so closing. --HappyDog 01:55, 2 February 2011 (GMT)

Problems when mixing different languages

So I am using an english wiki with wikiDB, but my language setting is set to German. When I create a table on my "User:Someguy" page, it works fine. However, when I look at the table data, it cites the source page as "Benutzer:Someguy", where "Benutzer" is German for "User". Therefore, the link will point to a wrong location, because even though my user settings are German, the wiki is still English, and the page's name really is "User:Someguy". --Kebap 10:27, 22 February 2011 (GMT)

Hi Kebap. Can you confirm whether this is actually a functional problem as well as a display problem (i.e. that the link doesn't work, as opposed to it does work, but displays the wrong text). Either way, I will look into fixing it ASAP. --HappyDog 23:27, 22 February 2011 (GMT)

Hi, I've done a bit more digging and managed to reproduce the bug. I've implemented a fix, which will be in the next release. --HappyDog 11:38, 23 February 2011 (GMT)

Thats great HappyDog, thanks a lot! So I don't have to confirm anymore, this was both a problem with display and functionality. --Kebap 11:44, 23 February 2011 (GMT)

Empty tables

Why do empty tables display anything? is this a feature or a bug? =) look for example what I created in Sandbox Osishkin 16:59, 13 July 2010 (BST)

An empty table should show the header columns, but no rows (or at least, that's my thought - this is up for discussion if others disagree). The fact that it shows a single row is a bug, which is fixed in my development version. --HappyDog 14:26, 16 July 2010 (BST)

Note that the fix made it into a release version at some subsequent point. Can't remember when. --HappyDog 20:54, 16 March 2012 (UTC)

Problems when using repeat-tag to populate other commands

I would like to gather some data in a wikiDB table, then use the data from that table to populate other commands, other extensions, etc. This won't work. I created a very simple example below.

• Create wikiDB data table

• (The above step is invisible, you have to edit this page to see the code) I have defined the data for Table:KebapTest (definition) (view data)

• Now I would like to read data from wikiDB data table and put it into some other form, in this example a simple wikitable
  • (This is buggy and will not produce the expected result. You will see the code for creating the wikitable, instead of the created wikitable.)

<tr><td>02.09.2010</td><td>1940</td><td>2520</td></tr><tr><td>04.10.2010</td><td>2445</td><td>3110</td></tr><tr><td>18.09.2010</td><td>2260</td><td>2850</td></tr>

Date	Africa	Asia

• This is what I would have expected:

Date	Africa	Asia
02.09.2010	1940	2520
18.09.2010	2260	2850
04.10.2010	2445	3110

• Finally: Yeah I know I could just let me show the wikitable by using the wikidb repeat tag without any modification. But really I want to do so much more than just creating a wikitable, send the data to other extensions, etc. So to rule out any errors in those other extensions, I want to first succeed at this easy example.

Date	Africa	Asia
02.09.2010	1940	2520
04.10.2010	2445	3110
18.09.2010	2260	2850

Thanks for any input on this. --Kebap 12:15, 22 February 2011 (GMT)

Hi Kebap. Tables are handled strangely in MediaWiki, and there is some discussion about an alternative repeat tag syntax which looks into how best to solve it. As yet, I still don't really have a solution in mind. Once I settle on something workable, I don't think it will take too long to code, however. It's basically down to a trade-off where currently there is no clear winner, so I find myself unable to make a decision. A good explanation of the problem is given here.

Note that this is a problem specific to MediaWiki's table handling, and may not necessarily be a problem when using other extensions, therefore this is not a good test case. Please re-test with some extension code (of the nature you are considering) and let me know how you get on.

Good luck! --HappyDog 23:32, 22 February 2011 (GMT)

Thanks, I will look into those discussions. Seems like there is much to think about. Looking forward to solving this.

I was actually first trying this with another extension, but this did not work at all. The extension seemed to go into some kind of endless loop and the server returned no wikipage as an answer at all. So I wanted to use easier test cases. Now I learn wikitables are also no good test-cases, I will have to think about other ones. --Kebap 12:49, 23 February 2011 (GMT)

Hi Kebap. Sorry it's taken so long, but the latest release of WikiDB has now fixed this issue, and it is possible to output tables via the <repeat> tag. You didn't go into specifics about the other issues you were having ('populating other commands') so I don't know if this fix resolves those problems too. Please log a new bug if there are any further issues now that this fix is in place.

Under the new syntax, your example, which looked like this:

<table class="wikitable" border="1;"> 
<tr><th>Date</th><th>Africa</th><th>Asia</th></tr> 
<repeat table="KebapTest"><tr><td>{{{Date}}}</td><td>{{{Africa}}}</td><td>{{{Asia}}}</td></tr></repeat> 
</table>

Should be written like this (white-space added for clarity - not required):

<repeat table="KebapTest">
    <header>
        <table class="wikitable" border="1;"> 
        <tr><th>Date</th><th>Africa</th><th>Asia</th></tr> 
    </header>

    <tr><td>{{{Date}}}</td><td>{{{Africa}}}</td><td>{{{Asia}}}</td></tr>

    <footer>
        </table>
    </footer>
</repeat>

Or you could use standard MediaWiki table syntax. The result of the above code is rendered like this:

Date	Africa	Asia
02.09.2010	1940	2520
04.10.2010	2445	3110
18.09.2010	2260	2850

I hope that resolves your issue. --HappyDog 16:06, 23 March 2013 (UTC)

Who take my "specialpage.php" ?

First Happy new year all ! We can tell it along january !!

Second : my installation : Mediawiki 1.20.2 Apache 2.2.20 PHP Version 5.3.8-pl0-gentoo Mysql 5.0.44 everything is readable at http://transfert.encyclopedie-afn.org/test.php on a dedicated serveur at OVH.com (France)

Third my problem : i'm trying to install wikidb which is exactly what i need for a big and important purpose. I've done each step of installation and when i add to localsettings the include .... wikiDB.php the system hang and tell me :

Warning: require_once(SpecialPage.php) [function.require-once]: 
failed to open stream: No such file or directory in 
/home/encyclo/sd/transfert/www/extensions/WikiDB/WikiDB.php on line 59
Fatal error: require_once() [function.require]: 
Failed opening required 'SpecialPage.php' (include_path='.:') 
in /home/encyclo/sd/transfert/www/extensions/WikiDB/WikiDB.php on line 59

I edit the wikiDB.php and i read :

//////////////////////////
// Include files
// Need to ensure that the IncludableSpecialPage class is defined before we define
// our own special pages, so include the appropriate MW class file (if not already
// included).
require_once("SpecialPage.php");

And obviously there is a problem because specialpages.php doesn't exists in root directory ....

What can i do, please Doctor ?

I'm french and my english is not a top one !! what is the meanning of :

so include the appropriate MW class file (if not already included).

--Websahib 09:39, 2 January 2013 (UTC)

Hi there. This looks like an issue introduced by changes made in MW 1.20. I have not tested WikiDB in 1.20 yet, but I will look into this and see if I can resolve the issue for you. Hopefully it won't take me long to resolve this, but if you need a quicker solution then downgrading to MW 1.18 or earlier should also fix the problem. --HappyDog 11:15, 2 January 2013 (UTC)

Hi HappyDog and thank you ! But i look in 1.18.6 (last update) and same problem ...! Then i think i'll wait YOUR solution of this problem, it's not in a hurry ! Take coffee and (chocolate) cake and work quietly !! :-D

Hmmm... I haven't found anything yet (though I've found a couple of things that MW 1.20 broke, so I would hold out until my next release before going back to 1.20, once you get this fixed). One thought I've had is that perhaps your include path is wrong. Is WikiDB actually located at /home/encyclo/sd/transfert/www/extensions/WikiDB/ or is it somewhere else? --HappyDog 22:53, 2 January 2013 (UTC)

--Websahib 08:55, 3 January 2013 (UTC) here is the line in my localsettings which exactly aim /home/encyclo/sd/transfert/www/extensions/WikiDB/

#require_once("extensions/WikiDB/WikiDB.php");

i tested also with no more effects :

#require_once("$IP/extensions/WikiDB/WikiDB.php");

i tested also rights of file and directory to check the right status, and all seem to be right ! i have another wiki with 1.15 version and i see, in localsettings of this version, the call to Defaultsettings.php which disapear in 1.20, is there an explanation of my problem ? I'm sorry to make you begin 2013 like that !! <3

Hi Websahib. I've been doing a bunch of testing in MW 1.20 and have fixed a number of issues that came up. I will be releasing a new version of WikiDB in the next few days, which I believe to have fixed all issues with the latest version of MW, and which will also include some new functionality! :-)

HOWEVER, none of the issues I found seem to be at all related to the problem you are experiencing. I have tried to reproduce it and I can't. My feeling is that PHP is looking for WikiDB in the wrong place. Could you please send me an e-mail containing your LocalSettings.php file, plus a copy of what you get if you add the following lines to the bottom of your LocalSettings.php (before the closing ?> tag, if there is one):

print("PATH: [" . ini_get("include_path") . "]\n\n");
print("CWD: [" . getcwd() . "]\n\n");
print_r($GLOBALS);
die();

Please send me the file itself (by saving it from within your browser), rather than just copy/pasting from the page. Hopefully that will give me enough info to figure out what's going wrong. Cheers --HappyDog 15:05, 9 January 2013 (UTC)

Actually, you can't attach files via that method. Please use 'view source' to get the formatted page output, and copy/paste from there. Cheers --HappyDog 15:07, 9 January 2013 (UTC)

---

--Websahib 08:18, 14 January 2013 (UTC) i think we have to look for efficiency !! 1) i have to test wikiDB on a pure new installation with no old problem... 2) it will be better to do with the new version ! It think there's no interest to spend time on an old version .... isn't it ?

Please send the files as described above. I am 99% confident that with that information I can fix the problem - either by a tweak to WikiDB or a tweak to your configuration, whichever is more appropriate. --HappyDog 09:53, 14 January 2013 (UTC)

---

I solved the problem by changing the line:

require_once("SpecialPage.php");

in the WikiDB.php to

 require_once("$IP/includes/SpecialPage.php");

--46.115.113.163 17:52, 19 April 2013 (UTC)

Hi Websahib - thanks for the update. I've done some digging, and it turns out that in MediaWiki 1.17 they removed the code which automatically set PHP's include_path setting to include the MediaWiki 'includes' directory. Therefore on any fresh install of MW 1.17 and above, the extension would exhibit the behaviour you describe. That also explains why I wasn't experiencing the issue myself (my LocalSettings.php was generated ages ago, in a previous MW version). I have fixed this in the latest version of WikiDB, which is now available for download (this fix is the only change from the previous version). Cheers - HappyDog 10:14, 20 April 2013 (UTC)

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:

• User:Cocjh1/Nested_Repeats

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

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

Hi Cocjh1. The next version of WikiDB will fix this issue. It has already been deployed on this site, so your test page at User:Cocjh1/Nested_Repeats now shows the correct output. I am doing a bit more testing of this, and some other template-expansion-related issues that I have fixed, and hope to do a release of the updated code soon. Sorry it has taken so long! --HappyDog 16:12, 7 August 2014 (UTC)

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)

How?

• I guess the sample code should actually have a colon - but I couldn't get it to work. The criteria= is NOT done and the whole table is returned. Any help anyone? --Lindsay keir 06:07, 26 November 2008 (GMT)

{{#expandafter:repeat|table="handelaars" criteria="id={{{templateparametername}}}">{{{tablefield}}} }}

• Yes - the code should have a colon as you describe, but I don't have any experience with this parser function so can't comment any further on the remaining issue, I'm afraid. --HappyDog 14:19, 27 November 2008 (GMT)

• Any chance of asking Mdrayman ? - I spent way too much time trying to get this to work; but being able to use templates with WikiDB is just too good a function to pass up. I'll type up the How-To page. Just a working sample is all I need. --Lindsay keir 21:19, 27 November 2008 (GMT)

WikiDB now supports this natively, and this will be available in the next release (hopefully soon). Now, the example you give (where there is a template variable in the criteria) will work as expected without requiring the ExpandAfter extension. --HappyDog 20:30, 7 August 2014 (UTC)

An idea of way to solve this problem ?

--Websahib 10:27, 7 January 2013 (UTC)

You know i have lost my "specialpage.php" !! I have installed WikiDB on an old platform with MW 1.15 and try to use WikiDB to solve my wish ...

But as other people, there's a lot of problems to use it with templates aand it never work right ! or never work only !!

if i understand the difficulty for changing the use of repeat and the necessity to "hard coded" the order of repeat with :

<repeat table="exemple" criteria="Field=Target"> ..... </repeat>

and that criteria must be, well et definitivly hard coded, i suggest a way tu use it on another way if possible.. If we write :

<repeat table="exemple" criteria="Field=Target">{{Template:XXX}}</repeat>

The template instruction will never be executed ... (if it contain conditions and other choice instruction..more) Can you modifiy the code (i'm not enough "mediawikited" to write this code) to another syntax eg :

<repeat table="exemple" criteria="Field=Target" template="XXX"></repeat>

that solve this problem, first the TEMPLATE:XXX will be explored, than it will be passed as argument to the basic :

<repeat table="exemple" criteria="Field=Target"></repeat>

i don't know if it's possible .. sorry if my question is too .....

The aim is to pass {{{Fields}}} in the repeat process ....{{{Fields}}} define in the template..

I am about to release a new version of WikiDB, but I will make this issue my priority for the version that will follow that, as it is annoying for a lot of people, myself included. The next version of WikiDB will be the last version to support MW1.6 (i.e. PHP 4), and possibly support for a number of subsequent versions will also be dropped, depending on what features I need and when they were introduced. Dropping support for older versions should make it easier to fix this issue as the way templates are parsed has changed a couple of times since then. Allowing a template attribute may be an alternative solution if I can't fix it properly, but I'd rather do a proper fix so templates work as expected. Thanks for the suggestion, and for bringing this back to my attention. --HappyDog 15:27, 9 January 2013 (UTC)

--Websahib 15:39, 9 January 2013 (UTC) Great ! and a good idea to reduce support to "on the way" versions !! I can't help but sendig 2 you a lot of energy !!! :-D <3

The next version of WikiDB (out soon) will include a fix for this, which makes it very easy to do what you want.

You need to pass the relevant fields through to your template, but other than that it is simple to use, as follows:

<repeat table="exemple" criteria="Field=Target">{{Template:XXX|Field1={{{Field1}}}|Field2={{{Field2}}}}}</repeat>

I hope that resolves your issue - sorry it took a little while! Please let me know if you have any other questions or problems with this, once the new version has been released.

--HappyDog 21:01, 7 August 2014 (UTC)

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)

The next version of WikiDB (to be released soon) will resolve all these issues. The use of complex templates is working (possibly it is already working in the current release, as I closed the item you linked to a while ago, but either way it is working now) and also the ability to use data tags within templates is also now working.

Thanks for your help in diagnosing and suggesting fixes for this issue - sorry it took a while to fix! --HappyDog 21:17, 7 August 2014 (UTC)

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)

To my knowledge, this was fixed by the change I made as per my previous comment, and I have not encountered this problem or had it reported by any users since then, so moving to the 'fixed bugs' list. --HappyDog 21:37, 7 August 2014 (UTC)

"/" character in repeat tag argument value

I'm experiencing a bug when using the repeat tag, which I suspect is related to using '/' character. I'm using a repeat tag within a template, so that values to the criteria are passed from the template arguments. Some of the values are not parsed as expected. I inserted print outs before and after the parsing of the criteria parameter. i.e. this line

$Args[$key] = $Parser->recursiveTagParse($temp , $Frame );

and I see that some of the values are parsed as <!--LINK 0:0--> etc.

The only parameters where this happens are one where the actual template argument name contains a '/' character, and another one where the parsed value contains the character. So to iilustrate it looks something like this

criteria="arg1={{{bla/bla}}},arg2={{{templatearg}}},arg3={{{anothertemplatearg}}}"

I'm also pretty sure I was able to reproduce this on the test wiki as well. See Testslash Osishkin 20:52, 8 March 2012 (UTC)

I can confirm that there is something funny going on here. There was an error in your template (you had used {{{arg2/arg2}}} instead of just {{{arg2}}}, which meant the template would never give a result, but I've fixed that. I've also updated the page at Testslash (and the related template) to more clearly show the difference in rendering between in-line and templated versions. I will investigate further. --HappyDog 21:23, 8 March 2012 (UTC)

I actually used arg2/arg2 on purpose! I have template with an argument name that contains '/', which I want to pass on to a repeat tag. The value itself does not contain the characgter, but still this gets wrongfully parsed, in the same manner Osishkin 21:33, 8 March 2012 (UTC)

I see, so you think it is actually an issue in the MW template parser, rather than WikiDB? --HappyDog 22:50, 8 March 2012 (UTC)

Well, not exactly. The template parser can definitely handle the '/' character, either as an argument name, or a value. And WikiDB can definitely handle it as an argument value. But somehow the combination created a bug. Which to my understanding means that WikiDB is probably not using it correctly in some manner Osishkin 07:48, 9 March 2012 (UTC)

From my testing (I've updated Testslash it seems that there is absolutely no problem, with either MW or WikiDB, if the name of the template argument contains a / character. However, there is definitely an issue in WikiDB when the argument value contains a /. I will investigate further. --HappyDog 10:30, 9 March 2012 (UTC)

OK - I've tested this further, but outputting the arguments that get passed into the <repeat> tag in both cases. In normal use we get this:

Array (
  [table] => Slash
  [criteria] => stage=test/me,department=football
  [sort] => stage
) 

However, when the arguments are passed into a template, we get this:

Array (
  [table] => Slash
  [criteria] => stage={{{arg1}}},department={{{arg2}}}
  [sort] => {{{arg3/arg3}}}
) 

So what's happening is MW is calling the WikiDB tag with unexpanded arguments, which obviously don't match anything in the DB. Presumably it will also expand any resulting arguments that we send back from the function (if, for example, the data in one of the fields contained "{{{arg1}}}"), which would also cause problems.

At the moment, I know have no idea how to deal with - or if it's even possible! I will need to look into it, but it might take a while to come up with a workable solution. In the meantime, if you have any suggestions or pointers, please pass them on! --HappyDog 20:58, 16 March 2012 (UTC)

This has been fixed in the latest dev version, which is live on this wiki. If you visit the Testslash page now, you can see that the rendering matches the expected rendering. The next version of WikiDB will include this fix. Thanks for your detailed bug report and your help diagnosing the issue. --HappyDog 21:50, 7 August 2014 (UTC)

Fix indexes for sqlite

In sqlite, indexes must be unique within the DB (not just within the table), and the MW approach is to prefix them with the table name. Tim is currently working on an sqlite back-end for MW, so in order to support this when it is released the DB definitions should be updated to include the table name in any indexes. This does not affect the column names, so should not require any changes for current users of the WikiDB extension. --HappyDog 01:53, 15 January 2009 (GMT)

This has been done in the latest development version. The schema is now compatible with SQLite and this will be available in the next release. At this stage, I am not guaranteeing full compatibility, but it is known to install properly on SQLite databases, at least. --HappyDog 23:03, 31 August 2014 (UTC)

SetupTables.php erroring out on sqlite

SetupTables.php errors out when I run it on my install. I would assume that it is because I am using sqlite as my database backend.

Error Message:

Checking existence of tables...
NOT FOUND: wikidb_tables
NOT FOUND: wikidb_rowdata
NOT FOUND: wikidb_fielddata
Creating missing tables...A database query error has occurred.
Query: CREATE TABLE IF NOT EXISTS wikidb_tables (
 table_namespace 		INTEGER NOT NULL,
 table_title 			TEXT  NOT NULL,
 table_def 				BLOB NOT NULL default ,
 redirect_namespace	 	INTEGER DEFAULT NULL,
 redirect_title 			TEXT  DEFAULT NULL,
 PRIMARY KEY  			(table_namespace,table_title),
 INDEX redirect_ns_title	(redirect_namespace,redirect_title)
 )
Function: DatabaseBase::sourceFile( /path/to/mediawiki/extensions/WikiDB/maintenance/sql/tables.sql )
Error: 1 near "INDEX": syntax error

--92.196.86.6 16:26, 27 February 2014 (UTC)

I manually edited the tables.sql and got it to work. My Version of the tables.sql can be found in this gist. --92.196.86.6 16:48, 27 February 2014 (UTC)

Well, it looks like you are using some functions that do not work with SQLite. If I try and filter things using criteria="x!=1", I get a database error. Inspecting the MediaWiki debug log, I noticed the line SQL ERROR: no such function: IF. Are there any plans for SQLite compatibility? --92.196.86.6 17:13, 27 February 2014 (UTC)

Hi there - thanks for your comments and your gist! I would love for the extension to work on SQLite, but I really don't have any experience of it so it is difficult for me to know where the issues are. From your gist, and a bit of a web search, it seems that you can't define indexes as part of the CREATE TABLE statement, so I will incorporate your changes and update WikiDB to add these as separate statements after the CREATE TABLE. This should resolve any issues creating the schema.

However, in terms of the query SQL that WikiDB uses, I'm afraid I don't really know where to start. I don't really know anything about SQLite and also don't currently have the ability to test it, so it is not easy for me to resolve this. However, I will happily accept patches or advice on this issue, or to collaborate with someone who has the necessary experience, as I would love to support SQLite.

--HappyDog 11:29, 28 March 2014 (UTC)

My latest dev version of WikiDB has been updated to include variants of your fixes in the various .sql files, as well as some other updates to the command-line scripts, which mean that it now installs correctly on SQLite databases, and the command-line scripts should now all work correctly. These changes will be in the next release.

The remaining SQLite issues you mention (particularly in relation to query criteria) will be investigated further, now that I have set up an SQLite install of MediaWiki for testing on. I hope (but don't guarantee) that these will all be resolved in the next release, also. --HappyDog 23:07, 31 August 2014 (UTC)

I have fixed all known issues relating to SQLite in my local development branch and so the next release of WikiDB will officially support SQLite as a database backend. The specific issue you reported above when using the <repeat> was because SQLite does not support the IF() function of MySQL. The code has been updated to use the CASE WHEN statement instead, which should be supported by all database back-ends.

Thank you for reporting the issue and for your help in diagnosing/fixing the problems.

--HappyDog 12:27, 7 September 2014 (UTC)

Using Templates

• HappyDog ... you were asking why I was so interested in combining your really-really-great WikiDB with templates - Here's the answer. Now my documentation is varied based on only changing a template definition or two. Just copy-and-paste for installs, etc., etc. Thanks for simplifying my life.
• I put this here because I didn't know where else. Besides, I believe it answers some of the above bugs, which are due to the > sign being html'd into &_gt_; and not being recognized within your code.

--Lindsay keir 01:03, 30 November 2008 (GMT)

These steps describe how WikiDB can be accessed from within templates and so generate variable pages. For Example ... Your router(s) have a set of external ports specific to each computer. Instead of documenting each computer and port you can display them as variables on a wiki page. What you are trying to achieve is a wiki display showing

 Name:   600-server
 HTTPS:  60000 ==> 443
 Webmin: 60001 ==> 10000
 SSH:    60022 ==> 22
 Rsync:  60099 ==> 873
Verification
 HTTPS: https://aaaa.accessmyhome.net/60000
Webmin: https://aaaa.accessmyhome.net/60001
   SSH: ssh -p 60022 aaaa.accessmyhome.net

... that is changeable depending on the specific computer and router.

WikiDB Tables

• Table:Computers is defined with

> id :string
> use :string
> ip :string 
> ports :string 
<data table="Computers" template="default">
  id = server
  ip = aaaa
  ports= 600 
</data>
<data table="Computers" template="default">
  id= backup
  ip = bbbb
  ports= 601 
</data>

• Table:Routers is defined with

> id :string
> ip :string
> https :string
> webmin :string
> ssh :string 
> rsync :string 
<data table="Routers" template="default">
  id = aaaa
  ip = aaaa.accessmyhome.net
  https = 00
  webmin = 01
  ssh = 22
  rsync = 99
</data>
<data table="Routers" template="default">
  id = bbbb
  ip = bbbb.accessmyhome.net
  https = 00
  webmin = 01
  ssh = 22
  rsync = 99
</data>

Template.Definitions

• Template:{{Red}} is defined as (because I want to highlight the field)

<span style="color:red"><tt>{{{1}}}</tt></span>

• Template:{{Computers}} which does the Table Lookup, is defined as

{{#repeatt:repeat|table="Computers" criteria="id={{{1}}}">{{Red|{{{{{{2}}}}}}}}}}

• Template:{{Routers}} which does the Table Lookup, is defined as

{{#repeatt:repeat|table="Routers" criteria="id={{{1}}}">{{Red|{{{{{{2}}}}}}}}}}

• Template:{{ComputerID}} which changes which Computer is displayed, , is defined as

server

• Template:{{RouterID}} which changes which Router is displayed, , is defined as

aaaa

Wiki.Page

==== {{Computers|{{ComputerID}}|id}} ====
* Firewall ports 
   Name:   {{Computers|{{ComputerID}}|ports}}-{{Computers|{{ComputerID}}|id}}
   HTTPS:  {{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|https}} ==> 443
   Webmin: {{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|webmin}} ==> 10000
   SSH:    {{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|ssh}} ==> 22
   Rsync:  {{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|rsync}} ==> 873
* Verification
  HTTPS: https://{{Routers|{{RouterID}}|ip}}/{{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|https}}
 Webmin: https://{{Routers|{{RouterID}}|ip}}/{{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|webmin}}
    SSH: ssh -p {{Computers|{{ComputerID}}|ports}}{{Routers|{{RouterID}}|ssh}} {{Routers|{{RouterID}}|ip}}

• Note that even the Wiki section is a variable
• So, when {{ComputerID}}=server and {{RouterID}}=aaaa the top sample information is displayed.
• And, when {{ComputerID}}=backup and {{RouterID}}=bbbb the following sample information is displayed.

 Name:   601-backup
 HTTPS:  60100 ==> 443
 Webmin: 60101 ==> 10000
 SSH:    60122 ==> 22
 Rsync:  60199 ==> 873
Verification
 HTTPS: https://bbbb.accessmyhome.net/60100
Webmin: https://bbbb.accessmyhome.net/60101
   SSH: ssh -p 60122 bbbb.accessmyhome.net

• Naturally my actual Computers and Routers tables contain more information than this.

Installation

• Utility.php returns the field surrounded by <p>...</p> tags - we don't want this as a new line is displayed.
  • Change from $LineStart = true to ...

 # extensions/WikiDB/Utility.php
 function WikiDB_Parse($Input, &$Parser, '''$LineStart = false''') {

• repeatt.php - Install this program, hook, whatever they're called ...
  • This is a copy - modification of ExpandAfter.php tailored for the WikiDB extension ...
  • Get the code from a source view - HTML automatically changes the display - making this line look stupid.

       $attrs = str_replace('>', '>', $attrs);

repeatt.php

  Save as           .../extensions/WikiDB/repeatt.php
  # LocalSettings.php 
  include_once("extensions/WikiDB/repeatt.php"); 

<?php
/*
Install:
  Save as           ... /var/lib/mediawiki/extensions/WikiDB/repeatt.php
  LocalSettings.php ... include_once("extensions/WikiDB/repeatt.php"); 

Description:
  Allows the use of a WikiDB table from a Wiki:template
  The 'table=' must be hard-coded (a WikiDB restriction) so each table must have it's own template.

Template:  {{staff}} contains
           {{#repeatt:repeat|table="Staff" criteria="userid={{{1}}}">{{{{{{2}}}}}}}}

Example:      Send error mail to {{staff|admin1|email}}
   Generates: <repeat table="Staff" criteria="userid=admin1">{{{email}}}</repeat>
   Generates: Send error mail to admin1@server
   Tip:   Also return as colour-coded
      {{Red}}   = <span style="color:red"><tt>{{{1}}}</tt></span>
      {{Staff}} = {{#repeatt:repeat|table="Staff" criteria="userid={{{1}}}">{{Red|{{{{{{2}}}}}}}}}}

Function Code:
*  This is a copy - modification of ExpandAfter.php tailored for the WikiDB extension ...
*/
function repeattInit() {
        global $wgParser;
        $wgParser->setFunctionHook( 'repeatt', 'repeattHook' );
}
function repeattHook($parser) {
        $args = func_get_args();
        array_shift($args);
        $tag = array_shift($args);
        $attrs = array_shift($args);
        $attrs = str_replace('>', '>', $attrs);
// print_r("\n repeatt ==>  <$tag $attrs</$tag>\n");
        return "<$tag $attrs</$tag>";
}
function repeattLanguageGetMagicHook( &$magicWords, $langCode = 'en' ) {
        $magicWords['ea2']    = array( 0, 'ea2');
        $magicWords['repeatt']    = array( 0, 'repeatt');
        return true;
}
$wgExtensionFunctions[] = 'repeattInit';
$wgHooks['LanguageGetMagic'][] = 'repeattLanguageGetMagicHook';
?>

Hi Lindsay.

I have finally managed to find a way to get WikiDB to handle the situation you describe natively, without requiring your repeatt hook!

I have used the code you supplied above to set up an example page on this wiki, which demonstrates the code in use: WikiDB/Templates and repeatt tests.

As you can see, it now all works as you want without the need for the extra markup or additional parser hook.

I am doing a little more testing and polishing of this change, and hope to release a new version of WikiDB very soon, which includes this fix. In the meantime, please feel free to experiment on this wiki and let me know if you have any feedback!

Thanks for your bug report and your detailed test case, which really helped to get to the bottom of the issue and to have some example code to test against.

--HappyDog 18:45, 7 September 2014 (UTC)