Get Options via API causes Timeout-Error

1

My blueprint looks like this:

  item:
    label: Code-Element
    type: select
    options: api
    api: 
      url: "{{ site.url }}/mm-api"
      text: "{{ item.title }}"
      value: "{{ item.value }}"

This is my url: http://127.0.0.1:3000/mm-api

And here is what i get if i open this url in my browser:
[{"value":"pano","title":"Pano"}]

If i do this, the panel loads really slow and the field comes up with an error:

Operation timed out after 10004 milliseconds with 0 bytes received in file: /path_to_my_project/kirby/src/Http/Remote.php line: 288

2

This should actually work and I would only expect a timeout with a lot of data. What is in your route?

3

I’m currently facing the same problem with a “tags” field:

      chart:
        label: Select one or more charts
        type: tags
        options:
          type: api
          url: '{{ site.url }}/charts.json'

        [
            'pattern' => 'charts.json',
            'action' => function() {
                $content = [
                    'value1' => 'Value1',
                    'value2' => 'Value2',
                    'value3' => 'Value3'
                ];

                return new Kirby\Cms\Response(json_encode($content), 'text/json');
            }
        ],

I’m debugging Remote.php but it’s still not clear why the request goes in timeout.
Of course the endpoint is reachable without any problem via browser.
Tried to play around with the remote.ca options, different return statement in the route etc.

4

Try return $content instead.

5

Thank you for your message.

Unfortunately this doesn’t solve the problem! :frowning:

6

Well, your example above works for me. But since you are talking about the Remote class, I guess that’s not your real world example…

7

Sorry what do you mean with that?
I mentioned the Remote.php class because it’s there where the timeout occurs, since that is the place where a curl call is made.

8

My bad, the OptionsApi calls the Remote class.

I have no idea why you are running into a timeout with such a minimal setup.

What is your environment, are you testing this locally?

Could you post your phpinfo() output?

9

Just fixed the issue with the timeout by switching from PHP CLI to Valet.
For what I understand, the PHP CLI running environment doesn’t allow the creation of a second PHP process, but this is what a curl request actually makes.

Unfortunately, this doesn’t end here.
Now I have a different error:

Kirby\Query\Query::factory(): Argument #1 ($query) must be of type string, null given, called in /Users/abc/projects/Website/kirby/src/Option/OptionsApi.php on line 113 in file: /Users/abc/projects/Website/kirby/src/Query/Query.php line: 54

Now, if I debug OptionsApi.php I see that the values are actually fetched from the endpoint specified by the “url” property in the YAML file, since I find them in the $data variable in the resolve() method.
For some reason however, $this->query in the resolve() method is null, and this is a problem because Query::factory() is called and expects a string as the first argument.
Any idea? :slight_smile:

10

It seems like the reason for this last problem is that I’m not using the latest Kirby version! Using an empty “query:” property in the YAML file patches it.
Hope this can be helpful for others. :slight_smile: