I'm debugging an Internal Server Error on a site developed by, well, not me. :p The site has an absolutely enormous Matrix field called "Modules", and the blocks in said field have so many fields that it reaches some sort of "65,536 char row limit" in the database when trying to add new fields.
Anyway, so the most recent block added to this giant Matrix field causes an internal server error whenever it gets added to an entry. The relevant
web.log line is:
2018-08-20 09:25:06 [127.0.0.1][h9dtcm3ad2nb50aie3m6t27be3][error][yii\base\Exception] yii\base\Exception: Invalid field handle: resource2Description in [MyProject]\vendor\craftcms\cms\src\base\Element.php:1932
This was odd, as the Matrix block in question didn't have a "Resource 2 Description" field in the backend. It did, however, have "Resource 1 Description" (and 3 other "Resource 1 ____" fields), and the development pattern I've seen in this site leads me to be nearly certain that at some point, someone tried to add or succeeded in adding a "Resource 2 Description" field (side note: consider this my +1 for Matrix-within-Matrix, and yes, I will be converting this morass to Super Table for the time being).
So this led me to poking around the database, trying to figure out why parts of Craft thought this field existed, but it wasn't being shown in the backend.
What I found was that the Matrix block in question, which has a
3275 as referenced in the
craft_fieldlayoutfields table, has only 4 rows in that table (one for each field seen in the backend):
However, when I looked up those field IDs in
craft_fields, I saw that they had a common
context column, of
matrixBlockType:78. Querying that table for all rows with that same
context, I found the mystery fields:
So at this point I have two theories about what happened:
- Option 1: Craft may have a bug of sorts where, if you try to add fields but hit that previously-mentioned 65,536-char row limit, the fields only get partially added to the database and you end up with a mismatch between tables.
- Option 2: This site had, at one point, upwards of 15,000 rows in the
craft_queuetable, due to some stuck 'Pending image transform' tasks that the developers had ignored during development. This was "resolved" by wiping out the contents of
craft_queuewholesale. I suspect that one of those tasks may have been something to do with saving or updating the fields in the Matrix block.
So the actual question is this: Which of those two scenarios (or some other cause I've not thought of) are more likely to result in mismatching database tables?
Bonus question at no extra charge: Which would be wiser, A) Manually (editing the database) "restoring" the missing rows for those fields in
craft_fieldlayoutfields, B) Manually deleting those "extra" rows in
craft_fields, or C) Trying to recreating those fields as normal, through the Craft backend?