[5.x]: Matrix in Matrix reaching max input vars quickly

[Mathias-Syversen]

What happened?

I have been testing the "matrix in matrix" solution in Craft 5 for a while now, and I've noticed that I reach the max input vars of 1000 really quickly.

For my test I have a few different entry types and matrix fields:

• Section
• • Column
• • • Image, Text

Creating one section, with 3 columns inside, with one image and text block in each column, so a total of 9 blocks, already hits max input vars.

I might be mistaken, but wasn't the entrification of matrix fields partly to avoid saving huge payloads (neo, supertable), and to offset the saving to each individual entry instead of saving the whole "field"?

Writing something in one text field now turns the whole page blue with "changes" and I get told I have hit max input vars.

I know one can up this limit, and we have it higher in production, but at the rate this is growing atm, we would have to have 50 - 100 000 vars limit for a large page with a lot of content..

Craft CMS version

5 Alpha 11

PHP version

8.2

Operating system and version

MacOS

Database type and version

MariaDB

Image driver and version

No response

Installed plugins and versions

-

[davidwebca]

I've had this happen pretty quickly even when there aren't a lot of fields added. I've raised the limit with php.ini, but it the saving action was chunked in different requests, maybe it would help.

[brandonkelly]

I might be mistaken, but wasn't the entrification of matrix fields partly to avoid saving huge payloads (neo, supertable), and to offset the saving to each individual entry instead of saving the whole "field"?

Yes, but that only applies to the cards and element index Matrix view modes. Inline-editable blocks will be roughly the same as submitting via Matrix + Super Table/Neo in Craft 4.

[Mathias-Syversen]

Craft 5 / Matrix in Matrix seems to generate a lot more variables than Neo atm. Some of our admittedly behemoth site builders does not reach 3000, and thats with 5-10 sections, with lots of columns and content types.

If we use the card view, editing a text block takes us 3 layers deep, and to edit the image next to it, you need to go back and then open another drawer. The user experience here is horrible.

And this is just with a couple of test blocks, trying to edit any actual content would be a nightmare..

The page builder we usually set up for larger sites is not that complex, its usually a section with settings for background, text color and padding, with column blocks that has settings for width so we can stack them besides each other, and then all the usual content blocks inside the columns, like image, text, map, forms, videos, contacts etc.

[thupsi]

Hello @Mathias-Syversen, just wanted to add my 2 cents seeing your screenshot above: You don't have to use the card view for ALL your content levels, and indeed doing so results in a sub-optimal AX. You could configure sections as inline blocks, columns as cards, and everything inside columns as inline blocks.

So, this way, you would only need to go 1 layer deep to edit your text field and in the same layer you would see end edit your image. And with each save only the current column would be saved, not the whole page.

[Mathias-Syversen]

Hello @Mathias-Syversen, just wanted to add my 2 cents seeing your screenshot above: You don't have to use the card view for ALL your content levels, and indeed doing so results in a sub-optimal AX. You could configure sections as inline blocks, columns as cards, and everything inside columns as inline blocks.

So, this way, you would only need to go 1 layer deep to edit your text field and in the same layer you would see end edit your image. And with each save only the current column would be saved, not the whole page.

Card views does not show field values for "blocks" inside a matrix field, so this solution ends up with a list of columns, with no way of knowing where the content you want to edit is (see pictures). Unusable for any user, unless you want to open the slideout for every column and check if that is the right one.

Todays problem with neo and how it saves data really shows if you use it for more complex page builders, something the entrification of matrix blocks could solve, but with the current itteration, the only use-case for the card views is when its for single layer elements, for example contacts or articles. For any nested fields, the only user friendly way is to use inline editable blocks, and that is also the only mode without any of the performance enhancements..

[thupsi]

Yes, this is a slightly different issue. I have faced it too in some quick experiments. From the top of my head, I can think of a few different ways to solve this:

