Extension talk:Arrays

Old messages until March 2011 are archived.

Previous page history was archived for backup purposes at Extension talk:Arrays/LQT Archive 1 on 2015-07-10.

Removed with this revision.

Hi all, in paragraph #arraysearcharraysearch, what is the use of first row of the example "Return index of first occurrence of a value" since it is duplicated at the head of the second row ? Thanks. --Christian 🇫🇷 FR (talk) 20:24, 20 November 2023 (UTC)

Removed with this revision.

in paragraph Configuration/$egArraysCompatibilityMode, remove link to sub page -> https://www.mediawiki.org/wiki/Special:MyLanguage/Extension:Arrays/Pre_2.0_Documentation#Differences_compared_to_Arrays_2.0 since it is itself a redirection to the current page itself -> #REDIRECT [[Extension:Arrays]] --Christian 🇫🇷 FR (talk) 19:41, 21 November 2023 (UTC)

Removed with this revision.

dead link in "6.4 Working with Extension:DynamicPageList" for

"DPL query. In the example" ->  http://semeb.com/dpldemo/index.php?title=DPL_Example_017

is no longer responding. Please can someone realign ? Thanks. --Christian 🇫🇷 FR (talk) 19:53, 21 November 2023 (UTC)

It seems that {{#arraysort:}} is more effective when letters are involved, but its duties with numbers leave a bit to be desired--and the extension's documentation has never made note of that. That much I found out after noon two days ago after setting up my first box-office chart for my geofictional realm in 8½ years. A title that was supposed to be #18 in rank...suddenly jumps into fourth place. (For context, the figures are 645247 [#3], 44189 [#4], 422290 [#5], 400261 [#6]... when they should be arranged as 645247, 422290, 400261...44189.)

It seems that PHP's natsort may be needed to remedy this in a future update of the extension. Until then, one must resort to this workaround if their site uses Page Forms (ad hoc example provided below):

{{#arraydefine:rand|{{#arraymap:4, 586, 46, 8, 79, 1031|,|*|<span style="display: none">{{padleft:*|4|0}}</span>*}}}}{{#arraysort:rand|desc}}{{#arrayprint:rand}}

To developers @Lidingpku: /@Baojie: /@Danwe: (And maybe recent talk-page guest @MGChecker: ) Just letting you three know of this apparent, hitherto-undiscovered upstream bug (in case you're still active on Wikimedia/MW.org). (Which may be enough for me to finally join WM Phabricator just so I can make a filing on this matter.)

---

Delayed by two days thanks to the technical difficulties described in Support desk Topic:Xjjrg9rs06eshjj0. --Slgrandson (talk) 22:18, 8 June 2023 (UTC)

Hi! is it somehow possible to create an array out of an API-result? I want to get an array of all Namespaces and the furthest I got was with an API-query:

api.php?action=query&meta=siteinfo&siprop=namespaces

There is the option to use the extension Jsoner, but I think this is a bit of an overkill since I am not querying from an external site..

Is there a place to vote against the incompatibility of future MW developments with this very useful extension? :-/

Personally, I would rather scuttle Parsoid than Arrays and Variables. ;-)

Let's focus this at Extension talk:Variables.

As the topic says.

Unfortunately there isn't. Per ExtArrays.php line 188, the only valid values for the print option are list, which prints the input as a simple list, and pretty, which instead pretty prints it with the last two items separated by and (or presumably the interface language equivalent, depending on what exactly the $wgLang->listToText() function does).

If your wiki has Extension:Page Forms installed, you can instead use #arraymap, which allows you to change the delimiter used between the final two items in the array.

Tracked in Phabricator
Task T245134

Individual wikis can fix this by applying the changes listed here.

MW 1.34 + Arrays 2.2.0 (40737de)

Converted to 1.34 and seeing the "array prints "Array" issue [1] already documented.

I understand that it can be addressed one of two ways:

1. Add $egArraysCompatibilityMode = true; in LocalSettings, or
2. Update uses to conform to the new implementation standard.

I'm perfectly happy to update my wikitext to conform to the new array coding standard, but it's not clear to me what changes I need to make. The examples provided in Extension:Arrays hasn't changes that I can tell, only the way the extension processes the array values. Where's the in-wiki issue?

Please, what is the "in wiki" change I need to make to allow Arrays to handle my data as it previously did?

Thanks!

/Rich Revansx (talk) 12:51, 23 September 2020 (UTC)

[1] Topic:Vmucn50w8yy30mmp

In the meantime I have put the extension into compatibility mode and indeed, all seems well.

No change should be required, this is purely an extension-side bug. See phab:T245134.

Is this already solved in MW 1.35 by chance?

I don't think so; my understanding is that this has to be fixed in the extension, not in MediaWiki (though I could be wrong).

You can fix this by editing the extension.json as shown here.

Thanks a lot! The provided patch works very well for me!

The classical parser newline tricks involving <nowiki /> allow making lists using arrays.

I'm using this extension to build a template that takes a comma seperated list as an argument and prints it out as a bulleted list. It works for the first bullet, but the subsequent bullets are rendered as asterisks. Is it a bug?

{{#arraydefine:people|{{{1|}}}{{{people|}}}|,}}{{#arrayprint:people|<br />|@@@@|*{{has person|@@@@}} }}

I'm testing it with

{{has people|john smith, jason smith, sally smith}}

Which gives me something like this: https://www.crewsgenealogy.com/wiki/Test/array_problem

Is it a bug, or am I just missing something?

You need the list syntax at the beginning of a line. Try the following code instead:

{{#arraydefine:people|{{{1|}}}{{{people|}}}|,}}{{#arrayprint:people|<br />|@@@@|
*{{has person|@@@@}} }}

If that doesn't fix it (I can't ever remember without testing myself), insert a <nowiki/> or <noinclude/> at the end of the first line:

{{#arraydefine:people|{{{1|}}}{{{people|}}}|,}}{{#arrayprint:people|<br />|@@@@|<noinclude/>
*{{has person|@@@@}} }}

Thanks, the </nowiki> did the trick.

In the arraysearch documentation, it states, "This function...returns an empty string when failed." However, in practice, I am seeing that it returns -1.

That is the case if compatibility mode is set (or you're using an old version of the extension), but it is not the current behaviour.