Editing WikiDB/Bugs

'''<big>PLEASE ADD NEW BUGS TO THE TOP</big>'''

== Open Bugs ==

Bugs are moved to the 'closed bugs' section at the bottom of the page when complete.  Scroll to the end if you can't find your recently-reported bug.

===All Tables are Undefined, no data tab===

I have defined tables using the table="tablename" code, with two different tables. One is on a dedicated table page (Table:Matches), table="Matches", the other is within a normal wiki page where I've created a table, table="Matches1". Both of these show up on SpecialPages:UndefinedTables. When I try to query the Matches table, it says "Bad criteria: Invalid table name 'matches'." 

Also, there is no data tab? When I click on the link that goes &action=viewdata, it says "No such action
The action specified by the URL is invalid. You might have mistyped the URL, or followed an incorrect link. This might also indicate a bug in the software used by ..."

I've tried rebuild and everything. What should I do?


--Confused User 14 September 2019

: Hi there - thanks for getting in touch.  Can you please let me know what version of MediaWiki you are using, and also confirm that you are using the latest version of WikiDB.  I don't know if your wiki is public, but I'd be happy to take a direct look, if that's OK.  Feel free to [[Special:EmailUser/HappyDog|e-mail me]] if you'd rather not post it publicly.  No problems if you'd rather not.  Either way, once I have the version information I'll look into this in a bit more detail.
: Kind regards --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 21:00, 20 September 2019 (BST)

