Remove empty panel-fields from .txt

[sebsel]

Maybe this is considered a feature, instead of a bug, and maybe it's already discussed, but I couldn't find it.

When a page containing empty fields is saved in the panel, the field-name remains in the .txt file, like:

Field:

I would like it if the field disappears, like with $page->update(['field' => null]);, it saves storage for when you have a lot of sometimes-used-but-mostly-unused fields.

[lukasbestle]

It depends on the field. Fields like headline or info don't write anything at all, it's just the fields that normally write something but are currently empty.

So the difference is a return value of null vs. an empty string. I think we should keep this distinction in case there are any other supported storage systems in the future.

[sebsel]

This is just mentioned on the forums here.

[lukasbestle]

I do think that I understood you correctly. But there is still a distinction between null and an empty string.

I think it doesn't really make sense to store a lot of "optional" fields/page settings in fields anyway. It's probably better to store these in a single field in a YAML structure. Of course you would currently need to write a custom field for that.

We will keep this in mind, but right now this is a feature, not a bug.

[sebsel]

Well, every post on my website (https://seblog.nl/) is type entry. An entry with just text is a note, an entry with a photo is a photo and an entry with a checkin-field is a checkin. This is the way IndieWeb's h-entry works and thus also the way a Micropub request works. It made sense to let the fields just flow into the KirbyData .txt file.

But, that does mean I have a little list of fields that are not always there. Only 'published' and 'updated' are always filled, but even 'text' is empty for likes. I am not arguing that you should support my specific case, because I am fine with not using the panel, but this is the reason why I don't use it.

I see the difference between'' and null, which is what I am using to keep those fields gone. I'm just saying that it's a waist of disk space to write them out like that. But you can file that one on KirbyData too, if you want. :)

public function postType() {
  if($this->has('in_reply_to') and $this->has('text')
  and mb_strlen($this->text()->value()) < 10
  and Emoji\is_single_emoji($this->text()->value()))
                                return 'reacji';
  if($this->has('like_of'))     return 'like';
  if($this->has('bookmark_of')) return 'bookmark';
  if($this->has('tag_of'))      return 'tag';
  if($this->has('repost_of'))   return 'repost';
  if($this->has('read_of'))     return 'read';
  if($this->has('watch_of'))    return 'watch';
  if($this->has('checkin')
  and $this->has('photo'))      return 'photo-checkin';
  if($this->has('checkin'))     return 'checkin';
  if($this->has('invitee'))     return 'invitation';
  if($this->has('rsvp'))        return 'rsvp';
  if($this->has('in_reply_to')) return 'reply';
  if($this->type() == 'event')  return 'event';
  if($this->type() == 'review') return 'review';
  if($this->has('wrote'))       return 'wrote';
  if($this->has('video'))       return 'video';
  if($this->has('photo'))       return 'photo';
  if($this->has('name'))        return 'article';
  if($this->has('text'))        return 'note';
  return 'entry';
}

[lukasbestle]

Hm, but you don't have to use the same template for all of your h-entrys, do you? You can decide which template to use based on the Micropub request. Each blueprint then only needs the fields it uses.