Batch-purging field on non-primary languages content files (programatically?)

I have a 3 languages site.

In this site there are many ‘artwork’ pages, with a structure field called ‘Elementdimensions’.

This is a non translatable field, so I always output whatever i in the primary lang. But for some reason the field is present BUT EMPTY in non-primary langs content txt files.

An example:

Title: Lorem Ipsum

----

Elementdimensions:

- 
  elementdescription: ""

----

…that ‘elementdescription’ is a writer subfield from the ‘Elementdimensions’ structure field, that for some reason, as I say above, shows… but empty.

So in the front, in non default langs, when o echo dimensions, they show empty.

I assume to fix this I have to remove this field from non-default langs content txt files, so it is not read as empty, and kirby falls back to default lang vale.

Now, what is the less painful way of doing this?

Thank you

The question is if the field remains empty when the pages are updated again, otherwise removing the field programmatically won’t help in the long run.

To null the field, you would loop through all pages in all non-default language and update the page, setting the structure field to null.

I did not understand what you meant here at first, but when I tried manually deleting the field from the content file, then updating any other field and saving, the field is again written on the content file, just as shown in my initial post.

Is this a (known?) bug related to the writer field within the structure?

At first glance I couldn’t find a bug report. Do structure fields with other subfields save as empty when translate option is set to false?

BTW: Which Kirby version?

Judging by the content file, I’d say this is only happening for/because of the writer subfield.

Kirby version is 3.7.2.1 I see some writer and structure bug fixes in the subsequent releases up to 3.9, but none related to this particular matter.

I am a bit scared of updating, because of the uuiid system, as I often share content between servers, and I did not understand fully what this implies.

Any recommendations?

Thanks

I’d disable uuids in config, then update and test.

Oh I see what is going on now

The structure field itself is NOT translate: false

All subfields are translate: false, EXCEPT for the writer field, which was the only subfield that could actually need translation, as it was a textual description, while all other subfields were numerical.

Something like:

test:
  type: structure
  fields:
    description:
      type: writer
    height:
      type: number
      translate: false
    width:
      type: number
      translate: false

With this setup, when I update any other field in the non-default language page, the structure field is written as empty.

I’ve tested the plainkit and this seems to be the default/intended behaviour. If a page has several translatable fields, as long as one of the fields is modified, all are written to content file, even if empty.

I am not sure what to do here. The description field is needed per each structure item. But this behaviour messes the output on page update.

Is my only solution to workaround it on the front ? Perhaps checking if the field is empty on the current language, and reverting to default language, as duplicating what Kirby usually does?

Thanks

After more thought, I think that this is flawed since the beggining.

Structure items are not supposed to be translated, as they don’t have correspondence on subsequent languages, as field themselves do.

It seems that updating a field in a non-default lang page that contains a translatable structure field, does not write the field as empty.

So I think I should set this structure field (and its subfields) as translatable, purge the non-default langs content files if necessary, and educate my users on the need to recreate each structure item manually if a translation is needed.

The main problem with the structure field is that number and order of items in one language may not be the same as in other languages and therefore as long as there are no items ids that might result in issues.

1 Like