===Multiple Links In Single Cell===
If I place two internal links in a single cell with datatype "link", <code>[[Page1]], [[Page2]]</code> the wiki returns <nowiki>[[Page1, Page2]]</nowiki>, where Page 1 is plaintext and Page2 is the correct link. The solution is to enter <code>Page1]], [[Page2</code> without the wrapping brackets and let the parser do its work. <code>Page1]], [[Page2]], [[Page3</code> works similarly.
--[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 02:51, 14 May 2018 (BST)

: The <code>link</code> data type allows you to enter a single link, only.  If you wrap it in link markers (e.g. <code><nowiki>[[My link]]</nowiki></code> instead of <code>My link</code>) then it is intelligent enough to remove the markers, other than that, what you enter is treated as the destination page title, verbatim.
: What you have highlighted is a bug in the extension, in that it isn't detecting invalid links.  In both of your above cases, the output should be an empty string as what you have entered is not valid for the type (it contains characters that are not allowed in a link).  This is similar to how a non-numeric value is handled for a number field.
: The correct way to achieve what you want is via the <code>wikitext</code> data type, which allows for arbitrary wiki text, which will be rendered in full.
: I hope that answers your question.  Either way, I am going to leave this bug report open until the code is fixed to handle invalid link fields correctly.
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 23:57, 15 June 2018 (BST)

=== BUG: Unwanted HTML <nowiki><P></nowiki>aragraph Settings (FIXED?) ===
The extracted field ($Input) is parsed with <nowiki><p> xx </p></nowiki> 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
 (
  <nowiki>  [mText] => <p>lindsay </nowiki>
  <nowiki>  </p> </nowiki>
  <nowiki>  [mLanguageLinks] => Array </nowiki>
Sorry, no Perl skills what-so-ever. --[[User:Lindsay keir|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.  --[[User:HappyDog|HappyDog]] 14:21, 27 November 2008 (GMT)
 <nowiki>NOT<repeat table="Companies3" criteria="Company name=Microsoft">'''{{{Founded}}}'''</repeat>IN-LINE</nowiki>
* NOT<repeat table="Companies3" criteria="Company name=Microsoft">'''{{{Founded}}}'''</repeat>IN-LINE
* I just created a new page, enabled the <tt>// print_r($Output);</tt> 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 <nowiki>BEFORE'''Microsoft'''AFTER</nowiki>? --[[User:HappyDog|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 --[[User:Lindsay keir|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 <code>&lt;pre&gt; tags</code> work, which is like <pre>this</pre> example).  I can see the utility of making them inline (more like <code>&lt;code&gt; tags</code>) 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. <code><nowiki><fieldvalue table="Companies3" field="Founded" match="CompanyName" value="Microsoft"></nowiki></code>, 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 &lt;repeat&gt; 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? --[[User:HappyDog|HappyDog]] 23:25, 9 December 2008 (GMT)

== Fixed Bugs ==

<div class="FixedBugs"><!-- Deliberately unclosed, to make moving bugs easier. -->

=== Miscellaneous quickies ===

* <s>On [[table:Companies2|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? --[[User:HappyDog|HappyDog]] 00:00, 6 January 2007 (GMT)</s>
** 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! --[[User:HappyDog|HappyDog]] 03:30, 23 January 2007 (GMT)
* <s>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). --[[User:HappyDog|HappyDog]] 03:33, 23 January 2007 (GMT)</s>
** 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-".

=== $wgArticle - non-object on special pages ===
<small>(Moved from [[Talk:WikiDB/Files/WikiDB.php#$wgArticle - non-object on special pages]])</small>

FYI: I currently get the following error whenever trying to access Special: or MediaWiki: pages:

'''Fatal error: Call to a member function on a non-object in /hsphere/local/home/dduran/innoviki.com/extensions/WikiDB.php on line 63'''

<pre>
59.	function wfWikiDB_AddActionTabs(&$ContentActions) { 
60.		global $wgArticle, $action; 
61.		global $wgWikiDBNamespaces;
62.		
63.		$Title = $wgArticle->getTitle(); 
64.		if ($Title->isTalkPage())
65.			$Title = $Title->getSubjectPage();
</pre>

There's some discussion [http://mail.wikipedia.org/pipermail/mediawiki-l/2006-May/012154.html here] about the merits of $wgArticle vs. $wgTitle between MW1.5 and MW1.6. Not sure I understand but wanted to point it out.

I'm running: MW:1.6.5 PHP:4.3.11 (apache) MySQL:4.0.26-standard-log

: Hi - Thanks for the heads up - I think I've fixed this now:

 59.	function wfWikiDB_AddActionTabs(&$ContentActions) { 
 60.		global '''$wgTitle''', $action; 
 61.		global $wgWikiDBNamespaces;
 62.		
 63.		'''$Title =& $wgTitle;''' 
 64.		if ($Title->isTalkPage())
 65.			$Title = $Title->getSubjectPage();

: Let me know if this works on 1.6.5 (it seems to work fine here on 1.5.6). --[[User:HappyDog|HappyDog]] 19:58, 1 October 2006 (BST)

:: Works like a charm! I'm up and starting to play around. Thanks. :) Is there a decent reference for these MW functions? I was trying to use $wgTitle->getTitle(); which apparently is incorrect. [[User:Blckdmnd99|Blckdmnd99]] 21:46, 1 October 2006 (BST)

::: I've not found one yet - I just dip into the MW source, or ask on IRC.  Check [http://meta.wikimedia.org/ meta] though, there's some good stuff there, even if it's not always easy to find... --[[User:HappyDog|HappyDog]] 22:52, 1 October 2006 (BST)

=== Internal error deleting a page ===

I went to delete a page from my wiki and got the following error:
<pre>
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}

</pre>
--[[User:AFCGOC|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 [[../Files/WikiDB.php|WikiDB.php]], r59. --[[User:HappyDog|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 <nowiki><data></nowiki> 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 <nowiki><data></nowiki> tag without it adding records to the real table?
<pre>
<nowiki><data table="ServiceCustomerJobs">
job_num=
account_num=
description=
date_called=
date_serviced=
completion_time=
job_page=
satisfaction=
complaint_page=
</data></nowiki>
</pre>

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

-- [[User:Mdrayman|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><nowiki></nowiki> tags, the table still showed up with the record defined above.

Any clues as to what's going on here?

-- [[User:Mdrayman|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 <code>&amp;gt;</code> instead of <code>&gt;</code> and <code>&amp;lt;</code> instead of <code>&lt;</code> when creating your example data tags. --[[User:HappyDog|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. -- [[User:Mdrayman|Mdrayman]] 20:02, 5 July 2007 (BST)

Is your $pRegexDataTag ignoring the <nowiki><nowiki></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><nowiki></nowiki> tags do prevent MediaWiki from using any of the WikiDB functions to render a table entry or <nowiki><repeat></nowiki> 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 <nowiki><data></nowiki> tags regardless of the presence of the <nowiki><nowiki></nowiki> tags. -- [[User:Mdrayman|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 &lt;nowiki&gt; 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. --[[User:HappyDog|HappyDog]] 13:26, 5 February 2008 (BST)

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

I mentioned [[WikiDB/Roadmap#Bugs|above]] about using the [http://www.mediawiki.org/wiki/Extension:ExpandAfter ExpandAfter] MediaWiki extension to populate fields of the <nowiki><repeat></nowiki> tag inside of a template.  Now, this extension works with the <nowiki><repeat></nowiki> tag, however, it does not work quite right with the <nowiki><data></nowiki> tag.  Below are two attempts to add a table entry to a new table called '''ExpandAfterTable'''.

Not using ExpandAfter:
<pre>
<nowiki>
<data table="ExpandAfterTable" template="default">
value1=nothing
value2=something
value3=everything
</data>
</nowiki>
</pre>

Using ExpandAfter:
<pre>
<nowiki>
{{#expandafter:data|table="ExpandAfterTable" template="default"|
value1=nothing
value2=something
value3=everything
}}
</nowiki>
</pre>

Now, what happens when I use the <nowiki><data></nowiki> 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 <nowiki><repeat></nowiki> tag, the table printout appears on the page containing the <nowiki><data></nowiki> 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 [http://www.mediawiki.org/wiki/Extension:ExpandAfter 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! -- [[User:Mdrayman|Mdrayman]] 20:02, 5 July 2007 (BST)

During my investigation of the <nowiki><repeat></nowiki> tag bug below, I think I might know why the <nowiki><data></nowiki> 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 <nowiki><data ...> ... </data></nowiki> text in the page because it is hidden inside either the ExpandAfter extension's markup or a template.  Since WikiDB looks for the <nowiki><data ...> ... </data></nowiki> 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 <nowiki><data></nowiki> 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 <nowiki><data></nowiki> 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 ''every''time a page is rendered.  Would there be some way to detect if data changed and save it during a render only if data changed?  -- [[User:Mdrayman|Mdrayman]] 08:40, 6 July 2007 (BST)

: I now also pass the page text through $Parser->replaceVariables() to expand parser functions such as the <nowiki>{{#expandafter:}}</nowiki> 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. --[[User:HappyDog|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, 
[[User:Msa11usec|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. --[[User:HappyDog|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 :)  --[[User:Msa11usec|Msa11usec]] 01:32, 30 September 2008 (BST)

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

=== function wfWikiDB_ArticleSaveComplete ===
<small>(Moved from [[Talk:WikiDB/Files/Hooks.php#function wfWikiDB_ArticleSaveComplete]])</small>

{| border=1
! MediaWiki
! Server OS
! PHP
! MySQL
! WikiDB
|-
| 1.15.1
| W2k3 Server en
| 5.3.0 (apache2handler)
| 5.1.37
| $Rev: 177 $
|}
; Symptoms:
: saving a page with a &lt;data&gt; tag shows an error
: "Warning:  Parameter 3 to wfWikiDB_ArticleSaveComplete() expected to be a reference [...]"
; Solution:
: I removed the reference indicator &amp; from all but the first two parameters of the function definition
[[User:Gonesoft|Gonesoft]] 07:50, 13 November 2009 (GMT)

:: Hi Gonesoft.  Are a file/line number for this error message reported?  The fix you suggest would work fine for WikiDB, but the description of the bug implies a bug in either the core MW software, or the documentation at MediaWiki.org, so it would be good to have a bit more info in order to ensure it gets sorted out for other users. --[[User:HappyDog|HappyDog]] 21:12, 16 November 2009 (GMT)

Here goes:
<pre><nowiki>
Warning: Parameter 3 to wfWikiDB_ArticleSaveComplete() expected to be a reference, value given 
  in C:\xampp\htdocs\wiki\includes\Hooks.php on line 117

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

Backtrace:

#0 C:\xampp\htdocs\wiki\includes\Article.php(1779): wfRunHooks('ArticleSaveComp...', Array)
#1 C:\xampp\htdocs\wiki\includes\Article.php(1472): Article->doEdit('<data table="Co...', '', 102)
#2 C:\xampp\htdocs\wiki\includes\EditPage.php(1027): 
  Article->updateArticle('<data table="Co...', '', true, false, false, '')
#3 C:\xampp\htdocs\wiki\includes\EditPage.php(2483): EditPage->internalAttemptSave(false, false)
#4 C:\xampp\htdocs\wiki\includes\EditPage.php(449): EditPage->attemptSave()
#5 C:\xampp\htdocs\wiki\includes\EditPage.php(340): EditPage->edit()
#6 C:\xampp\htdocs\wiki\includes\Wiki.php(510): EditPage->submit()
#7 C:\xampp\htdocs\wiki\includes\Wiki.php(63): MediaWiki->performAction(Object(OutputPage), 
  Object(Article), Object(Title), Object(User), Object(WebRequest))
#8 C:\xampp\htdocs\wiki\index.php(116): MediaWiki->initialize(Object(Title), Object(Article), 
  Object(OutputPage), Object(User), Object(WebRequest))
#9 {main}
</nowiki></pre>
hth ... looks to me like there's a constant value passed somewhere in the caller chain. Maybe updateArticle at #2?
<br>[[User:Gonesoft|Gonesoft]] 13:10, 17 November 2009 (GMT)

: Obviously, it's been some time since this was written, but here's an update:
:# The actual error in your trace above is here: <code>Detected bug in an extension! Hook wfWikiDB_ArticleSaveComplete failed to return a value;</code>.  This arose because wfWikiDB_ArticleSaveComplete() wasn't returning a proper result.  In earlier versions of MW, returning nothing indicated everything was OK and that the calling code should continue with the next hook, and returning anything else indicated an error string to be output.  At some point this was changed to allow three return values: an error string, if an error occurred; TRUE if the function completed successfully and remaining hooks should be run; and FALSE if the function completed successfully, but remaining hooks should ''not'' be run.  At this point a check was added for NULL (the old default value) and an error raised in this case, to force extension writers to update to the new system.  This was fixed a long time ago in my code, but it was done as part of general fix-up, so I didn't think to update the wiki.
:# The pass-by-reference warning you were getting appears to have been a documentation problem, as [http://www.mediawiki.org/w/index.php?title=Manual:Hooks/ArticleSaveComplete&diff=next&oldid=219281 the documentation for ArticleSaveComplete] has now been updated to remove the reference indicator.  I don't know if this is because MW changed, or whether the documentation was just wrong, but either way it has been fixed there and also in my code. 
: Thanks for reporting the issue (I wouldn't have spotted and fixed it without you) - sorry about the slow response! :-)
: --[[User:HappyDog|HappyDog]] 12:43, 13 September 2010 (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 <nowiki>{{test}}</nowiki>), 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, 
--[[User:Msa11usec|Msa11usec]] 13:58, 30 September 2008 (BST)

:A little googling led me full circle to [http://www.kennel17.co.uk/testwiki/Talk:WikiDB/Tutorial#When_will_the_next_version_available.3F another user's inquiry]. --[[User:Msa11usec|Msa11usec]] 04:28, 2 October 2008 (BST)

:: I have finally gotten [[WikiDB/Files|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! --[[User:HappyDog|HappyDog]] 02:21, 23 October 2008 (BST)

::: Not heard anything, so resolving as FIXED.  --[[User:HappyDog|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 <nowiki><data></nowiki> 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 <nowiki><data></nowiki> tags the entire problem is circumvented.  Any ideas? Has anyone else seen this problem? -[[User:Alex.eisenhart|Alex.eisenhart]] 19:09, 28 August 2008 (BST)

: Try adding the following line to the top of your LocalSettings.php file.
<php>
    ini_set("display_errors", true);
</php>
: 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. --[[User:HappyDog|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... --[[User:HappyDog|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.  -[[User:Alex.eisenhart|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 <tt>$Parser->clearState();</tt> directly after the <tt>$Parser = new Parser();</tt> 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 [[WikiDB/Files|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. --[[User:HappyDog|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 <tt>$Parser->clearState();</tt> 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
<pre>
<data table="Companies" template="default">
name=Microsoft
founded=1492
revenue=$8
</data>
<repeat table="Companies"></repeat>
</pre>
* Looks like the bug still continues; however, maybe, if someone would tell me '''where''' to put the My <tt>$Parser->clearState();</tt> ? '''Thank you to whoever it was who replied'''
--[[User:Lindsay keir|Lindsay keir]] 00:27, 25 November 2008 (GMT)
: '''Answer:''' In [[WikiDB/Files/Hooks.php|Hooks.php]], directly after the <tt>$Parser = new Parser();</tt> statement.

:: I have added the clearState() call to the current version of [[WikiDB/Files/Hooks.php|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! --[[User:HappyDog|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! --[[User:HappyDog|HappyDog]] 01:55, 2 February 2011 (GMT)

=== Error in Normalise ===
I noticed a bug:<br>
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:

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

-[[User:Jacob|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? --[[User:HappyDog|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. --[[User:HappyDog|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". --[[User:Kebap|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. --[[User:HappyDog|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.  --[[User:HappyDog|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. --[[User:Kebap|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]] [[User:Osishkin|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. --[[User:HappyDog|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. --[[User:HappyDog|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

<data table="KebapTest">
  Date=02.09.2010
  Africa=1940
  Asia=2520
</data>
<data table="KebapTest">
  Date=18.09.2010
  Africa=2260
  Asia=2850
</data>
<data table="KebapTest">
  Date=04.10.2010
  Africa=2445
  Asia=3110
</data>

* (The above step is invisible, you have to edit this page to see the code) I have defined the data for Table:KebapTest [[Table:KebapTest|(definition)]] [http://www.kennel17.co.uk/testwiki/index.php?title=Table:KebapTest&action=viewdata (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.)

<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>

* This is what I would have expected:

<table class="wikitable" border="1;"> 
<tr><th>Date</th><th>Africa</th><th>Asia</th></tr> 
<tr><td>02.09.2010</td><td>1940</td><td>2520</td></tr>
<tr><td>18.09.2010</td><td>2260</td><td>2850</td></tr>
<tr><td>04.10.2010</td><td>2445</td><td>3110</td></tr>
</table>

* 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.

<repeat table="KebapTest"></repeat>

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

: Hi Kebap.  Tables are handled strangely in MediaWiki, and there is some discussion about [[WikiDB/Repeat tag syntax|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 [[Talk:WikiDB/Repeat tag syntax#Leave it as it is|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! --[[User:HappyDog|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. --[[User:Kebap|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 &lt;repeat&gt; 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:
<pre>
<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>
</pre>
::: Should be written like this (white-space added for clarity - not required):
<pre>
<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>
</pre>
::: Or you could use standard MediaWiki table syntax.  The result of the above code is rendered like this:
<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>
::: I hope that resolves your issue. --[[User:HappyDog|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).''

--[[User:Websahib|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.  --[[User:HappyDog|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? --[[User:HappyDog|HappyDog]] 22:53, 2 January 2013 (UTC)

::: --[[User:Websahib|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 [[Special:EmailUser/HappyDog|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):
<php>
print("PATH: [" . ini_get("include_path") . "]\n\n");
print("CWD: [" . getcwd() . "]\n\n");
print_r($GLOBALS);
die();
</php>
:::: 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 --[[User:HappyDog|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 --[[User:HappyDog|HappyDog]] 15:07, 9 January 2013 (UTC)

----
: --[[User:Websahib|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. --[[User:HappyDog|HappyDog]] 09:53, 14 January 2013 (UTC)

----
: I solved the problem by changing the line: <pre>require_once("SpecialPage.php");</pre> in the WikiDB.php to <pre> require_once("$IP/includes/SpecialPage.php");</pre>--[[Special:Contributions/46.115.113.163|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 - [[User:HappyDog|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 [[User:Cocjh1|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! --[[User:HappyDog|HappyDog]] 16:12, 7 August 2014 (UTC)

=== Error when using repeat in a template ===

* If I use a <nowiki><repeat></nowiki>-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. ([http://en.wikipedia.org/wiki/User:Stephanvaningen Stephanvaningen], 23 May 2007)
:* Like this: <nowiki><repeat table="handelaars" criteria="id={{{templateparametername}}}">{{{tablefield}}}</repeat></nowiki>
:* After that, I tried this:
:** <nowiki><repeat table="handelaars" criteria="id=50">{{template}}</repeat></nowiki>, 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 <nowiki><repeat></nowiki> tag inside a Template using template parameters to feed the fields of the <nowiki><repeat></nowiki> tag using a MediaWiki Extension called [http://www.mediawiki.org/wiki/Extension:ExpandAfter ExpandAfter].  Follow the link to learn how to install it.  Once installed, use it like this in your template: '''<nowiki>{{#expandafter|repeat|table="handelaars" criteria="id={{{templateparametername}}}">{{{tablefield}}} }}</nowiki>''' What this extension does is parse out the template parameters BEFORE calling the WikiDB code for the <nowiki><repeat></nowiki> tag.  What's ''really cool'' about this ExpandAfter extension is that it works for ANY <nowiki><xxx></nowiki> tag in MediaWiki, not just the <nowiki><repeat></nowiki> or <nowiki><data></nowiki> tags for WikiDB, but for others too, such as any tags introduced by other extensions. -- [[User:Mdrayman|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? --[[User:Lindsay keir|Lindsay keir]] 06:07, 26 November 2008 (GMT) 
 <nowiki>{{#expandafter:repeat|table="handelaars" criteria="id={{{templateparametername}}}">{{{tablefield}}} }}</nowiki>
*: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. --[[User:HappyDog|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.  --[[User:Lindsay keir|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.  --[[User:HappyDog|HappyDog]] 20:30, 7 August 2014 (UTC)

=== An idea of way to solve this problem ? ===

--[[User:Websahib|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 :
<pre>
<repeat table="exemple" criteria="Field=Target"> ..... </repeat>
</pre>
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 :
<pre>
<repeat table="exemple" criteria="Field=Target">{{Template:XXX}}</repeat>
</pre> 
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 :
<pre>
<repeat table="exemple" criteria="Field=Target" template="XXX"></repeat>
</pre>
that solve this problem, first the TEMPLATE:XXX will be explored, than it will be passed as argument to the basic :
<pre>
<repeat table="exemple" criteria="Field=Target"></repeat>
</pre>
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. --[[User:HappyDog|HappyDog]] 15:27, 9 January 2013 (UTC)

::--[[User:Websahib|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:
<pre>
<repeat table="exemple" criteria="Field=Target">{{Template:XXX|Field1={{{Field1}}}|Field2={{{Field2}}}}}</repeat>
</pre>
::: 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.
::: --[[User:HappyDog|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.

--[[User:Quasar|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 --[[User:HappyDog|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.  [[WikiDB/Bugs#BUG: data tag does not create new table entry when using ExpandAfter MW extension|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. -- [[User:Mdrayman|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! --[[User:HappyDog|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 <nowiki><repeat></nowiki> 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 <nowiki><repeat></nowiki> tag.

[[Image:WikiDB_Repeat_Filter_Zero_Result_Error.png|right|300px]]
At the right is a screenshot of my Firefox browser window in the wiki page using the <nowiki><repeat></nowiki> 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.

-- [[User:Mdrayman|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 <nowiki><repeat></nowiki> 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:

# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{job_page}}} : {{{description}}}
# {{{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.

-- [[User:Mdrayman|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 <nowiki><repeat></nowiki> tag is '''exactly equal''' to the number of ''fields'' in the table specified in the <nowiki><repeat></nowiki> tag.

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

<pre>
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     }
</pre>

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?
-- [[User:Mdrayman|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 <nowiki><repeat></nowiki> 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.

<pre>
...
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     }
</pre>

So, what do you think?  This fixes my problem, and my other <nowiki><repeat></nowiki> 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?

-- [[User:Mdrayman|Mdrayman]] 07:44, 6 July 2007 (BST)

I think this might be the same bug as reported by [[User:Jacob|Jacob]] on the [[Talk:WikiDB/Roadmap]] page. -- [[User:Mdrayman|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 <code>if (count($Data) > 0) {</code>, we have <code>if (is_array($Data) && count($Data) > 0) {</code>, 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! --[[User:HappyDog|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. --[[User:HappyDog|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. --[[User:HappyDog|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 &lt;!--LINK 0:0--&gt; 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]]
[[User:Osishkin|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. --[[User:HappyDog|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 [[User:Osishkin|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? --[[User:HappyDog|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 [[User:Osishkin|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. --[[User:HappyDog|HappyDog]] 10:30, 9 March 2012 (UTC)

::::: OK - I've tested this further, but outputting the arguments that get passed into the &lt;repeat&gt; 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! --[[User:HappyDog|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. --[[User:HappyDog|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. --[[User:HappyDog|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. --[[User:HappyDog|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:
<code>
 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
</code>
--[[Special:Contributions/92.196.86.6|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 [https://gist.github.com/malexmave/9254016 this gist]. --[[Special:Contributions/92.196.86.6|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 <code>criteria="x!=1"</code>, I get a database error. Inspecting the MediaWiki debug log, I noticed the line <code>SQL ERROR: no such function: IF</code>. Are there any plans for SQLite compatibility? --[[Special:Contributions/92.196.86.6|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.
::: --[[User:HappyDog|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. --[[User:HappyDog|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 &lt;repeat&gt; 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.
::::: --[[User:HappyDog|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.
--[[User:Lindsay keir|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: <nowiki>https://aaaa.accessmyhome.net/60000</nowiki>
 Webmin: <nowiki>https://aaaa.accessmyhome.net/60001</nowiki>
    SSH: ssh -p 60022 aaaa.accessmyhome.net
... that is changeable depending on the specific computer and router.
==== WikiDB Tables ====
* '''Table:Computers''' is defined with
<pre>
> 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>
</pre>
* '''Table:Routers''' is defined with
<pre>
> 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>
</pre>

==== Template.Definitions ====
* Template:<nowiki>{{Red}}</nowiki> is defined as (because I want to highlight the field)
 <nowiki><span style="color:red"><tt>{{{1}}}</tt></span></nowiki>
* Template:<nowiki>{{Computers}}</nowiki> which does the Table Lookup, is defined as
 <nowiki>{{#repeatt:repeat|table="Computers" criteria="id={{{1}}}">{{Red|{{{{{{2}}}}}}}}}}</nowiki>
* Template:<nowiki>{{Routers}}</nowiki> which does the Table Lookup, is defined as
 <nowiki>{{#repeatt:repeat|table="Routers" criteria="id={{{1}}}">{{Red|{{{{{{2}}}}}}}}}}</nowiki>
* Template:<nowiki>{{ComputerID}}</nowiki> which changes which Computer is displayed, , is defined as
 server
* Template:<nowiki>{{RouterID}}</nowiki> which changes which Router is displayed, , is defined as
 aaaa

==== Wiki.Page ====
<pre>
==== {{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}}
</pre>
* Note that even the Wiki section is a variable
* So, when <nowiki>{{ComputerID}}</nowiki>=server and <nowiki>{{RouterID}}</nowiki>=aaaa the top sample information is displayed.
* And, when <nowiki>{{ComputerID}}</nowiki>=backup and <nowiki>{{RouterID}}</nowiki>=bbbb the following sample information is displayed.
  Name:   601-backup
  HTTPS:  60100 ==> 443
  Webmin: 60101 ==> 10000
  SSH:    60122 ==> 22
  Rsync:  60199 ==> 873
 '''Verification'''
  HTTPS: <nowiki>https://bbbb.accessmyhome.net/60100</nowiki>
 Webmin: <nowiki>https://bbbb.accessmyhome.net/60101</nowiki>
    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 <nowiki><p>...</p></nowiki> tags - we don't want this as a new line is displayed. 
** Change from <tt>'''$LineStart = true'''</tt> to ...
<pre>
 # extensions/WikiDB/Utility.php
 function WikiDB_Parse($Input, &$Parser, '''$LineStart = false''') {
</pre>
* '''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.
        <nowiki>$attrs = str_replace('&gt;', '>', $attrs);</nowiki>
===== repeatt.php =====
<pre>
  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('&gt;', '>', $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';
?>
</pre>

: 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.
: --[[User:HappyDog|HappyDog]] 18:45, 7 September 2014 (UTC)


=== Error message while trying to create an SMW Property ===
<small>(Moved from [[Talk:WikiDB/Bugs#Error message while trying to create an SMW Property]])</small>

Hi,

I'm getting the following error when trying to create an SMW (Semantic Mediawiki) property of any type (String/Text/Number):

Fatal error: Unexpected object type passed to WikiDB::pSetupPageObjects(): smwpropertypage in C:\wamp\www\wiki\extensions\WikiDB\includes\classWikiDB.php on line 101.

The property is eventually created, but I wonder whether it cause any damage...

WikiDB version: r816
SMW version: 1.7.0.2

--[[Special:Contributions/82.80.126.182|82.80.126.182]] 09:19, 4 November 2013 (UTC)

: This should be fixed in v4 r909.  The code was previously expecting an object of the Article class, but now it also accepts any child of that class, so SMWPropertyPage should now be handled correctly by this function.  I have not tested whether there are other conflicts with the SMW extension, but this specific issue has been resolved.  Thanks for taking the time to report it. --[[User:HappyDog|HappyDog]] 13:45, 8 November 2014 (UTC)

=== Move page problem ===
<small>(Moved from [[Talk:WikiDB#Move page problem]])</small>

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 <nowiki>{{_SourceArticle}}</nowiki> 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. --[[User:Okino|Okino]] 21:34, 12 September 2014 (UTC)

: Hi Okino.  There was a change in MediaWiki 1.15 which broke page moves, which I didn't spot until your bug report.  I believe this has been resolved in the latest version of WikiDB (v4 r906).  Please install the latest version to stop this issue re-occurring.  To fix existing data you should run the rebuild script as per the [[WikiDB/CHANGELOG#r906|CHANGELOG]].  Please let me know if that resolves the problem for you, and thanks for the bug report! --[[User:HappyDog|HappyDog]] 22:03, 2 November 2014 (UTC)

::Hi, HappyDog. I have sent you an e-mail, but I don't know if you received it. The problem was solved with the new version, nevertheless I had to return to the old version because of the problem I describe above <small>''[edit - now [[#Template parsing|below]]]''</small>. Thanks anyway. --[[User:Okino|Okino]] 23:25, 13 March 2015 (UTC)

::: Glad this one's fixed.  I have also fixed the other issue, so hopefully the latest version will be working for you now. --[[User:HappyDog|HappyDog]] 23:34, 21 April 2015 (UTC)

=== Template parsing ===
In the last [[WikiDB/CHANGELOG#r906|CHANGELOG]] you describe some changes regarding the template parsing and you write the templates should work ok. When I installed the new version on my wiki, the former workaround to parse templates was not working, but also an expected way of templates inside the REPEAT tag was not working. I had to return back to the older version. I tried to experiment with it in my [[User:Okino/Sandbox 2|sandbox]], where you can find that the templates are not parsed the propper way. Or am I doing something wrong? Can you show me, how I shall do, what is shown in the sandbox - the "should look like" section shows, I believe, rather well, what the output should be. Thanks a lot. --[[User:Okino|Okino]] 23:25, 13 March 2015 (UTC)

: Hi Okino,
: I have been looking into this on-and-off since you wrote to me, but haven't quite figured out how to handle it.  The issue is to do with the fact that there are some situations where the content needs to be escaped, and some where it doesn't, and it is not really clear how to tell them apart.  I am still investigating and will let you know if I make any progress.
: Part of this is down to how different data types are handled, so I have made a general test-case for these, here: [[WikiDB/DataTypeTests]].  As you can see, everything renders fine in a &lt;data&gt; tag or in a default &lt;repeat&gt; tag, but some items are rendered incorrectly when output as part of a custom &lt;repeat&gt; tag.  This is the issue that needs to be resolved first.  Whether or not it will also resolve your problem remains to be seen!
: Thank you for your patience while I investigate this.
: -- [[User:HappyDog|HappyDog]] 11:44, 15 March 2015 (UTC)

:: Sorry it took a while, but I eventually tracked it down.  Documentation of the MediaWiki parser is somewhat scant, but after a lot of prodding, poking, var-dumping and hair-pulling, it ended up being a single-line change!  The test-case you posted is now passing, so hopefully the problem is now fully resolved.  Thanks for your detailed bug report. --[[User:HappyDog|HappyDog]] 23:34, 21 April 2015 (UTC)

=== wfViewPrevNext() removed in MediaWiki 1.24 ===

Hello,

I'm using WikiDB with MediaWiki 1.24.1. When trying to view table data I receive the error

<nowiki>Fatal error: Call to undefined function wfViewPrevNext() in /home/wiki/extensions/WikiDB/includes/Hooks.php on line 230</nowiki>

It appears that wfViewPrevNext has been deprecated since 1.19 and removed in 1.24. [http://www.gossamer-threads.com/lists/wiki/mediawiki-cvs/484921] states that the alternative is Language::viewPrevNext()

I've worked around the issue by replacing the call (poorly) as follows:

<pre>
global $wgLang;
$Output = $wgLang->viewPrevNext(
$Title,
$Offset,
$ItemsPerPage,
wfCgiToArray("action=viewdata"),
$IsLastPage
);
</pre>

And it seems to be working. I doubt it's a good long term solution but hopefully it's useful as a starting point.

: Thanks for the bug report.  This has been fixed in [[WikiDB/CHANGELOG#r972|v4, r972]].  --[[User:HappyDog|HappyDog]] 08:26, 24 April 2015 (UTC)

:: Thanks for the quick response! Look forward to using it. --[[Special:Contributions/198.48.130.201|198.48.130.201]] 06:35, 26 April 2015 (UTC)

::: No problem :-)  Let me know if you encounter any other issues. --[[User:HappyDog|HappyDog]] 12:45, 27 April 2015 (UTC)

=== Language::specialPage() removed in MediaWiki 1.24 ===
Sorry for my bad English.<br>
Hello,<br>
I'm using WikiDB with MediaWiki 1.28.0-rc.1. When trying to view all defined tables I receive the error<br>

<nowiki>Fatal error: Call to undefined method Language::specialPage() in WikiDB\includes\SpecialPages.php on line 143</nowiki><br>
The method Language::specialPage() was removed (deprecated since 1.24).<br>
Do you have a solution?<br>
In advance already times thank you.

: Thanks for the bug report.  I will look into it and hopefully provide a fix shortly. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 18:03, 29 January 2017 (GMT)

:: This has been fixed in the latest release, v4 (r1333).  Thank you for taking time to report.  --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 18:49, 29 January 2017 (GMT)

:: Thank you for your quick response, i'll test it right away<BR>
Unfortunately, I have received a new error:<BR>
<nowiki>Call to undefined method SkinVector::makeLinkObj() in WikiDB\includes\SpecialPages.php on line 417</nowiki><BR>
And another mistake is wfMsg(), you should use wfMessage() :-) in SpecialPages.php<BR>
Apologize for the new error :-(

::: I have fixed both of these issues in my development version.  I don't have a version of MediaWiki 1.28 to test on at the moment, so I'm reluctant to release another version of WikiDB that might still contain bugs.  If you'd rather I released what I've done so far for you to test then let me know, otherwise I will release it once I've tested it a bit more thoroughly.
::: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 00:40, 1 February 2017 (GMT)
::: Thank you for your quick response. I like testing your development version. I have a local test installation, this is not a problem.
:::: I've been through the release notes for MW 1.27 and 1.28.  A large number of deprecated items were removed in 1.27, including the items you brought to my attention.  I have found a couple more removed items that will cause things to break in some situations and am in the process of fixing these.  Once they are resolved, I will release a new version that will hopefully fix all compatibility issues with the newest MediaWiki releases.
:::: I hope to bring you an update soon.  Thank you for your patience and your offer of help - I may need it yet!
:::: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 21:42, 23 February 2017 (GMT)
::::: It took a bit longer than I thought, but I've now fixed all deprecated items listed in the release notes for 1.26, 1.27 and 1.28.  Hopefully this means that the extension is now fully compatible with these MediaWiki versions.  Sorry that it took a little while to complete this - it seems like they went a bit deprecation-crazy in MW 1.27!  Please let me know if you encounter any further problems with the latest release, and thank you, once again, for your patience.  --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 00:23, 18 March 2017 (GMT)

=== Install error on MW 1.28 ===
Installing WikiDB (I assume r1345, but don't know how to confirm) with MW 1.28, PHP 7.0.16, and MariaDB 10.1.21 on CentOS 7.3, all wiki pages return nothing more than: <tt>[WNQ-GvzBcRQg1EY2-ycRxQAAAAo] 2017-03-23 21:33:14: Fatal exception of type "DBQueryError"</tt>

All I've done so far is unzip WikiDB and add <tt>require_once("extensions/WikiDB/WikiDB.php");</tt>

Suggestions? [[Special:Contributions/72.1.73.217|72.1.73.217]] 21:44, 23 March 2017 (GMT)

: It looks like you haven't completed the [[WikiDB/Installation|install process]].  That is the error I would expect to see if the required DB tables have not been added to your database yet.
: If you still have issues having run the command-line scripts then please let me know.
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 10:59, 26 March 2017 (BST)

:: You're right.  I stopped at step 2 because I tried the "You can check that the extension is loaded properly by visiting the Special:Version page..." which didn't work.  If I just keep going even though the wiki is temporarily broken, after finishing the install, it works fine.  Thanks for the tip. [[Special:Contributions/107.0.253.14|107.0.253.14]] 14:22, 17 April 2017 (BST)

::: Good spot.  I have fixed WikiDB so that you no longer get this error when the extension is enabled but the tables have not been installed, so the Special:Version page is now accessible again at the point indicated on the install page.  This fix will be included in the next release.  Thank you for reporting this.  --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 22:16, 22 April 2017 (BST)

=== WikiDB on Mediawiki 1.29 ===
Hi,

I have installed WikiDB (4,r1345) for MediaWiki 1.29 on Ubuntu 16.04.3. Along with the following extensions that come ootb with mediawiki:
*Interwiki
*Renameuser
*ImageMap
*InputBox
*ParserFunctions
*SytaxHighlight
*WikiEditor

Upon editing any page, even a page that does not contain markup for WikiDB, i will get errors such as the following:

<pre>
[31de752f471edd1547325ff0] /mediawiki/index.php?title=Test_Page_4&action=submit Error from line 172 of /var/lib/mediawiki/extensions/WikiDB/includes/classWikiDB.php: Call to undefined method Article::getContent()

Backtrace:

#0 /var/lib/mediawiki/extensions/WikiDB/includes/Hooks.php(364): WikiDB::PageUpdated(Title)
#1 /var/lib/mediawiki/includes/Hooks.php(186): efWikiDB_LinksUpdate(LinksUpdate)
#2 /var/lib/mediawiki/includes/deferred/LinksUpdate.php(177): Hooks::run(string, array)
#3 /var/lib/mediawiki/includes/jobqueue/jobs/RefreshLinksJob.php(277): LinksUpdate->doUpdate()
#4 /var/lib/mediawiki/includes/jobqueue/jobs/RefreshLinksJob.php(122): RefreshLinksJob->runForTitle(Title)
#5 /var/lib/mediawiki/includes/jobqueue/JobRunner.php(289): RefreshLinksJob->run()
#6 /var/lib/mediawiki/includes/jobqueue/JobRunner.php(189): JobRunner->executeJob(RefreshLinksJob, Wikimedia\Rdbms\LBFactorySimple, BufferingStatsdDataFactory, integer)
#7 /var/lib/mediawiki/includes/MediaWiki.php(972): JobRunner->run(array)
#8 /var/lib/mediawiki/includes/MediaWiki.php(958): MediaWiki->triggerSyncJobs(integer, MediaWiki\Logger\LegacyLogger)
#9 /var/lib/mediawiki/includes/MediaWiki.php(910): MediaWiki->triggerJobs()
#10 /var/lib/mediawiki/includes/MediaWiki.php(731): MediaWiki->restInPeace(string)
#11 /var/lib/mediawiki/includes/MediaWiki.php(750): MediaWiki->{closure}()
#12 /var/lib/mediawiki/includes/MediaWiki.php(554): MediaWiki->doPostOutputShutdown(string)
#13 /var/lib/mediawiki/index.php(43): MediaWiki->run()
#14 {main}
</pre>
I have another wiki that is running on 1.28.2 with WikiDB without issue (however it isn't running as many ootb extensions). I am not very experienced with the mediawiki backend, could there be an issue with an incompatible plugin? or perhaps with the latest version of MediaWiki?

When I try RebuildWikiDB.php, it errors with the following
<pre>
Updating 5 pages: [8647d28b5517aa93bfaa25c0] [no req]   Error from line 249 of /var/lib/mediawiki/extensions/WikiDB/maintenance/install_functions.inc: Call to undefined method Revision::getText()
Backtrace:
#0 /var/lib/mediawiki/extensions/WikiDB/maintenance/RebuildWikiDB.php(106): ReparseArticle(string)
#1 {main}
PHP Fatal error:  Uncaught Wikimedia\Rdbms\DBTransactionError: Explicit transaction still active. A caller may have caught an error. in /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php:1152
Stack trace:
#0 [internal function]: Wikimedia\Rdbms\LoadBalancer->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\DatabaseMysqli))
#1 /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1490): call_user_func_array(Object(Closure), Array)
#2 /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1175): Wikimedia\Rdbms\LoadBalancer->forEachOpenMasterConnection(Object(Closure))
#3 [internal function]: Wikimedia\Rdbms\LoadBalancer->approveMasterChanges(Array)
#4 /var/lib/mediawiki/includes/libs/rdbms/lbfactory/LBFactory.php(183): call_user_func_array(Array, Array)
#5 [internal function]: Wikimedia\Rdbms\LBFactory->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\LoadBalancer), 'approveMasterCh...', Array)
#6 /var/lib/mediawiki/includes/libs/rdbms/lbfactory/LBFactorySimple.php(149): call_user_ in /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php on line 1152

Fatal error: Uncaught Wikimedia\Rdbms\DBTransactionError: Explicit transaction still active. A caller may have caught an error. in /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php:1152
Stack trace:
#0 [internal function]: Wikimedia\Rdbms\LoadBalancer->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\DatabaseMysqli))
#1 /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1490): call_user_func_array(Object(Closure), Array)
#2 /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php(1175): Wikimedia\Rdbms\LoadBalancer->forEachOpenMasterConnection(Object(Closure))
#3 [internal function]: Wikimedia\Rdbms\LoadBalancer->approveMasterChanges(Array)
#4 /var/lib/mediawiki/includes/libs/rdbms/lbfactory/LBFactory.php(183): call_user_func_array(Array, Array)
#5 [internal function]: Wikimedia\Rdbms\LBFactory->Wikimedia\Rdbms\{closure}(Object(Wikimedia\Rdbms\LoadBalancer), 'approveMasterCh...', Array)
#6 /var/lib/mediawiki/includes/libs/rdbms/lbfactory/LBFactorySimple.php(149): call_user_ in /var/lib/mediawiki/includes/libs/rdbms/loadbalancer/LoadBalancer.php on line 1152
</pre>

Any help would be appreciated.

: Hi there.  Thanks for the bug report.  It looks like some internal APIs have been removed from MediaWiki in v1.29, which cause WikiDB to break.  I will try and issue a fix soon, but in the meantime the only way to run WikiDB is on 1.28 or earlier, I'm afraid.  I will try and resolve this as quickly as possible, though --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 23:04, 21 August 2017 (BST)

:: Thanks HappyDog! I am in no rush to upgrade, I am happy to stay on 1.28 for the time being.

::: Both of these issues should now be fixed, in [[WikiDB/CHANGELOG#r1376|v4 (r1376)]].  I have done some basic testing on 1.29 and all showstoppers have been fixed, but it is possible there are still some edge-cases.  Please let me know if you encounter any further issues, and thank you so much for your patience!  --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 00:31, 10 October 2017 (BST)

=== WikiDB & Cite Extensions ===

Hi,

I have installed WikiDB (r816 version) and [http://www.example.com Cite] extensions.
From some reason, Using the <nowiki><repeat></nowiki> tag within the Cite tags (ref and references) on same page causes the reference section to disappeared.
My "workaround" is to locate the <nowiki><repeat></nowiki> 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. --[[User:HappyDog|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? --[[Special:Contributions/79.177.198.151|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! --[[User:HappyDog|HappyDog]] 15:47, 12 September 2013 (UTC)

:::: I've installed the latest version and unfortunately the problem is still occurring  :(( --[[Special:Contributions/109.65.215.231|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. --[[User:HappyDog|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).  --[[User:HappyDog|HappyDog]] 21:31, 2 November 2014 (UTC)

::::::: I am marking this issue as resolved, as I've not heard anything since my major reworking in 2014, which I suspect has fixed the issue.  If anyone encounters this issue again, please let me know, but otherwise I will assume it is fixed. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 00:37, 10 October 2017 (BST)

===500 Error on Edit Pages===
Wiki returns the following error on all edit pages (&action=edit). Am able to retrieve data, and table pages work as expected.

<code>Fatal error: Call to undefined method MediaWiki\MediaWikiServices::getLinkRenderer() in .../extensions/WikiDB/includes/Utility.php on line 383</code>

Running MediaWiki 1.27 and latest version of WikiDB

Also receiving the following error.

<code>Fatal error: Call to a member function getNamespace() on null in .../extensions/WikiDB/includes/BuiltInTypes.php on line 321</code>

--[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 03:58, 7 May 2018 (BST)

: Thanks for letting me know - I will investigate and get back to you as soon as I can. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 11:52, 7 May 2018 (BST)

::I appreciate the help. I have since had to disable <code>$wgExtraNamespaces = array(100 => "Table", 101 => "Table_Talk",); $wgWikiDBNamespaces = array(100 => true,);</code> because it conflicted with one of my custom name spaces. Could this be related?--[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 13:41, 7 May 2018 (BST)

::: The table namespace needs to be defined as a new pair of namespaces, so if you already have custom namespaces then you will need to pick an alternative pair of IDs to ensure you avoid a conflict.  You should add the extra IDs to your existing <code>$wgExtraNamespaces</code> declaration, using the next two available numbers (or, if you want, you can leave a gap if you plan to add additional namespaces in the future) and then make sure that <code>$wgWikiDBNamespaces</code> matches the even-numbered ID.  If you just use the code you posted above, you will lose your custom namespaces as it will overwrite what you have already defined.
::: I'll look at updating the install instructions if this is unclear - or you can update them yourself, if you like... :-)
::: I will also continue looking into the issue you raised.  Even if the configuration ends up being the cause, then I still want to make sure it handles it more gracefully. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 17:36, 7 May 2018 (BST)

:::: Hi JSmith,  I have found and fixed the first of these errors and this fix will be in the next version of WikiDB.
:::: As far as I can see, this error is specific to MediaWiki 1.27 and does not occur in any other version, therefore upgrading MediaWiki should fix the error.
:::: However, if that is not possible at the moment, and if you are unable to wait until the next release of WikiDB (which is in progress, but not quite there yet), you might want to apply the fix manually.
:::: This can be done by changing line 376 of <code>includes/Utility.php</code> from this:
::::: <code>		if (class_exists("MediaWiki\\MediaWikiServices")) {</code>
:::: to this:
::::: <code>		if (method_exists("MediaWiki\\MediaWikiServices", "getLinkRenderer")) {</code>
:::: I will continue investigating the second issue you report, though it may just be a knock-on effect of the first.  If you ''do'' try the manual solution, please let me know if this also fixes the second error.
:::: All the best,
:::: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 21:13, 7 May 2018 (BST)

:::: Further to my last update, I have found and fixed the cause of the second error you reported, and this fix will also be in the next version of WikiDB.  They were unrelated.
:::: The manual fix is a little more involved as a couple of lines need changing.  If you need it, let me know and I'll post it here.  However, the cause of the issue is that there is a field whose type is set to 'link' but which contains a value that is not a valid MediaWiki page title (blank values are also allowed).  For example <code>::</code> or <code>Project:</code> or text which contains invalid UTF-8.  Therefore, the simplest method of fixing it might be to fix the invalid entry.  If you are able to pinpoint the value in question, please let me know - particularly if it doesn't appear to be invalid, as I would never be so bold as to rule-out a parsing error! :-)
:::: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 22:16, 7 May 2018 (BST)

:::::Thank you very much for your help! I believe an initial issue was a set of links that ran like this: <code>[[9]] | [[10]] | [[11]] | [[12]]</code> which MediaWiki interpreted as (I think) a piped link. My only reason for thinking this is that some rendered as links while others had one or two brackets surrounding. Probably a typo.

:::::I updated class_exists... to method_exists... in <code>includes/Utility.php</code>, but it was line 376 on mine? I may do a clean install of the extension later this evening, as I am now receiving an error <code>Fatal error: Call to a member function getNamespace() on null in .../extensions/WikiDB/includes/BuiltInTypes.php on line 321</code>, which only seems to be called with an "older version," leading me to believe the new method_exists code is being bypassed.

:::::I am happy to edit the lines if you can provide them, if only to check my use case. I've been putting off updating the wiki, but now might be the time to do it.

:::::I moved the namespace IDs to the 400s, but the error above has prevented me from checking whether that worked.
:::::--[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 01:43, 8 May 2018 (BST)

:::::: You're right - it was line 376.  My local version has some other updates that means the line numbering had changed.  I have updated the above text with the correct line number, to avoid confusion in case anyone else needs to apply the same solution.
:::::: The fix to the BuiltInTypes issues is as follows (it's not as involved as I thought, as I've realised that most of the edits were comment changes, which I've not included here.
:::::: On line 321, change this:
::::::: <code>				if (in_array($Link['title']->getNamespace(),</code>
:::::: to this:
::::::: <code>				if ($Link['title'] !== null && in_array($Link['title']->getNamespace(),</code>
:::::: And before line 342, which contains this:
::::::: <code>				return $Link['title']->getPrefixedDBkey();</code>
:::::: add the following line:
::::::: <code>				if ($Link['title'] === null) return "";</code>
:::::: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 12:56, 8 May 2018 (BST)

:::::::That worked! Running into an additional error on edit: <code>Fatal error: Call to undefined method User::getSkin() in .../extensions/WikiDB/includes/Utility.php on line 388</code>
:::::::--[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 13:17, 8 May 2018 (BST)

:::::::: I've updated to 1.3 and all is working as expected, except for one issue noted above. Thanks for all your support! This extension is a game-changer.
::::::::--[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 02:51, 14 May 2018 (BST)

::::::::: By "except for one issue noted above", do you mean the <code>getSkin()</code> error?  Are you getting this on 1.30?  I have done some digging and can see that this error would occur on 1.27 (which will be fixed in the next release) but it doesn't appear to affect any other version. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 22:49, 15 June 2018 (BST)

:::::::::: Sorry this was unclear. The 500 error is solved by updating to 1.30, so this issue is resolved for me. 

:::::::::: The noted issue: I was attempting to create multiple links in a field of type link. Typing <code><pre>[[09]], [[10]], [[11]]</pre></code> yields 09]], [[10]], [[11. It probably isn't a best practice, but was needed for my case. I guess the parser is wrapping the content with double square brackets? My solution is to remove the outer brackets from the entry. Not a big deal, and maybe more trouble to solve than it is worth.

:::::::::: --[[User:JSmith|JSmith]] ([[User talk:JSmith|talk]]) 23:11, 15 June 2018 (BST)

::::::::::: The 'multiple links' issue was logged as a separate issue, so I'll deal with it there.  All other issues raised in this thread have been resolved in the v5.0.0 release of WikiDB.  If you encounter any further issues, please start a new thread to discuss them.  Thank you for helping me improve WikiDB.  --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 21:01, 30 March 2019 (GMT)

=== Trouble running SetupTables.exe ===

Hello!

I'm attempting to run the maintenance script SetupTables.php through Terminal with command line access. I'm all logged in and such, but I get this error:

<pre>
<br />
<b>Parse error</b>:  syntax error, unexpected '[' in <b>/clickandbuilds/MediaWiki/thornswiki/maintenance/commandLine.inc</b> on line <b>30</b><br />
</pre>

When I look in my MediaWiki maintenance/commandLine.inc file, line 30 looks fine to me?

Here are lines 26-34 for reference:

<pre>
// phpcs:ignore MediaWiki.NamingConventions.ValidGlobalName.wgPrefix
global $optionsWithArgs, $optionsWithoutArgs;

if ( !isset( $optionsWithArgs ) ) {
        $optionsWithArgs = [];
}
if ( !isset( $optionsWithoutArgs ) ) {
        $optionsWithoutArgs = [];
}
</pre>

So, I'm not sure what the error is? I'm running MediaWiki 1.31.1 and php 7.2.14. I followed all of the other install directions and set up two different table namespaces in my LocalSettings.php.

-- [[User:Niftysmith|Niftysmith]]

: Hi Niftysmith.  Thanks for your bug report.
: I will very shortly be releasing a new version of WikiDB, which has had a number of significant changes, particularly with regards updating the code for compatibility with more recent MediaWiki versions.  It has not been tested against either MW 1.31 nor PHP 7.2, so I don't know if it will fix your problem, but there is a reasonable chance that it will as so much else has changed.  If the problem persists on the new version then I will happily look into it and would hope to have an updated release shortly afterwards.
: Thank you for your patience.
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 23:00, 11 February 2019 (GMT)


---
For the record, I am apparently currently running PHP 4.4.9 for no reason. My hosting service says I'm updated to 7.2 but when I run a command line version check, it says 4.4.9. Once I get this resolved with my host, I will keep you posted on my errors! Is there an ETA for a new version of WikiDB?

[[User:Niftysmith|Niftysmith]]

: Well, that's definitely going to break things!!  You'll need PHP 7.0 or above to run that version of MediaWiki.
: That said, I know there were some issues with WikiDB in MW 1.30 that I have fixed but not yet released, so you will need the updated version of WikiDB in any case.  Whether that is sufficient to run on 1.31, we will have to see.
: I hope to release this week, if I have time...
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 18:42, 12 February 2019 (GMT)

---
Alright, so this is fun. I am, according to MediaWiki, running 7.0. I'm on a shared hosting service, so while I have SSH access via Terminal, my user profile is running 4.9.4 on Shell. I can run scripts via php7.1 as the command instead of php (i.e. php7.1 SetupTables.php), but I get a "This command must be run from command line" error. Do you know what that means?

Anyway, please keep me posted on an update. I really would like to use your easy-to-understand database management on my story's lore wiki. We are an ever-growing community. Cargo is my other option, but, to be honest, your WikiDB looks so much more natural and understandable. Thank you.

[[User: Niftysmith|Niftysmith]]

: Hi Niftysmith,
: That error message is a MediaWiki error message, and nothing to do with WikiDB.  It is there to prevent command-line scripts being run from the web (just in case) but it looks like it's misfiring in your case.  I think the most likely cause is that the <code>php7.1</code> command you are running is the CGI (web) version, rather than the CLI (command-line) version.  You should be able to see this by running <code>php7.1 --version</code> which will indicate which of these is the case.
: If that is what is happening, you should inform your hosts that this has been set up incorrectly and ask them to either fix it or - if they have made both available for some reason - to let you know the correct command for the CLI version of PHP.
: If they can't/won't help you, then you might get away with disabling the check in <code>maintenance/commandLine.inc</code> by commenting-out the following lines - however I have no idea if there will be other side-effects of skipping this check:
<php>
if ( isset( $_SERVER ) && array_key_exists( 'REQUEST_METHOD', $_SERVER ) ) {
	print "This script must be run from the command line\n";
	exit();
}
</php>
: If I have diagnosed the problem correctly, you may also want to raise a ticket on the MediaWiki issue tracker to see if they can adapt the check so that it is possible to run it using the CGI command-line executable, as I don't see why it shouldn't be.
: Good luck! Let me know how you get on.
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 22:04, 13 February 2019 (GMT)

:: I'm marking this as resolved.  I believe the issues you were experiencing are related to the incorrect PHP version being run, and will be resolved by running the correct version (PHP >= 7.0, CLI rather than CGI).  In addition, WikiDB 5.0.0 has had a large number of fixes relating to both MediaWiki and PHP compatibility, so any compatibility issues that might have affected your installation (MediaWiki 1.31.1 and PHP 7.2.14) should hopefully now be resolved.
:: If you are still encountering any issues having upgraded WikiDB and ensured you are running the correct PHP version, then please raise them in a new thread and I will be happy to investigate.
:: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 21:06, 30 March 2019 (GMT)

=== Warning and no table creation ===
<small>(Moved from [[Talk:WikiDB/Configuration settings#Warning and no table creation]])</small>

Hi! The following code is bogus :
<php>$wgWikiDBNamespaces = 100;</php>

$wgWikiDBNamespaces is expected to be an array (in classWikiDB_Table.php line 232),
so this code generate a warning and no table creation.

the good way to create the namespace in LocalSettings.php is:
<php>
require_once "$IP/extensions/WikiDB/WikiDB.php";
define('NS_TABLE', 100);
define('NS_TABLE_TALK', 101);
$wgExtraNamespaces[NS_TABLE] = "Table";
$wgExtraNamespaces[NS_TABLE_TALK] = "Table_Talk";
$wgWikiDBNamespaces = array(NS_TABLE => true);
</php>

----

: Hi - thanks for the bug report.
: The extension has code to handle this, in WikiDB.php:
<php>

// If $wgWikiDBNamespaces has not been set, or is otherwise blank, initialise it to
// an empty array.
	if (IsBlank(@$wgWikiDBNamespaces)) {
		$wgWikiDBNamespaces = array();
	}
// Otherwise, if it has been set, make sure it's a valid array.
// In this case the value is treated as the namespace ID of a single table
// namespace, which we convert to the standard array representation used by this
// variable.
	elseif (!is_array($wgWikiDBNamespaces)) {
		$wgWikiDBNamespaces = array($wgWikiDBNamespaces => true);
	}
</php>
: However, this only works if you define the properties before you include the extension.  If you moved your <code>require_once</code> line so that it comes after <code>$wgWikiDBNamespaces</code> is defined, then things would work as intended.
: This is a bug - it is normal to include the extension before configuring it, and so we should definitely support this.  I will include a fix for this in the next release.
: Kind regards,
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 22:10, 24 November 2019 (GMT)

:: This issue was fixed in [[WikiDB/CHANGELOG#5.0.3|WikiDB 5.0.3]]. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 00:43, 8 April 2021 (BST)


=== Class 'Revision' not found in Constants.php ===
Just installed WikiDB 5.1.0 on MediaWiki 1.37.1, but get the following error:
 PHP Fatal error: Uncaught Error: Class 'Revision' not found in /srv/mediawiki/extensions/WikiDB/includes/Constants.php:79

Which comes from here:
 if (class_exists("RevisionRecord"))
     define("WIKIDB_RawRevisionText", RevisionRecord::RAW);
 else
     define("WIKIDB_RawRevisionText", Revision::RAW);

Commenting out the else part apparently solves the issue, but I don't know if that affects to further functionalities.

Thanks in advance.

--[[User:Fortega|Fortega]] ([[User talk:Fortega|talk]]) 21:28, 10 March 2022 (GMT)

: Thanks for your great bug report.  I have now fixed this, in WikiDB v5.1.1.  Kind regards --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 18:50, 11 March 2022 (GMT)

=== SetupTables.php -> PHP Fatal error: Declaration must be compatible with Maintenance ===

Hi and thank you for the super nice looking extension, I would love to try it, but cant get it to run. But the following error that occours is:

 $ php SetupTables.php  [12-Oct-2023 02:21:34 Europe/Berlin] PHP Fatal error:  Declaration of WikiDB_Maintenance::finalSetup() must be compatible with Maintenance::finalSetup(?MediaWiki\Settings\SettingsBuilder $settingsBuilder = null) in /var/www/virtual/boogie/html/mw/extensions/WikiDB/maintenance/install_functions.inc on line 38

<pre>
Software 	Version
MediaWiki 	1.39.4
PHP 	    8.0.30 (fpm-fcgi)
MariaDB 	10.6.15-MariaDB
ICU 	    72.1
Pygments 	2.11.2

No installed extensions besides VisualEditor.

My LocalSettings.php:

require_once("extensions/WikiDB/WikiDB.php"); 
$wgExtraNamespaces = array(         
   100 => "WikiDBTable",
   101 => "WikiDBTable_Talk", 
); 
$wgWikiDBNamespaces = 100;

</pre>

-- tranquillo 12.Okt 2023

: Hi tranquillo - thank you for the bug report.
: I am in the process of updating WikiDB to support PHP 8, but this work is not complete yet, and is the reason for the above error.  I will see if I can expedite a fix for this specific issue and do a basic smoke test that WikiDB does not crash the wiki when it's run on PHP 8, but it will take a bit longer before I can definitively declare full support.
: I'll try and get a first-draft PHP8 version out in the next week or so, and would then welcome reports of any further issues you encounter, if you're happy to do that?
: Kind regards,
: --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 10:28, 12 October 2023 (BST)
:: It took a bit longer than I had hoped, but WikiDB 5.1.3 has now been release, which addresses this issue.  Thanks for taking the time to report it. --[[User:HappyDog|HappyDog]] ([[User talk:HappyDog|talk]]) 12:40, 27 January 2024 (GMT)
@@ Line 280: / Line 280: @@
 : Thanks for reporting the issue (I wouldn't have spotted and fixed it without you) - sorry about the slow response! :-)
 : --[[User:HappyDog|HappyDog]] 12:43, 13 September 2010 (BST)
-=== Field too long ===
-<small>(Moved from [[Talk:WikiDB/Tables#Field too long]])</small>
-wikidb_fielddata
-- Specified key was too long. Max key length is 500 :(
-: I'm guessing that this error is occuring when you are creating the indexes in your local copy of the wikidb_fielddata table.  This may be because the version of MySQL you are using is incompatible with my DB - I haven't tested on anything except 3.23.58.  I'm guessing the binary fields require 2 bytes per character, and with a 255 character limit, that means a key of 510 bytes.  Perhaps this is a config setting.  Please let me know if you find a good fix for this, or if I am off the mark with my diagnosis, and thanks for taking the trouble to write. --[[User:HappyDog|HappyDog]] 23:54, 5 January 2007 (GMT)
-:: Just to update this, as far as I'm aware this issue is now fixed.  All the current indexes seem to fit within the 1000 byte limit of MySQL 4/5, even if multi-byte character sets are being used (e.g. UTF-8).  They may exceed the 500 byte limit of MySQL 3 if a multi-byte character set is being used (though it should be fine with single-byte charsets) - however MySQL 3 is very old now so I'm not going to worry about supporting it unless there are actual users who are reporting problems and are unable to upgrade.
-:: If anyone does encounter this problem, then please let me know the version of MySQL you are using, plus the full text of the error message you receive, and I will see what I can do.  Otherwise I will assume that nothing further needs to be done in relation to this issue. --[[User:HappyDog|HappyDog]] 20:54, 13 September 2010 (BST)
 === Can't apply templates at all on any page===
@@ Line 540: / Line 531: @@
 :: 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 - [[User:HappyDog|HappyDog]] 10:14, 20 April 2013 (UTC)
-=== SQL error when creating tables ===
-<small>(Moved from [[Talk:WikiDB/Tables#SQL error when creating tables]])</small>
-I was having all sorts of trouble installing this extension... even on a fresh MW install it failed
-Then I found this page and tried manually creating the tables... phpMyAdmin advised an error in SQL syntax
-turns out that for MySQL 5.5 you need to change ''TYPE = MyISAM;'' to '''ENGINE = MyISAM;''' then the create queries work
-: Hi there,
-: Sorry you had trouble installing.  The MediaWiki engine automatically takes care of the engine declaration (it inserts either TYPE or ENGINE depending on your version of MySQL) so this is unlikely to have been the original cause of your problems.  I would be very interested to hear about your difficulties so I can either improve the documentation or fix the extension, as appropriate.
-: In the meantime, I have fixed this page (by updating my [[Debugging tools|WikiDebug extension]], which is used to generate the table schema) so that it now outputs ENGINE instead of TYPE.  Until 5.5 was released, TYPE was more compatible as all MySQL versions supported it.  However, as you say, since 5.5 this is no longer the case, and for all versions of MySQL that MW still supports, ENGINE will work whereas TYPE may not.
-: Thanks for getting in touch - I hope I can help further with your installation issues.
-: --[[User:HappyDog|HappyDog]] 13:16, 31 December 2013 (UTC)
 === Nesting repeat statement via templates ===