Extension talk:External Data/Archive 2017 to 2018

strange error message
Notice: Use of undefined constant CURLOPT_SSL_VERIFYPEER - assumed 'CURLOPT_SSL_VERIFYPEER' in /var/lib/mediawiki/extensions/ExternalData/ED_Utils.php on line 400

I have allowed the ip adres of the csv file in LocalSettings.php

using this code

It seems to happen when I try to put three or more imports in one page. It blanks the article completely as well. Anyone have any ideas?


 * Are you using the latest version (1.2.3)? I thought that problem was fixed in 1.2.3. Yaron Koren 14:35, 23 March 2011 (UTC)

Not Working
any idea why? it's installed in Special:Version, but it doesn't show anything (xml works fine): http://www.komentarz.org/pl/test


 * You also need to set the "data" parameter. Yaron Koren 22:36, 2 February 2011 (UTC)

so if this is my xml feed, what data should i type? name of the xml node? http://www.komentarz.org/smw/api.php?action=query&list=threads&format=xml


 * I don't want to sound rude, but - have you read the documentation? Yaron Koren 00:59, 4 February 2011 (UTC)

sure, i found this fragment but i think a clear example of getting rss xml feed in documentation would be helpful. i still can't get it to work.your extension would be a perfect rss reader (other extension doesn't work or are unstable): For data from XML sources, the variable names are determined by both tag and attribute names. For example, given the following XML text:  red the variable type would have the value Apple, and the variable color would have the value red. Similarly, the following XML text would be interpreted as a table of values defining two variables named type and color:  red  brown


 * Well, in any case, a more reasonable value for "data=" would be "data=thread=thread,subject=subject". Yaron Koren 23:37, 4 February 2011 (UTC)

Sort results
Any way to sort results returned from #get_db_data?


 * I don't think so, but it might definitely be worthwhile to have a way for users to add an "ORDER BY" command to the SELECT call... Yaron Koren 01:00, 4 February 2011 (UTC)


 * It certainly would! Could you provide that? Matheus Garcia 17:53, 15 February 2011 (UTC)

SQLSRV vs MSSQL
I am not sure how to ask this correctly. I have upgraded to PHP 5.3.5 which no longer supports mssql (from what I can tell). So I have downloaded the Microsoft support for SQL Server and PHP and added the necessary information to php.ini.

Does MediaWiki support the interface to SQL Server through the new library sqlsrv. The mediawiki includes/db directory has the DatabaseMssql.php file, but the interface is mssql_function calls and not sqlsrv_function calls.

So am I out of luck using PHP 5.3.5 and MS SQL Server?

Wolcott 20:32, 18 February 2011 (UTC)


 * Hi, I really don't know anything about MediaWiki's suppport for SQLServer, but it sounds like you might be out of luck - at least until MediaWiki's support gets improved. You could always submit a bug report for it... Yaron Koren 22:27, 18 February 2011 (UTC)


 * Well a little further research this morning and I found a Bugzilla Report 22093 which discussed the new interface to Microsoft SQL Server. .  With my limited ability I was able to find the new code in the 1.17 trunk (includes/db/DatabaseMssql.php.  It is the same file name as before, but different guts.  I have not been able to find a 1.16 version and I can't get the 1.17 version to work under 1.16 because of some interface changes.  I have emailed Ryan Biesemeyer for any further suggestions with 1.16... Wolcott 15:25, 21 February 2011 (UTC)


 * Ryan Biesemeyer responded that MediaWiki team still has some concerns with the compatibility. He will attempt to see what it would take to back port to 1.16, but no promises.  I have backport a minimalistic number of functions to make it work with my requirements ... Wolcott 17:19, 22 February 2011 (UTC)

get_db_data - Data parsing
I wasn't thinking how you parsed the data section before trying to attempt and format a date via the database. Issuing the query below via SQL Server produces Feb 22, 2011 instead of 2011-02-17T12:04:00Z

SELECT Title_Txt, CONVERT(VARCHAR(12), Documentation_Rev_Dt, 107) AS Rev_Dt FROM Tool WHERE Acronym_Txt ='ITEM'

But obviously trying to perform it via get_db_data the parser messes things up because it uses the comma to parse on KeyValue mappings.

Any thought to allow us to define the seperator? Would it be better to define it as a localsettings token and thus make it global or add it to #get_db_data: as seperator so that it is unique to that query. Wolcott 18:49, 22 February 2011 (UTC)


 * Ah - good point. Let me look into it. Maybe with some simple parenthesis-matching, it'll still be possible to use commas. Yaron Koren 21:01, 22 February 2011 (UTC)


 * Yaron not a big hurry. I am able to use the #time parser to format the date the way I want to present it. Wolcott 01:41, 27 February 2011 (UTC)


 * I would be interested in this solution, too. Volker

Evaluating inside #for_external_table
Can I evaluate a field within the #for_external_table parser?

I was trying to retrieve all the study names and descriptions based on my page name. That works just fine. I then was going to iterate over the data (multiple rows) and display the Study Name and if there is a description display it also.

Studies (U)
}}

