This extension used to define a specific tag for only a short time. That tag, whatever it was called, has been removed. Now, any tag which may be defined by this extension comes from the tag emulation mode.

If Composer for this extension is sorted out, perhaps something can be done about T259743, so that manual composer require mongodb/mongodb is no longer necessary to access MongoDB.

External Data is not published at Packagist anyway.

In T302049#7720871, @Reedy wrote:

What version of MobileFrontend are you using?

I thought I was using REL1_35. Deleted the extension folder and cloned it again; the error disappeared. It seems I had messed it up with the IDE.

In T282499#7163196, @RobinHood70 wrote:

what about implementing the legacy parser as a content model? That would allow wikis to use one or the other on a per-namespace and even per-page basis, as needed, potentially even mixing and matching if transclusions can be handled correctly between the two. The legacy parser could be defined as always being linear, while Parsoid would not.

Closing as inactive and possibly already resolved.

I usually wait some time for errors to be found.

@Ofbeaton, could you try to update the extension and repeat that query, to see whether there is still an error? Database queries have been modified significantly since 2019.

The special page GetData works, I have checked. Closing.

Are you still having this problem?

In T289616#7464048, @Yaron_Koren wrote:

Okay, let me make sure I understand this, because I just want to make sure that there's no security leak here.

In T289616#7464048, @Yaron_Koren wrote:

Is that all correct?

In T289616#7463904, @Yaron_Koren wrote:

I see now that that the variables $edgDirectoryPath and $edgFilePath have both been replaced with the parameter 'path' - given that, how does the code know whether this is a directory or a file?

No objections.

Mr Koren?

In T289616#7457539, @Yaron_Koren wrote:

• I think the "_prefix" value in extension.json doesn't actually need to be set, because I think it defaults to "wgExternalData".

In T289616#7456513, @Yaron_Koren wrote:

Does it work?

In T289616#7455845, @Yaron_Koren wrote:

Sorry for the delay. What is #get_external_data? I hadn't noticed that addition before.

Mr Koren?

In T289616#7453334, @Yaron_Koren wrote:

Okay - sorry that I wasn't clear about it: I meant that I thought it made sense to have these separate variables instead of (what was then known as) $edgSources. I still think there's an argument to have these separate variables - although I admit there are also valid reasons to have a single variable like $wgExternalDataSources. But I never thought it made sense to have both; sorry that it sounded like I did.

In T289616#7452020, @Yaron_Koren wrote:

Sorry for the delay. Overall this is looking good. I'm wondering about those other new global variables, $wgExternalDataDatabases, $wgExternalDataSites, $wgExternalDataFiles, $wgExternalDataDirectories and $wgExternalDataPrograms - I didn't notice those before. What are they there for?

I have uploaded a new patchset (don't know why the robot didn't add a link to it again).

I have uploaded a new patchset (don't know why the robot didn't add a link to it again).

In T289616#7446816, @Yaron_Koren wrote:

That's interesting. How would "allow external data from" work on a per-host level?

In T289616#7446814, @Yaron_Koren wrote:

Here's another question: External Data's use of the $edg prefix for its variables comes from the days before it was standardized to use $wgExtensionName... for variables. Now that the variables are getting changed completely, maybe this is a good opportunity to change $edgSources to $wgExternalDataSources? It would require changing around extension.json, but I think it is technically possible. Maybe it doesn't matter, though. What do you think?

I think it can be done, more or less. There will be some difficulty with the few extension settings that stay as they are: $edgAllowExternalDataFrom, $edgExternalValueVerbose, $edgCacheTable, because the backward compatibility has to be kept.

But could you explain the current proposed structure - meaning the set of allowed parameters?

In T289616#7445409, @Yaron_Koren wrote:

Alright. If the real goal with the $edgSources settings for #get_web_data and #get_soap_data is to avoid overloading the outside service, maybe a better ID to use is the domain of the website rather than the whole URL, e.g. 'worlddata.com' rather than 'http://worlddata.com/api/1234"?

