Foreach loop with more than 50 results hangs up the system

[bbarclay]

I’m using

rasteiner/controlledlist

But when I try and pass a foreach array through this with more than 50 results. It hangs up .

I can use this.

      $start = 1;
        $end = 1123;
        $values = array();

        for ($start; $start < $end; $start = $start + 1) {
            $values[$start] = $start."helloworld";
        }
return($values);

It works just fine. But when I try something like.

   $values = array();
       foreach ($users as $user) {
          $test[$user->name] =
          $user->name;
           $values = array_slice($test, 0,45);
      }
 // print_r($output);
return $values;

I sliced the array to 45 and it hangs, if I put it down to 5 it works just fine, but still slow.

It freezes up. Any idea why this might be happening?

It uses this to pass the results in.

class ControlledradioField extends RadioField {
	public function options() {
		return call_user_func($this->controller, $this);
	}
}

[bbarclay]

It must be something in my array because I run the following code and it works just fine.

 static function userlist($field) {


        $start = 1;
        $end = 1123;
        $values = array();

        for ($start; $start < $end; $start = $start + 1) {
            $values[$start] = "helloworld";

        }

        echo "somethingelse";
       // print_r($values);
        $theseVals = $values;

        // $kirby = kirby();
        //$site = $kirby->site();
       // $users = $site->users();
// print_r($theseVals);
        $result = array();

        foreach ($theseVals as $key => $value) {
           $result[$key] = $value;
        }

       return $result;
    }
}

[texnixe]

I’m a bit suprised that the above works at all, because the User class does not have a name method:

class Test {
    static function userlist($field) {
        $kirby = kirby();
        $site = $kirby->site();
        $users = $site->users();

        $result = array();

        foreach ($users as $user) {
            $result[$user->username()] =
                $user->username();
        }
        return $result;
    }
}

Can’t test with that many users, though.

[texnixe]

So, I now script-generated 100 users and tested with those. And I can confirm that it takes very long to generate the options list when using checkboxes, although the system does not hang itself up. The result is way faster with select or radio fields. While I doubt that such a long list of options really makes sense, this is still weird.

I recall there was an issue on GitHub regarding checkboxes and JSON API queries, but that was fixed in June. And when using the JSON API now, the options are created fast, at least after the second load.

I also tested the above user example without a named key and it way a lot faster.

[bbarclay]

If we are referencing back to the other post. Checkboxes creating a funny loop with input values (Possible Bug) or Improvement

It’s somehow returning the number of array $keys, plus 1 array.

this array.

$array = array(‘green’ => ‘blue’, ‘tan’=> ‘red’, ‘tan’ => ‘green’,);

Gives this result. Also notice it combines any simular $keys but also counts the array then loops through that many times. + 1.

Array ( [green] => blue [tan] => green ) Array ( [green] => blue [tan] => green ) Array ( [green] => blue [tan] => green ) Array ( [green] => blue [tan] => green ) Array ( [green] => blue [tan] => green ) Array ( [green] => blue [tan] => green ) Array ( [green] => blue [tan] => green )

[texnixe]

@bbarclay

$array = array(‘green’ => ‘blue’, ‘tan’=> ‘red’, ‘tan’ => ‘green’,);

This array does not make sense. You can’t have duplicate keys.

[bbarclay]

It was to verify that it’s counting. But yeah, we don’t have duplicate keys. I just wanted to see if it ignores it or counts it, which I’m pretty sure it’s counting it.

Update. Or it’s not

$array = array(‘green’ => ‘blue’, ‘tan’=> ‘red’, ‘pink’ => ‘green’,); This returns the array below. Which is 10 so it’s 3 times the loop plus one.

Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green ) Array ( [green] => blue [tan] => red [pink] => green )

Just tested

$array = array(‘green’ => ‘blue’);

Array ( [green] => blue ) Array ( [green] => blue ) Array ( [green] => blue ) Array ( [green] => blue )

[texnixe]

I think I’ve lost track. What are you doing with the array to get the above result?

[bbarclay]

I thought you were refering to this. Checkboxes creating a funny loop with input values (Possible Bug) or Improvement

Which from here. I use the plugin.

Then run the plugin

class MyPlugin {

   static function getpermissionslist() {
       $array = array('green' => 'blue');
       print_r($array);
}

}

in yaml I do like on the other page and also use the plugin on the other page. If I change this to radio button the array only returns once.

It’s like something is hitting this multiple times causing it to loop the array and that’s what’s slowing down the return time.

[texnixe]

Ah, ok, I don’t get multiples, though.

This:

class Test {
  static function userlist() {
      $array = array('green' => 'blue', 'yellow' => 'black');
      dump($array);
  }
}

dumps

Array
(
    [green] => blue
    [yellow] => black
)

as it should.

[bbarclay]

Crazy. Could this be a plugin interfeiring?
Array
(
[green] => blue
)
Array
(
[green] => blue
)
Array
(
[green] => blue
)
Array
(
[green] => blue
)

[texnixe]

That’s what I was just going to ask, have you tested this with a nice, fresh Starterkit yet? I haven’t tested with 2.5.6 yet, but I don’t think there have been any changes from 2.5.6 to 2.5.7 that could be causing this behavior.

Edit: As expected, 2.5.6 gives me the same results.

[bbarclay]

My fault was using.

    static function getpermissionslist() {
        $array = array('green' => 'blue');
        dump($array);
return $array;

But still large queries take forever with the checkboxes. We have 500 options and are using.

distantnative/field-multiselect

so checkes are organized, but the regular checkbox is slow to filter through the results.

Hope this helps and there is a solution to parse them in faster.

[texnixe]

Isn’t 500 options a bit overdoing it with regular checkboxes? I still have a feeling that it is faster without named keys.

[bbarclay]

They are internal company permissions. The permissions have ID’s but dev is saying the permissions are all stored by name, because that is the practice for those permissions. So if I ever reference them, they have to be by name. I wish I could and there weren’t that many. Not my decision though. lol.

[texnixe]

How about using the JSON API instead of the controlledList plugin?

[bbarclay]

These are all coming out of a JSON webservice. It’s not the webservice that’s slow though, I’ve eliminated that.

Can the JSON API be used with webservices calls?

[texnixe]

Via a route that shouldn’t be a problem at all.

If your web service call is a URL that returns nothing else than JSON encoded key/value pairs, it might even work directly (have never tested that)

Field:

  mycheckboxes:
    label: Users
    type: checkboxes
    options: url
    url: api/users.json

route:

c::set('routes', array(
  array(
    'pattern' => 'api/users.json',
    'action' => function () {

     // your web service call instead of this, of course
      $users = site()->users();

      $result = array();

      foreach ($users->limit(60) as $user) {
          $result[$user->username()] = $user->username();
      }
      return response::json($result);
    }

  )
));

It’s at least worth a test. Maybe you can even cache the results?