1

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][206][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 tabId of 3275 as referenced in the craft_fieldlayoutfields table, has only 4 rows in that table (one for each field seen in the backend):

Screenshot of a MySQL table showing four rows with a tabId of 3275

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:

enter image description here

So at this point I have two theories about what happened:

  1. 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.
  2. Option 2: This site had, at one point, upwards of 15,000 rows in the craft_queue table, 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_queue wholesale. 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?

2

Craft doesn’t do any field operations in the queue, so it must be the first option.

Create a DB backup first, but it should be safe to delete the rows for fields that are not in the Matrix field’s layout. It also wouldn’t hurt to double-check the matrixcontent_modules table to make sure it doesn’t have columns for those fields.

Also worth noting, you can shrink the size of the table by going over all the sub-fields and checking their Column Type settings (under Advanced). If it’s possible to select smaller column types, you should do it.

  • Great, thanks so much! I'd love to see a more robust handling of stuck tasks someday. Perhaps if a task is still processing after X minutes (15?), move it to a "Stuck Tasks" list in the CP for reference and move on to the next one. – Sandwich Aug 20 '18 at 19:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.