How can I test to see if the string is not empty inside the #for_external_table parser function... Wolcott 20:38, 2 March 2011 (UTC)


 * I don't know if this would work - I've never tried it. Yaron Koren 22:15, 2 March 2011 (UTC)


 * It doesn't. That is why I was asking.  I was looking at the function in the code and trying to understand how you processed the information... Wolcott  00:19, 3 March 2011 (UTC)

Clearing Out Data
I built a template that calls the database based on particular ID. A page calls the template 5 times passing in different ID's. The problem was the data does not clear itself out between calls and the template was not working correctly. I added a new parser funtion #clear_external_data: that resets the $edgValues to an empty array;

Thus at the end of the template I call #clear_external_data: to reset the data since I am done with it. Everything works now. Is this something that you can add in the next version? Wolcott 10:25, 3 March 2011 (UTC)


 * Oh, interesting - that makes sense. Sure, can you send me the code, to yaron57@gmail.com? Yaron Koren 15:06, 3 March 2011 (UTC)

Parser function evaluations inside #for_external_table
Yaron,

I asked the question above, but have since dug a little deeper and wanted to go over it one more time to see if you think there is any way to get this to work or to explain MediaWiki process of evaluating pages.

Below is a simplified version of the page. We are retrieving multiple rows out of the database and attempting to interpret the data to build a table.

The problem above is the the third column (Switch parser function) is not being evaluated within the #for_external_table. It is being evaluated before and the result is being passed into your parser function. I printed the value of the $expression variable and got the following.

2011-03-16 13:22:26 wikidac16-wac_: Expression - UNIQ760a39896f6503dc-nowiki-00000000-QINU

As you can see 'N' is being passed into your parser function and not the actual code to be executed. Obviously when the switch function is evaluated outside your funtion is not set yet so 'N' is the correct value.

Is there anyway to delay the switch function from being evaluated until we are inside your code?

How does MediaWiki process pages?

Wolcott 13:51, 16 March 2011 (UTC)


 * After writing this I began to search MediaWiki for some possible solutions and found an extension Control Struction Functions. It no longer works after 1.12, but it mentions the wiki markup preprocessor and how code is evaluated.  More research needed ... Wolcott 14:24, 16 March 2011 (UTC)

MediaWiki 1.17 mssql support
If you're using ExternalData to fetch data from a Microsoft SQL Server using the mssql php module, you'll have two choice to make it work in MediaWiki 1.17+.


 * 1) Install Microsoft Drivers for PHP for SQL Server (only work in Windows).
 * 2) Install Extension:MSSQLBackCompat (will work the same way mediawiki 1.16 worked except the DBServerType must be "mssqlold").

--Solitarius 00:26, 2 April 2011 (UTC)


 * Thanks for finding this out, and for adding it to the documentation. Yaron Koren 18:22, 3 April 2011 (UTC)

#for_external_table and Creates pages with form:: issue
Not sure of an easy way to explain this, but here it goes.

I use External Data to retrieve a list of tools out of the external database and display them on a wiki page.

That works great (see below) [left upper table "AB Tools"]



But then we added a new tool in the external database and a red link showed up. So I decided to have a page automatically created if it was a red link by adding the following code.

First when I retrieve the data I build the list and then loop through it again adding the tools to a property.

Know the Property "MS Tools" contains all the tools. I then edit the property page for "MS Tools" adding:

Has Type::Page Creates pages with form::MS Registry Item

The MS Registry Form just calls a generic template MS Registry Item that uses the pagename to retrieve detailed information about the tool and display it. So know when I add a new tool in the external database I see a red link (in the background a page is automatically being created, hopefully in quick fashion), so when I click on the red link the page exists. Yea, not just yet.

When there is a red link in the "AB Tools" list additional garabge characters are also show...



Any thoughts?


 * Hi - any time you see printouts containing UNIQ/QINU, it means that something has gone wrong with the parser. I'm far from an expert on the MediaWiki parser, so I don't know what specifically is going wrong, but - why not have a single #for_external_table call, that displays the values and sets the property at the same time? That seems like it might have a better chance of working. Yaron Koren 22:08, 5 April 2011 (UTC)


 * Yea I tried that also. Same result with UNIQ and an extra line feed is embedded. I will perform some debugs an alternates tomorrow at the office.  I have had issues with the #for_external_table parser were I can't do extra calls from within the parse (see above).

So when you say "something has gone wrong with the parser" should I debug within the #for_external_table: function? If you look at the discussion "Parser function evaluations inside #for_external_table" above I had a problem with #switch inside the #for_external_table.

Wolcott 00:17, 6 April 2011 (UTC)


 * I really don't know how to debug it. What I meant, though, was just calling:


 * Did you try that? Yaron Koren 00:24, 6 April 2011 (UTC)
 * Nope I will try that in the morning? Wolcott 01:31, 6 April 2011 (UTC)