This is possible. Settings for the URL are read first, if none found, then for the host (as you suggest), then for the second level domain of the host, then for the datasource '*'.

Sorry for delaying the previous answer. I forgot to press [Submit].

In T289616#7438993, @Yaron_Koren wrote:

I'm still not sure about this, but I'm glad we are discussing it further. First of all, I don't think something like $edgSources['throttle key'] is a good idea, because it looks like 'throttle key' is a source ID. (And what if there really is a source ID named 'throttle key'? There probably won't be, but still.) $edgSources['*']['throttle key'] would be better. ('*' makes more sense than 0, I think.)

Change https://gerrit.wikimedia.org/r/c/mediawiki/extensions/ExternalData/+/731789. For some reason, not added by the robot.

In T289616#7437887, @Yaron_Koren wrote:

They could overload the wiki by pointing to some URL

In T289616#7437061, @Yaron_Koren wrote:

Would this new variable be used for #get_web_data as well?

Yes.

In T289616#7434229, @Yaron_Koren wrote:

I do like minimizing the number of variables, but this may be going too far. I still think it makes sense to have a separate variable for each source type (although I guess two for local files, one for files and one for directories).

Mapping between old global variables and new indices for $edgSources['data source name'], for preliminary approval:

'StringReplacements' => 'replacements', 'TryEncodings' => 'encodings', 'AllowSSL' => 'allow ssl',
'HTTPOptions' => 'options',
'DBServer' => 'server', 'DBServerType' => 'type', 'DBName' => 'name',
'DBUser' => 'user', 'DBPass' => 'password',
'DBDirectory' => 'directory', 'DBFlags' => 'flags', 'DBTablePrefix' => 'prefix',
'DBPrepared' => 'prepared', 'DBTypes' => 'types',
'DirectoryPath' => 'path', 'FilePath' => 'path',
'LDAPServer' => 'server', 'LDAPUser' => 'user', 'LDAPPass' => 'password', 'LDAPBaseDN' => 'base dn',
'ExeCommand' => 'command', 'ExeParams' => 'params', 'ExeParamFilters' => 'filters', 'ExeInput' => 'input',
'ExeTempFile' => 'temp', 'ExeLimits' => 'limit', 'ExeEnvironment' => 'env',
'ExeIgnoreWarnings' => 'ignore warnings', 'ExePreprocess' => 'preprocess', 'ExePostprocess' => 'postprocess',
'ExeCacheSeconds' => 'cache seconds', 'ExeUseStaleCache' => 'use stale cache',
'ExeName' => 'program name', 'ExeUrl' => 'program url',
'ExeVersion' => 'version', 'ExeVersionCommand' => 'version command',
'ExeThrottleKey' => 'throttle key', 'ExeThrottleInterval' => 'throttle seconds', 'ExeTags' => 'tag',
'AlwaysAllowStaleCache' => 'use stale cache', 'CacheExpireTime' => 'cache seconds',
'ThrottleKey' => 'throttle key', 'ThrottleInterval' => 'throttle seconds'

Then there is another question: now POST requests are tried only once, while GET requests can be re-tried several times. The reason was similar: POST requests are not necesserily idempotent. Perhas, this should be unified, too?

In T293231#7426000, @Yaron_Koren wrote:

That would be nice... but so far, my policy has been to have my extensions supporting MW versions going back at least two years, or the current LTS version, whichever is older. MW 1.35 came out in September 2020; could this change wait another year?

Then it means MW 1.34 and PHP 7.2, which is nearly the same. But yes, it can wait, and has to wait due to limited resources.
But the task ought to be set.

In T293248#7425990, @Yaron_Koren wrote:

What is the argument against caching data from a POST request?

At first, I presumed that a POST request is supposed to change the state of the server, so withholding an HTTP request by caching will not be correct.

In T293231#7424564, @Yaron_Koren wrote:

Would it help the code in some way?

ALso, what is the remote repository that you use?