Pages field in page create dialog

Kirby 4
1

Would really love to be able to use the pages field in the new page create dialog.

In my use case when creating events, each event has a venue which is selected in a pages field. It would make sense to add the date and the venue in the dialog and publish directly. It’s very cumbersome to have this extra step just for this one field.

2

Yes, these fields are disabled so as not to open a dialog within a dialog. You could work around this problem by using a select field/multiselect field instead.

3

Thanks @texnixe .

I really do think it makes a lot of sense to make the pages field available. Multiple modals visually layered, or one modal where content is replaced when “drilling down” a level, does not have to be a problem from UI/UX point of view. But perhaps it’s a challenge from how the panel currently works?

I was trying out your idea now to workaround the limitation. There are about 400 venues so I tried with the multiselect field, as the regular select lacks search.

venue:
    type: multiselect
    max: 1
    min: 1
    search: true
    options:
      type: query
      query: kirby.page("venues").children.sortBy("city", "asc")
      text: "{{item.city}} • {{item.title}}"
      value: "{{item.uuid}}"

If I would change the current pages field into a multiselect field, it needs to be compatible with existing content and code. I have thousands of pages, content currently look like this:

Page field

----

Venue: - page://jwgSg9m8rvJcIEWo

----

Multiselect with value: "{{item.uuid"}}:

----

Venue: page://jwgSg9m8rvJcIEWo

----

Is the hyphen needed for it to be understood as a page/pages object or why is it different? Could I just add the hyphen to the value to get the same shape of data?
…
value: "- {{item.uuid}}"

With the pages field the editor can click the selected page to edit/view it, which will be lost with this solution. Perhaps I can add in the link in the fields help text or info section using query…

4

Yes, would love to see this as well. However, simply adding the files, pages and users in the list of supported fields doesn’t do the job :innocent:

You would have to update the pages programmatically. A multiselect store a comma separate list of values, a pages field stores the page uuids in yaml format.

5

However, simply adding the files, pages and users in the list of supported fields doesn’t do the job :innocent:

Haha, that’s for sure! Just trying to make sure your todo-list is never empty :wink:

A multiselect store a comma separate list of values, a pages field stores the page uuids in yaml format.

Ah yes you’re right. But in this case the user should only select a single option. I’ve limited the multiselect with max: 1. If I use value: "- {{item.uuid}}" on the multiselect, at least what I get in the text file look exactly the same as the yaml I get from the pages field. Does that make sense? Or will Kirby complain about the field type with methods like $venue->toPage()? If this work it would let me maintain compatability with the pages field if I decide to switch back later.

Did I forget to say, you’re all doing a fantastic job with Kirby and your support on this forum is top-notch. So thank you!

6

So I tested using the multiselect as replacement for the pages field to be able to use it in the page create dialog. To give a bit more context, the user is setting up a a tour with multiple events. An event is a page containing a date and one (1) venue, plus some additional info.

          venue:
            label: Venue 
            type: multiselect
            max: 1
            min: 1
            search: true
            required: true
            options:
              type: query
              query: kirby.page("venues").children.sortBy("city", "asc")
              text: "{{item.city}} • {{item.title}}"
              value: "- {{item.uuid}}" #make it look like yaml

To not risk breaking thousands of pages I want the multiselect store it’s data as if it were a pages field (yaml), hence I added a hyphen to the value. This should work, as we are only allowing one item to be selected anyway.

And indeed this seem to work everywhere on the site without touching the existing code (toPage methods and so forth working fine both in templates and blueprint query language / template strings). Except for in the page create dialog where I want to use it in the title and slug like this:

# no output from venue, but same template strings work in e.g help fields
create:
  title: "{{ page.venue.toPage.title }} • {{ page.startDate.toDate('EEE yyyy-MM-dd') }}"
  slug: "{{ page.startDate.toDate('yyyy-MM-dd') }}-{{ page.venue.toPage.city.slug }}"
  status: listed
  redirect: false
  fields:
    - startDate
    - venue
    - startTime
    - endTime

{{ page.venue.toPage.title }} and {{ page.venue.toPage.city.slug }} is not outputting anything to the title or slug. No error thrown. If I put the same template strings in a help field, they output correctly (after the page is created).

Any idea why this happen? I understand I’m bending things a bit too much, but it would be great to understand. Actually I did manage to make a custom field method using the page helper. The method works in the create dialogs title and slug, but only there and not in other places, and seems a little hacky so I can’t let it go :exploding_head:

# with this I can do {{ page.venue.toVenue.title }} in the create dialog 
# NOT WORKING in other places
"fieldMethods" => [
    "toVenue" => function ($field) {
       $uiid=$field->value(); 
       $uiid=Str::ltrim($uiid[0], "- "); 
       $venue = page($uiid);
       return $venue;
    },

Kirby 4.1 using uuids.