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.

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.

It should be simple. My example-code:

{{#arraydefine:test|-1,-2,1,2,3|,}}

{{#arrayprint:test|<br/>|@@@@|Test: @@@@}}

Returns:

Test: -Array

Test: -Array

Test: Array

Test: Array

Test: Array

Why?

See my example.

Ah! There's a bug:

Notice: Array to string conversion in PATH/htdocs/mediawiki-1.34.1/extensions/Arrays/ExtArrays.php on line 1220 Notice: Array to string conversion in PATH/htdocs/mediawiki-1.34.1/extensions/Arrays/ExtArrays.php on line 1220

Can you file an issue for this on Phabricator? If this is something that will affect any 1.34 wiki trying to use Ext:Arrays, it needs to be resolved.

Thanks for pointing this out: https://phabricator.wikimedia.org/T245134

I solved this by setting legacy mode.

Ran into this myself. "Array blah blah blah" instead of the expected "1 blah blah blah" as output. Now, trying to figure out what the mentioned legacy mode is...

Extension:Arrays#Configuration

Add `$egArraysCompatibilityMode = true` to local settings. This will change other things, though. I wanted to point to the old docs, via diff link, but the abuse filter says it's harmful.

The old docs in question are at Special:Diff/2888061#Differences compared to Arrays 2.0.

I ended up using a rather clunky workaround, but it works, without the negatives of compatability mode. Only negative is that when you sort the array, 1, 2, and 3 will sort at the end, rather than the beginning.

In my case, {{{Bar}}} is a CSV string that I turn into an array.

{{#arraydefine:Foo|{{#replace:{{#replace:{{#replace:{{{Bar}}}|1|①}}|2|②}}|3|③}} }}

Then later:

{{#arrayprint:Foo|
|@@@@ |{{#vardefine:val|{{#replace:{{#replace:{{#replace:@@@@|①|1}}|②|2}}|③|3}} }} ... }}

Just an update that 0 is also affected, though 4 through 9 are ok to leave 'unprotected'.

I am looking for a solution to count the number of occurrences of a string in an array. PHP has "array_count_values", did anyone make this available already for Arrays in MW?

[Apple, Pear, Apple, Banana] Apple = 2, Banana = 1, Pear = 1.

Thanks,

Best wishes,

Timo

Assuming your wiki has Extension:StringFunctions enabled, you could use wikia:yugioh:Template:Count. I don't think there's a built-in solution, though.

I've added floor to get rid of the decimals.

This works for strings indeed, my problem is counting occurrences of a string in an array of strings. When I copy those into 1 string to let {{count}} work, the string has gotten to long.

Your idea may help me though, I have to implement something to loop through the array counting for each element of the array.

Thanks!

Simply use arraysearcharray in combination with arraysize.

I upgraded my database from MW 1.31 to 1.33, but I am having problems with the Arrays extension, specifically seeing strip markers (e.g. UNIQ--nowiki-ArrayArrayArrayArrayArrayArrayArray6-QINU) in the rendered page and the following messages:

Notice: Array to string conversion in extensions/Arrays/ExtArrays.php on line 1216

Warning: Cannot modify header information - headers already sent by (output started at /extensions/Arrays/ExtArrays.php:1216) in /includes/WebResponse.php on line 72

I'm not sure if this is related to other problems folks have posted. Any help appreciated!

I'm not exactly sure what the problem here was; I reverted to an earlier version of the extension.

The Arrays extension (version 2.2.0) cannot parse certain numbers (1, 2, 3, 0) under certain condition. These number changed to "Array" on output if a custom pattern is used.

Input: {{#arraydefine:places|1234567890; 2WE340; 654453562|;}} {{#arrayprint:places||@R|<nowiki/> * [[@R]]}}{{#arrayprint:places}} Output:

• ArrayArrayArray456789Array
• ArrayWEArray4Array
• 65445Array56Array

1234567890, 2WE340, 654453562

https://phabricator.wikimedia.org/T245134

Consider the following example. The results in the top 12 and the bottom 12 should be identical, but after you run arrayunique, results from arraysearch are incorrect.

{{#arraydefine:abc|10, 0, 0, 0, 0, 0, 0, 8, 0, 0, 0, 6, 0, 7, 1, 0, 9, 0, 5, 12, 11}}

#{{#arraysearch:abc|1|0|1|0}}
#{{#arraysearch:abc|2|0|1|0}}
#{{#arraysearch:abc|3|0|1|0}}
#{{#arraysearch:abc|4|0|1|0}}
#{{#arraysearch:abc|5|0|1|0}}
#{{#arraysearch:abc|6|0|1|0}}
#{{#arraysearch:abc|7|0|1|0}}
#{{#arraysearch:abc|8|0|1|0}}
#{{#arraysearch:abc|9|0|1|0}}
#{{#arraysearch:abc|10|0|1|0}}
#{{#arraysearch:abc|11|0|1|0}}
#{{#arraysearch:abc|12|0|1|0}}
{{#arrayunique:abc}}

#{{#arraysearch:abc|1|0|1|0}}
#{{#arraysearch:abc|2|0|1|0}}
#{{#arraysearch:abc|3|0|1|0}}
#{{#arraysearch:abc|4|0|1|0}}
#{{#arraysearch:abc|5|0|1|0}}
#{{#arraysearch:abc|6|0|1|0}}
#{{#arraysearch:abc|7|0|1|0}}
#{{#arraysearch:abc|8|0|1|0}}
#{{#arraysearch:abc|9|0|1|0}}
#{{#arraysearch:abc|10|0|1|0}}
#{{#arraysearch:abc|11|0|1|0}}
#{{#arraysearch:abc|12|0|1|0}}

Results:

1. 1
2. 0
3. 0
4. 0
5. 1
6. 1
7. 1
8. 1
9. 1
10. 1
11. 1
12. 1

1. 0
2. 0
3. 0
4. 0
5. 0
6. 0
7. 0
8. 1
9. 0
10. 1
11. 0
12. 0

This works correctly for me on a wiki running MediaWiki 1.31.1 and Ext:Arrays 2.1.0. What's your version of MediaWiki and Ext:Arrays? What do you see if you add an {{#arrayprint:abc}} after the #arrayunique? I see 10, 0, 8, 6, 7, 1, 9, 5, 12, 11.

A fresh install of MediaWiki 1.33.1 with Ext:Arrays 2.1.0. I get that same result (10, 0, 8, 6, 7, 1, 9, 5, 12, 11) from arrayprint when run after arrayunique. That's what kept throwing me trying to find this bug; after arrayunique, arrayprint is right, but the arraysearch results are completely wrong.

A sample of the bug is live and visible at... ok, the system here refuses to let me post a link. Replace the spaces in the following with periods to get a url: wiki stratics com/index.php?title=User:BrianFreud/arrBug

Okay, that's definitely a bug. Would you be willing to file a Phabricator ticket for this? I can do so if you can't or don't want to, just let me know.

For curiosity's sake, what happens if you define a new array like {{#arraydefine: def | {{ #arrayunique: abc }} }} and run the #arraysearch stuff on the new def array? What about if you define a third array like {{#arraydefine: ghi | 10, 0, 8, 6, 7, 1, 9, 5, 12, 11 }} and run the #arraysearches on it?

I've updated that same link with the three tests.

test1 fails; it is the arraydefine using only the arrayunique as input

test2 passes: it is the arraydefine using an arrayprint of the unique'd array

test3 passes (as we'd expect); it is the arraydefine using a manually entered copy of the unique'd array

Test 4 is a clean test with a new input array (same input as the un-unique'd array abc).

It passes. Looks like

```

{{#arraydefine:def|{{#arrayunique:def}}{{#arrayprint:def}}}}

```

is a working workaround, though it's clunky, and not what you'd expect to have to do.

I can enter a Phabricator ticket after work; don't have an account there to do it at the moment.

That's the result I was expecting, to be honest.

Be sure to link the ticket here after you've created it!

Here you go: https://phabricator.wikimedia.org/T243031