The problem

Currently, the plugin loads the defined value(s) from the structure, and stores them as static text with just the fields defined in the blueprint.

It would be much more handier if the defined optionkeys were there only to make <select> options easier to read, but under the hood, the plugin would fetch the results dynamically with all the fields of the desired structure.

Use case: Footnotes & bibliography

I am currently working on an academical project. I have a bibliography page with all the entries stored in a structure field. It's rather extensive, as you can see below:

printed:
    label: Printed books and materials
    type: structure
    entry: >
      {{author}}, <i>{{title}}</i>.
    fields:
      author:
        label: Author
        type: text
        icon: user
      groupWork:
        label: Joint publication
        type: toggle
        text: yes/no
        required: true
      title:
        label: Title
        type: text
        icon: font
        required: true
      translation:
        label: Translator
        type: text
        icon: language
      inGroup:
        label: Joint publication title
        type: text
        icon: book
      redaction:
        label: Redakcja
        type: text
        icon: user
      print:
        label: Press
        type: text
        icon: book
      year:
        label: Year
        type: number
        min: 1900
        icon: calendar

Then, in different parts of my website, I have content that requires to have the source written down beneath. Every source I use must go to bibliography too, so it seems logical to make source a select field with all the entries from the bibliography.

For that purpose I wanted to use this plugin. First issue I encountered was the inability to use multiple optionkey values, which I have fixed. This is not enough in my case, though, I want not only few fields in my source, but the entire bibliography entry.

It's not a good solution to enter all the fields into the optionkey, as it would render <select> unreadable and be basically hard-coded. Any future changes in the bibliography structure and it might get broken.

Idea

I have come up with an idea how to fix that. There could be another dynamic option in the blueprint for the type: selectastructure field:

selecty:
    type: selectastructure
    structurepage: staffpage
    structurefield: stafflist
    optionkey: staffname
    dynamic: true

It would default to false to keep this backward-compatible. Then it would work just as now.

With the dynamic option however, the plugin would rather fetch a unique ID of each structure entry, and store this dynamic link instead of the value.

Then in the template, Kirby could dynamically load a structure directly from the page. Since we already store information about what page it is and how the field is named, it would work like that:

$selectedStructure = page($structurepage)->structurefield()->toStructure()

To get just one structure entry, we have the powerful get() method:

$selectedStructure->get($uniqueId)

Caveat

One and only caveat I can see, is that there would have to be something like uniqueid field in the structure, and its value would have to be unique per structure. This could be solved either by the user:

printed:
    label: Printed books and materials
    type: structure
    fields:
     uniqueId:
         label: Unique ID
         type: text
         required: true
      ...

Or, alternatively, it could be handled by this very plugin, with the introduction of a new custom field type, e.g.:

...
fields:
    uniqueID:
        type: selectastructureid
        required: true

This would get filled automatically for the user. UUID would be my option-of-choice in implementing that.

Summary

I will probably try to implement that in the following days, as it's something I have to have in my project. If there's any other ideas on how to accomplish that, then I'll be more than happy to read them.

Also, I want to thank you @calebgrove for the great plugin!

Hello! First of all thank you for this plugin. I've been looking for a while how to do this :)
Everything is in the title. I have in my structure 3 fields (width, length, height) and I would like to know if there is way to display the three values with optionkey?

Thank you in advance for your answer :)

I just wanted to test your Plugin and unfortunately getting an error:

Method SelectAStructureField::__toString() must not throw an exception, caught Error: Call to a member function location() on boolean

This occurs even if just test with a simple minimal example and of course I followed your installation instruction. Maybe you have a fast shot? Thx!

Here you can see my fields. Could it be a problem that both are on the same page?

I was surpriced that I needed to add structurepage to my blueprint. It's not very flexible if I want to use the blueprint for more than one page and I want the structure field on the same page.

My suggestion, fallback to the current page if structurepage is missing.

As it currently stands, structurepage in the blueprint is set to a string version of the page URI. This is nice and simple, but is very inflexible as it is always tied to one exact page.

Instead, you should be able to use good a 'ol Kirby page selection logic that returns a page object. For example, you could use structurepage: $page->parent() to select the parent of whatever the current page is. This would allow for usage in larger, more complicated websites where a blueprint may be used in many different contexts.

This only issue here is that backwards compatibility would be broken unless we use a new key (structurepage would continue to work as it does, page [for example] would be the newer implementation).

question: from looking at the gif... it needs a 'save' before the dropdown has the new values of the structure, right?

Given this blueprint:

staffmembers:
  type: structure
  fields:
    name:
      type: text
    position:
      type: text
employeeofthemonth:
  type: selectastructure
  structurepage: staff
  structurefield: staffmembers
  optionkey: name

This field currently writes this to the content file:

Employeeofthemonth: Gary

But, I would rather have it write it to the file as a single structure entry:

Employeeofthemonth:

-
  name: Gary
  position: Intern

Pros:

• As the entire entry is stored, it would make template logic much easier. You no longer need to navigate to the structurepage and filter through the structurefield to pull more data than the optionkey.

Cons:

• Because the entire entry is stored, updating the structurefield would result in the Employeeofthemonth becoming outdated. For example, if you changed Gary's position to CEO in the structurefield, Employeeofthemonth would still be left with his position as Intern.

It would be really nice if one could select multiple values from the structure field.
Example: Say you have more than one staff member responsible for the area. Perhaps you can pair it with the existing multiselect field https://github.com/distantnative/field-multiselect?