`$page->update()` copies fields on non-default languages

I’m creating an importer plugin that updates pages based on input data. However, the update() method creates fills in the missing data from my input with empty values. That’s a problem because Kirby no longer uses the default language’s values and instead uses the current language’s now-existing-but-empty values.

For example, let’s say I have page.en.txt with the following:

Title: Hello World

----

Description: Testing

----

Color: #FACFAC

and

page.bg.txt with the following:

Title: Здравей Свят

If I open that page in Bulgarian, Kirby would use the values for Description and Color (which has translate: false) from page.en.txt since they are missing in page.bg.txt. If I update the values in page.en.txt, I’ll see those updated values in Bulgarian too because they’re still missing in page.bg.txt. That’s the expected behavior.

However, if I want to update the title in Bulgarian and run:

$page->update([
  'title' => 'Нов Свят'
], 'bg');

The title is correctly updated, but all other missing values are copied to page.bg.txt, including translate: false ones (like Color in this case). So the content of page.bg.txt would be:

Title: Нов Свят

----

Description: Testing

----

Color: #FACFAC

That’s a problem because of two things:

  1. If I update Description in English, the value in Bulgarian will not be up to date as expected since it’s not empty in page.bg.txt and Kirby would use that outdated value.
  2. The Color value has translate: false in the blueprint, which means it can no longer be changed in the panel. Since it exists in page.bg.txt, it also won’t be synced with the English value, meaning that the value will differ in both language, defeating the purpose of translate: false.

As a side note, even if there are missing fields in the main language file, the update() method creates them in the secondary language file with empty values. That’s a problem because of #2 up top.


I tried using $page->update() with its third parameter, validate, set to true, but I get the same result.

What is you set empty fields to null in your update call?

Tried that, same thing happens.

Could you create an issue on GitHub, please?

1 Like

Does that look good?

1 Like

This should now be fixed on the develop branch and will be in 3.1.3.