Problem creating a page with prop $page->cover()

The CMS Questions
21

There must be something messed up, but I have no idea what or why. Are you using the latest Kirby version?

22

Yep. I could play around with versions … will report back.

Thanks very much Sonja for your effort.

23

Have you tried step by step debugging using Xdebug?

24

Mhh, no :frowning:

25

When moving the relevant content to a starterkit, the problem persists …

26

Just out of curiosity, what happens if you change your code to use a non existing blueprint? Like, substitute 'template' => 'book' with 'template' => 'ipromiseitsnotabook'.

Not sure if kirby 3 does this, but I have a suspect that the files field could interfere with the data you’re creating… Like “hmm… I don’t see a file with that name in this page, better just ignore that value :innocent:”

27

Well, it works! Now, explain yourself, Mister Wizard! How does one come up with this? :smile:

And how would this be fixed?

28

I’ve actually rewritten that reply like 2 times, each time by giving myself an answer to the question I had… So you’re seeing the result of a quite interesting, if I might say so, discussion with myself :stuck_out_tongue:

Actually I still have 2 suspects of what might cause it:

  1. the file doesn’t exist. Therefore when you write the “cover” data, the file must already be there. That could mean you either need to point to the ‘lesetipp’ page image, or, probably more resilient: create the page without cover, then copy the image file to the child, then update the child with the cover data.
  2. there’s something fishy about this: https://github.com/getkirby/kirby/blob/master/config/fields/files.php#L131 - but I don’t know kirby enough to know if that thing is run only from the panel or not - and if it’s always run if there are other things that are also always run. So, check first if suspect nr. 1 solves it :slight_smile:
29

After creating the page with empty cover field, I did this and it worked:

    foreach ($page->files() as $file) {
        $file->copy($child);
    }

    $child->update([
        'cover' => Data::encode($page->cover()->yaml(), 'yaml'),
    ]);
30

Seems that it’s the desired behaviour, so I won’t file a bug - what do you think?

31

I think it’s intended behavior, too. Since it protects you from writing “invalid data”.
But it’s also kind of unexpected and not documented. Maybe an issue would at least raise awareness that this needs documentation, or maybe we could change the API; I mean if there would be a documented “force data” attribute to the page create function, one that would ignore the blueprint and simply write the strings exactly like you give them to the function it would have been easier to debug.

32

I’ve already made a mental note to document this.

I think we need a way to override blueprint settings, anyway, not only for this issue, but also when a blueprint doesn’t allow editing fields or in general modifying data. I think there already is an issue somewhere.

2 Likes