Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-20T19:27:45.370Z
Answers.Text: 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.
Answers.UserDisplayName: Sandwich
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2018-08-20T18:46:43.677Z
Answers.LastActivityDate: 2018-08-20T18:46:43.677Z
Answers.UserDisplayName: Brandon Kelly
Body: <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>
  
Tags: <matrix><field><error-message><mysql>
Title: What could the possible causes be for a mismatch between `craft_fields` and `craft_fieldlayoutfields` MySQL tables?
ThreadText: # 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):
  
  [![Screenshot of a MySQL table showing four rows with a tabId of 3275](https://i.sstatic.net/qDtT3.png)](https://i.sstatic.net/qDtT3.png)
  
  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](https://i.sstatic.net/BhWUG.png)](https://i.sstatic.net/BhWUG.png)
  
  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?
  
  **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.  
  
  ---
  
  