Get default language uri from object in the panel

In the panel we can get the page object by $page = $this->page(); inside a field, so that is what I did.

sv is my default language in a multi language installation.

$page = $this->page();
echo $page->uri();
echo $page->uri('sv');
echo $page->content('sv')->get('uri');

On an english page

The result on an english page of the above is this:

activities/image/the-boat
pages/aktiviteter/bild/baten/sv
Empty string

I find it very strange.

  • This output is like expected, an english correct output.
  • What is this? It seems like a panel uri. The uri I expect is aktiviteter/bild/baten
  • This does only seem to work on fields.

Expected result

aktiviteter/bild/baten

It should not add sv because it’s the default language.

Question

  • How can I get the uri?

@texnixe Maybe you know this one?

Update

I fixed a bug that came with it when I rewrote it to fit the forum format. Even simpler now. No foreach loop.

Ehm, foreach( $page as? What are you trying to do there? Iterating through a single page does not work.

I rewrote the code to fit the forum format and it introduced this bug.

I have fixed it and now it even more simple, no foreach loop.

  • Can I get the uri I expect?
  • If not, is it a bug?
  • If not, add it as suggestion to the repo?

Alright.

A quick comment on the different ways you posted:

echo $page->uri();

You already wrote that, but: This returns the URI for the current language.

echo $page->uri('sv');

I just tested this syntax in the langkit on a project page and got the expected output. So that’s quite strange. Could you please verify if the same code works directly inside the template of your site?

echo $page->content('sv')->get('uri');

This is not supposed to work at all. The URI is not part of the content. The prior syntax should work.

I am not in a template. I am in a panel field. On a mobile device now. Can test more tomorrow.

Yes, I can confirm this, $page->uri('langcode') works in a template, but not in a field. I would consider this a bug and have created an issue on GitHub.

1 Like

It’s because $page in this case is the extended panel-version of the page class. Which implements uri() this way:

public function uri($action = null) {
    if(empty($action)) {
      return parent::uri();
    } else {
      return 'pages/' . $this->id() .  '/' . $action;            
    }
  }

So it’s not working by design. Not sure at the moment how I’d change it. Buuuuuuut workaround that might help:

kirby()->site()->page($page->uri())->uri('sv')

Shot in the dark, but maybe it actually works

EDIT: Just tested it and it should work! \o/

2 Likes

I already replyed on Github but I’ll add it here as well…

I can comfirm that the workaround work like the uri on the frontend.

Suggestions for solution:

  1. $page->uri() in the panel and the frontend does different things. Keep them apart by for example add the $page->panelUri(). Don’t mix them together in a single function.
  2. Change the $page->uri() when inside a field.

I like suggestion 1 better because it feels long term and not hackish. Solution 2 means kind of hack the page uri just for a field.