Markdown frontmatter disappears after a threshold

Support Forms & Blueprints
1

Hello,
we have a quite large website for the ministry of education runing on Grav. We have a section with which displays and filters educational materials.

The filter website is a normal Grav Page. The content (educational materials) is embedded as a module. The module itself has its own blueprint. There the educational materials are added into the frontmatter using a list.

Everything worked fine until now. After the count of the items (educational materials) in the list exceeds a very specific threshold (exactly 163 items or 102kB), all of the following items disappear. When I edit items 1-163 and save, it all works fine. Once I add item 164, 165 and so on and save, these new items are not saved in the form or in the markdown. If I add these items manually into the frontmatter though, it works for even 200 items. Even when editing the frontmatter inside the admin panel. It seems that the issue lies somewhere within the blueprint.

So here’s my blueprint:

form:
  fields:
    tabs:
      type: tabs
      active: 1

      fields:
        bigbox:
          type: tab
          title: Veľký box
          fields:
            header.bigbox_type:
              type: toggle
              label: Typ veľkého boxu
              default: classic
              highlight: classic
              options:
                classic: Klasický
                tool: Nástrojový
            header.bigbox:
              name: bigbox
              type: list
              style: vertical
              collapsed: true 
              label: Veľký box
              fields:
                .heading:
                  type: text
                  label: Nadpis boxu
                .text:
                  type: editor
                  label: Popis boxu
                .image:
                  type: file
                  label: Ilustrácia
                  multiple: false
                  destination: 'self@'
                  filesize: 5
                  accept:
                    - image/*
                .tags:
                  type: selectize
                  label: Tagovanie
                  validate:
                    type: commalist
                .links:
                  type: list
                  label: Linky
                  fields:
                    .text:
                      type: text
                      label: Text linku
                    .href:
                      type: text
                      label: Link
                .button_text:
                  type: text
                  label: Text tlačidla
                .button_href:
                  type: text
                  label: Link tlačidla

Do you know, what could be causing a threshold like this emerging?

This section of the site is very active and we have many editors waiting for it to work so any help would be appreciated.

2

@Jakub_Nagy, Did some testing and in my case I saw rows in the list being dropped around 165.

Did a Google search and the first hit on stackoverflow hinted on max_input_vars

According the default configs for Apache:

max_input_vars 1000 PHP_INI_PERDIR Available as of PHP 5.3.9.

And I found a matching warning in my logfile ‘/var/log/apache2/error.log’:

[Wed Jun 24 20:11:12.433914 2020] [php7:notice] [pid 171] [client 127.0.0.1:51186] PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0, referer:

3

Thank you very much. It is working. I’m kind of suprised that a value like this is by default so low.

4

@Jakub_Nagy, While testing your form with ~1000 fields, Chrome nearly died. Although my laptop is not the fastest in town, it did made me wonder about the UX experience of your clients.

So, a default max of 1000 doesn’t sound that low to me…

5

Also true. When we were choosing the CMS platform for this website we had no idea that it will grow to be this size.

We already made some modifications to the admin panel to support dynamic forms. We are probably just going to modify the admin panel so these large sections could be accomodated on a database. The smaller text section could still be in markdowns. This way we could get the best of both a database and a flat file architecture approach. What do you think?