Extension talk:Arrays

About this board

Old messages until March 2011 are archived.


Wladek92 (talkcontribs)
Summary by Kghbln

Removed with this revision.

Wladek92 (talkcontribs)

dead link http://semeb.com

1
Summary by Kghbln

Removed with this revision.

Wladek92 (talkcontribs)
Reply to "dead link http://semeb.com"

{{#arraysort:}} does not honour proper numerical sorting

1
Slgrandson (talkcontribs)

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)

Reply to "{{#arraysort:}} does not honour proper numerical sorting"

Array of available Namespaces

1
MarB-96 (talkcontribs)

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

Reply to "Array of available Namespaces"

About the worrying warning at the top of the page

2
Megajoule (talkcontribs)

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. ;-)

MGChecker (talkcontribs)
Reply to "About the worrying warning at the top of the page"

Is there a way to Pretty Print with 'or' instead of 'and'?

2
160.3.176.211 (talkcontribs)

As the topic says.

Dinoguy1000 (talkcontribs)

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.

Reply to "Is there a way to Pretty Print with 'or' instead of 'and'?"

arrayprint prints "Array" (Part II)

7
Summary by Dinoguy1000

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

Revansx (talkcontribs)

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

Revansx (talkcontribs)

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

Dinoguy1000 (talkcontribs)

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

Revansx (talkcontribs)

Is this already solved in MW 1.35 by chance?

Dinoguy1000 (talkcontribs)

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

MarkAHershberger (talkcontribs)

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

Megajoule (talkcontribs)

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

Reply to "arrayprint prints "Array" (Part II)"
Summary by MGChecker

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

The1gofer (talkcontribs)

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?

Dinoguy1000 (talkcontribs)

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|@@@@}} }}
The1gofer (talkcontribs)

Thanks, the </nowiki> did the trick.

Discrepancy in documentation?

2
Ammcgillivray (talkcontribs)

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

Clump (talkcontribs)

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.

Reply to "Discrepancy in documentation?"