• Have a title field in each column, even if only for the CP, so that can be used in the card preview.
• Use a preparse field to generate a usable preview for the column card.
• If some fields are used in most cases (like, title or text) put them direclty in the column, not in a martix.
• Have some ready-made column types with specific field layouts for the most common cases.
• Ask P&T for a way to bubble-up content from a matrix block to the parent card :)

In general though, even with some shortcomings that I hope will be ironed-out in coming releases, I strongly prefer the card and slide-out paradigm vs nested inline blocks. That's a personal preference though, based on my own projects and way of modelling content.

Having said that, since inline nested blocks seem "heavier" than Neo/Supert-table (haven't tested myself), I think that's something worth investigating for sure!

[thupsi]

Another idea: Since matrix blocks are now entries, you could even have special admin links in the front end (visible also in your preview pane) that go directly to the specific block in the CP! Not exaclty what you are asking, just brainstorming here!

[Mathias-Syversen]

Another idea: Since matrix blocks are now entries, you could even have special admin links in the front end (visible also in your preview pane) that go directly to the specific block in the CP! Not exaclty what you are asking, just brainstorming here!

Having an api endpoint to ping with block / entry ID and get the js / html for the slideout frontend would be nice yes.

[Mathias-Syversen]

Yes, this is a slightly different issue. I have faced it too in some quick experiments. From the top of my head, I can think of a few different ways to solve this:

• Have a title field in each column, even if only for the CP, so that can be used in the card preview.
• Use a preparse field to generate a usable preview for the column card.
• If some fields are used in most cases (like, title or text) put them direclty in the column, not in a martix.
• Have some ready-made column types with specific field layouts for the most common cases.
• Ask P&T for a way to bubble-up content from a matrix block to the parent card :)

In general though, even with some shortcomings that I hope will be ironed-out in coming releases, I strongly prefer the card and slide-out paradigm vs nested inline blocks. That's a personal preference though, based on my own projects and way of modelling content.

Having said that, since inline nested blocks seem "heavier" than Neo/Supert-table (haven't tested myself), I think that's something worth investigating for sure!

All of these examples still require the user to click extra times and navigate between loads of slide outs for simple text updates. Its not really user friendly, and a far way from what almost every other cms has now; inline front-end editing.

I like the block structure with matrix / neo, but having to explain it to the customer every time they want to do a simple text or image change is frustrating, and I think we forget that for us, who created and modelled the blocks, it makes total sense, but for a user that just wants to update that piece of content, navigating all these blocks and slideouts is challenging.

Making simpler page builders is something we always consider, and we try to make easier ones with less layers for the simpler sites. But then theres alway the question "Can i put that next to an image" or can i do this or that. I can understand that for someone who is used to a front-end WYSIWYG editor where you simply click whatever you want to edit, or drag the image to the right or left side of some text seems way easier. In the real world, sites can have a lot of content, and hard coding templates is something I stopped doing long ago, as there is always the "can you add this" or "move that".

Personally I would prefer something in the middle, where you have the front-end editing capability, but with less options than some of the competitors, like UXBlocks or whatever from wordpress, where you can quickly ruin the whole layout, and have options and buttons for every minor detail. The ability to click a "block" front-end and edit it in a slideout, and the ability to drag "blocks" around on the front-end to re-arrange them in the matrix field would be a good start.

[brandonkelly]

Craft 5 / Matrix in Matrix seems to generate a lot more variables than Neo atm.

That should not have been the case. I just looked into it and found that the element edit forms could submit duplicate input values, which wouldn’t break anything in PHP, but could cause you to hit the max_input_vars a lot quicker.

If you’d like to test and see if the fix helps you, change your craftcms/cms requirement in composer.json to 5.0.x-dev as 5.0.0-alpha.12 and run composer update.

Regarding front-end editing, we do have some ideas there, which we plan to explore in a 5.x release.

[alexanderbuergin]

Regarding front-end editing, we do have some ideas there, which we plan to explore in a 5.x release.

Craft CMS 5 will offer fornt-end editing? Are there already concepts for this?