Extension:External Data/Common problems

• If the call to #get_web_data or #for_external_table isn't returning any data, and the page being accessed is large, it could be because the call to retrieve is getting timed out. You should set the $wgHTTPTimeout flag in your LocalSettings.php file (which represents a number of seconds) to some number greater than 25, its default value. You could call, for instance:

$wgHTTPTimeout = 60;

• If the data being accessed has changed, but the wiki page accessing it still shows the old data, it is because that page is being cached by MediaWiki. There are several solutions to this: if you are an administrator, you can hit the "refresh" tab above the page, which will purge the cache. You can also easily disable caching for the entire wiki; see here for how. Finally, if you wait long enough (typically no more than 24 hours), the page will get refreshed on its own and display the new data.

• If you host a private wiki locally but use a dynamic IP service to access it, your wiki will connect to itself through your public IP and not through localhost or 127.0.0.1 (or an IPv6 equivalent). In such a case, your wiki is not allowed to query itself so the examples given here will work when data are hosted on a different server but not if they are hosted on your wiki. A workaround is to use the extension Extension:NetworkAuth which allows you to automatically authenticate your router/box/modem to access your wiki. Note: the security of this approach is not guaranteed.

• If the extension is not correctly handling non-ASCII characters, the problem might be that your PHP instance lacks the mbstring extension - make sure that it is installed.

• If you are running External Data alongside version 4.2 or higher of Semantic MediaWiki, you might see the following message on any page that accesses web data via an External Data function:

Fatal error: Declaration of MWCallbackStream::write($string) must be compatible with Psr\Http\Message\StreamInterface::write(string $string): int in .../includes/http/MWCallbackStream.php on line 49

This is due to Semantic MediaWiki installing a too-high version of some library, breaking compatibility with MediaWiki. This problem is discussed at length here, with some suggested workarounds; although if none of those work for you, one option is to simply add the string : int to the relevant line in the file MWCallbackStream.php, as suggested by the error message. It's a hack, but it works.

• To query data from another wiki that uses Semantic MediaWiki, it is recommended to use the Special:Ask page, rather than one of SMW's API actions, to construct the URL that will be passed in to #get_web_data, since the API will not output data in a syntax that External Data can use. To construct the URL, go to Special:Ask, create the desired query, then copy the URL from the "Download queried results in CSV format" link.
  • If such queries of Semantic MediaWiki data are adapted for use inside templates by adding parameters, it is required to escape special characters that are contained in the parameter. The required encoding method depends on the URL format that Special:Ask provides to you; there are at least two possible format, at least if using short urls. The recommendations made in this paragraph are the results of testing different encodings with two different URL formats; there may be different formats that Special:Ask provides under some circumstances and if further formats exist they weren't considered here. The appropriate encoding method for special characters is always hex ASCII encoding. In most cases, both URL formats require that each encoded character is preceded by a single hyphen-minus -. As an exception to this, one of the URL formats requires equal signs = to be non-encoded or percent-encoded. Since the other URL format can handle equal signs with any kind of encoding, you're best off not encoding or percent-encoding equal signs. Character encoding can be achieved with any method, including the {{#replace:}} StringFunction (crude but it works) or a pertinent Lua module. The {{urlencode:}} magic word does not work since it percent-encodes all special characters, which isn't appropriate.

Table: Character encoding handling of two different query URLs provided by Special:Ask

Special character to be encoded	Not encoded		Percent-encoded		Hyphen-encoded
	Format A	Format B	Format A	Format B	Format A	Format B
Any special character in property name or value	Error	Fail silently	Error	Fail silently	Ok	Ok
SMW tag [	Error	Error	Error	Ok	Ok	Ok
SMW tag ]	Error	Ok	Error	Ok	Ok	Ok
SMW tag ?	Error	Ok	Error	Ok	Ok	Ok
SMW tag =	Ok	Ok	Ok	Ok	Error for some parameters	Ok
SMW tag :	Ok	Ok	Ok	Ok	Ok	Ok