Access previous saved data in blueprint

Support Forms & Blueprints
1

Hey,

How can I access previous saved data in the same page blueprint? For example I have a page blueprint where I can enter a value into a text field, hit save and then I want to access this value in a drop down or select field. I tried it with ‘data-options@’ and several API paths but I always get an empy field or an crikey :frowning:

2

@Paddi, If you want to access the value of another field in the theme’s blueprint, you can do the following:

blueprints.yaml

form:
  fields:
    mytext:
      type: text
      label: My Text
    myselect:
      type: select
      label: Show value of 'mytext' in options
      options:
        'an option': an option
      data-options@: '\Grav\Theme\MyTheme::getOptions'

mytheme.php

public static function getOptions()
{
    $grav = Grav::instance();
    $config = $grav['config'];
    $mytext = $config->get('theme.mytext');

    return ["$mytext" => $mytext];
}

Unfortunately, this approach doesn’t work as well as you might like:

  • The form needs to be saved twice before field ‘myselect’ will pickup the entered value of field ‘mytext’.
  • If you saved a value for ‘myselect’, then update the value for field ‘mytext’ and save again 2 times, Grav will throw a validation error on the ‘myselect’ field.

There may be better/easier solutions, but I’m not aware of them yet…

3

@anon76427325, thank you for your answer. I wrote theme blueprint but I meant page blueprint, sorry :confused: I will edit it above. Is there a similar approach to this with pages? I don’t know how to access the data of the currently edited page in the admin panel.

4

I have another page blueprint where I need something like this. The user should be able to pick a folder or parent page as source for an article list, hit save and then have the ability to choose which one of its children should bei highlighted or pinned. Sure I could just use two page fields with all pages in both but that would not be very user friendly. What is the right approach to this or is it simply impossible with input modules designed in yaml? This would be very limiting :frowning:

5

Ok, this “sounds” like it’s not possible :frowning: