Extension talk:Arrays

About this board

Old messages until March 2011 are archived.


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?"
Kaffeeringe (talkcontribs)

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.

Kaffeeringe (talkcontribs)

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

Dinoguy1000 (talkcontribs)

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.

Kaffeeringe (talkcontribs)
99.232.155.35 (talkcontribs)

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

Becasita (talkcontribs)

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.

Dinoguy1000 (talkcontribs)
Brianfreud (talkcontribs)

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

99.232.155.35 (talkcontribs)

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

Reply to "arrayprint prints "Array""

Counting the number of occurences of a value in an array?

4
82.161.136.28 (talkcontribs)

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

Dinoguy1000 (talkcontribs)
82.161.136.28 (talkcontribs)

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!

Danwe (talkcontribs)

Simply use arraysearcharray in combination with arraysize.

Reply to "Counting the number of occurences of a value in an array?"

problems with MW 1.33.0 upgrade

2
108.7.72.249 (talkcontribs)

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!

108.7.72.249 (talkcontribs)

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

Reply to "problems with MW 1.33.0 upgrade"

Arrays extension cannot parse certain numbers

1
Acnetj (talkcontribs)

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

Reply to "Arrays extension cannot parse certain numbers"

#arrayunique breaks #arraysearch

8
99.232.155.35 (talkcontribs)

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
Dinoguy1000 (talkcontribs)

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.

99.232.155.35 (talkcontribs)

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.

99.232.155.35 (talkcontribs)

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

Dinoguy1000 (talkcontribs)

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?

99.232.155.35 (talkcontribs)

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.

Dinoguy1000 (talkcontribs)

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

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

Brianfreud (talkcontribs)
Reply to "#arrayunique breaks #arraysearch"
184.20.10.253 (talkcontribs)

Extension:Arrays#Fatal bug


$egArraysExpansionEscapeTemplates is currently not initialized correctly, I think because of JSON code:

"config": {
		"ArraysCompatibilityMode": {
			"description": "Set to false by default since version 2.0.",
			"value": false
		},
		"ArraysExpansionEscapeTemplates": {
			"description": "Contains a key-value pair list of characters that should be replaced by a template or parser function call within array values included into an '#arrayprint'. By replacing these special characters before including the values into the string which is being expanded afterwards, array values can't distract the surrounding MW code. Otherwise the array values themselves would be parsed as well.\n\nThis has no effect in case $egArraysCompatibilityMode is set to false! If set to null, Arrays will jump to compatibility mode behavior on this, independently from $egArraysCompatibilityMode.",
			"value": [
				{
					"=": "{{=}}"
				},
				{
					"|": "{{!}}"
				},
				{
					"{{": "{{((}}"
				},
				{
					"}}": "{{))}}"
				}
			]
		}
	},

The PHP code produces an associative array that matches how escapeForExpansion uses it. escapeForExpansion produces a PHP diagnostic. Oddly though I didn't see it until I had a page name with an apostrophe in it. So it's possible escapeForExpansion isn't always utilized, without doing more analysis. Note, escapeForExpansion is the only consumer of $egArraysExpansionEscapeTemplates at least inside of ExtArrays.php.

$egArraysExpansionEscapeTemplates = [
	'='  => '{{=}}',
	'|'  => '{{!}}',
	'{{' => '{{((}}',
	'}}' => '{{))}}'
];
Dinoguy1000 (talkcontribs)
184.20.10.253 (talkcontribs)

Thank you, looking at https://phabricator.wikimedia.org/T240111 I suggest explaining the extension.json code is the likely source of the error. I think it was probably written in haste, since extension.json is a new framework. This report here in Talk is a better resource I think. I tried to make the explanation in the Article easy to understand without tearing into details, so people can figure out a way to initialize the variable manually, since that's the only way to fix it (without modifying the JSON file or converting the JSON result into the expected result, whichever is correct. I don't know enough about the JSON setup to solve the problem.)

184.20.10.253 (talkcontribs)

Here (Topic:Vcpmy66hprtm34jy) is attempt an editor made to hide the problem, they should be prepared to fix it them, or any case the problem is hidden now, so I hope someone is seeing it through. Someone should be interested in shepherding this new JSON system since someone saw fit to institute it.

Reply to "Nonworking status 1.33.1"
Return to "Arrays" page.