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

<p>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 <code>matrixcontent_modules</code> table to make sure it doesn’t have columns for those fields.</p>

<p>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.</p>

CC BY-SA 4.0
2018-08-20T19:27:45.370Z
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
CC BY-SA 4.0
2018-08-20T18:46:43.677Z
2018-08-20T18:46:43.677Z
Brandon Kelly
<p>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.</p>

<p>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 <code>web.log</code> line is:</p>

<pre><code>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
</code></pre>

<p>This was odd, as the Matrix block in question didn't <em>have</em> a "Resource 2 Description" field in the backend. It <em>did</em>, 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).</p>

<p>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.</p>

<p>What I found was that the Matrix block in question, which has a <code>tabId</code> of <code>3275</code> as referenced in the <code>craft_fieldlayoutfields</code> table, has only 4 rows in that table (one for each field seen in the backend):</p>

<p><a href="https://i.sstatic.net/qDtT3.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/qDtT3.png" alt="Screenshot of a MySQL table showing four rows with a tabId of 3275"></a></p>

<p>However, when I looked up those field IDs in <code>craft_fields</code>, I saw that they had a common <code>context</code> column, of <code>matrixBlockType:78</code>. Querying that table for all rows with that same <code>context</code>, I found the mystery fields:</p>

<p><a href="https://i.sstatic.net/BhWUG.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/BhWUG.png" alt="enter image description here"></a></p>

<p>So at this point I have two theories about what happened:</p>

<ol>
<li>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.</li>
<li>Option 2: This site had, at one point, upwards of 15,000 rows in the <code>craft_queue</code> 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 <code>craft_queue</code> wholesale. I suspect that one of those tasks may have been something to do with saving or updating the fields in the Matrix block.</li>
</ol>

<p>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?</p>

<p>Bonus question at no extra charge: Which would be wiser, A) Manually (editing the database) "restoring" the missing rows for those fields in <code>craft_fieldlayoutfields</code>, B) Manually deleting those "extra" rows in <code>craft_fields</code>, or C) Trying to recreating those fields as normal, through the Craft backend?</p>

<matrix><field><error-message><mysql>
What could the possible causes be for a mismatch between `craft_fields` and `craft_fieldlayoutfields` MySQL tables?
# What could the possible causes be for a mismatch between `craft_fields` and `craft_fieldlayoutfields` MySQL tables?

(Asked by: username_0 on 2018-08-20)

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):

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_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?

**Tags:** matrix, field, error-message, mysql

---

## 1 answers

### Answer by username_1 on 2018-08-20. Score: 2 | Accepted answer

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.

> **Comments:**
> **username_0**: 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.  

---

