How to build a frontend select from input to blueprint select field type

Guess this should be pretty easy but I can’t figure out how to start right now.

I have a member blueprint with a location select field. And now I want to build a frontend select based on the field input. Like, I don’t need to output a location if there’s no member assigned to that location.

That’s what I have so far:

<select>
<?php foreach($data->children()->sortBy('location', 'asc') as $locations): ?>
<option value="<?php echo $locations->location()->kirbytext(); ?>">
<?php echo $locations->location()->kirbytext(); ?></option>
<?php endforeach ?>
</select>

Do I have to iterate through the results to build my own location array or is there a function out there to do that. Also I’d want the name for the values from my blueprint.

Phew, guess it’s more a programming question than a Kirby question, right?

And members are users or pages?

Yes, basically members means users.

Would be something like this, I think, not tested:

$locations = $data->children()->sortBy('location', 'asc')->filter(function($location) {
  return in_array($location->location()->value(), site()->users()->pluck('location', ',', true) );
});
foreach ( $locations as $location ) {
 // do stuff
}

Note that using kirbytext() for the option values is not such a good idea, use html() instead.

Thanx, I’ll try this.

Sorry, that was misleading, it’s not the built in users. No, member is my blueprint for a section called members. So yeah, it’s more like a page.

Then try

$locations = $data->children()->sortBy('location', 'asc')->filter(function($location) {
  return in_array($location->location()->value(), page('members')->children()->listed()->pluck('location', ',', true) );
});
foreach ( $locations as $location ) {
 // do stuff
}

Replace members with the path or foldername of the members page.

Well it both gives me a server error. Is there anything in there that’s not available in Kirby2?
Or is it because we are already on that object. The $data here is already my members page.

Ok, from your variable naming I assumed those were the locations. So $data->children() are the member pages then and you want to get the location field values of all these children pages into an array?

Sorry, it’s not so obvious because it’s a one pager hence the $data object.
Yes that’s what I am trying to achieve, ideally grouped with the label name, if that’s possible.

Maybe it’s better explained with these two screenshots.

This is hardcoded what I want to achieve:
Bildschirmfoto 2021-05-06 um 18.03.21

And this is where my knowledge stopped me (my first chunk of code):
Bildschirmfoto 2021-05-06 um 18.03.44

And that’s my blueprint:
Bildschirmfoto 2021-05-06 um 18.22.04

Ok, that’s two problem, the easiest of which is getting rid of the duplicates:

$locations = $data->children()->visible()->pluck('location', ',', true);

This will give you an array of unique location values.

The second part then is to get the nice names for these values. Since we are in Kirby 2 land, you have to create an array with these key/value pairs first, e.g. in your config. Then you can pick the the nice name from that array via the key:

c::set('locations', [
  'ba' => 'Brandenburg',
  // etc.
]);
$locationArray = c::get('locations');
foreach ( $locations as $location) {
  echo $locationArray[$location];
}

Thank you so much. That worked like a charm now. :ok_hand:
Gotta read up on that pluck function, i guess.

Just out of curiosity, with Kirby 3 you can grab the nice name directly from the blueprint?

Yes, Kirby 3 has the $page->blueprint() method that gives you access to the blueprint, so that you can get every little bit of information from it:

Nice. Well maybe it’s time to switch. I just love the simplicity of Kirby 2. That abstraction level of of V3 was too much for me.

Well, admittedly, setting up the Panel has become more complex if you want to leverage the full power of those options. But on the other hand, new features like the blocks or layout fields make creating more complex layouts for editors a lot easier and more visual.

On the frontend, controllers, templates, snippets etc. are still basically the same, I think.