Updated: Comment #1
Problem/Motivation
Imagine you're daily routine building a Drupal site with a team. You pull down upstream changes, and likely do a features-revert-all to get your local instances synced up.
Now imagine (as can happen frequently for me), another developer made a change that breaks your build. Perhaps, the developer Featurized a change to a field type. Now "drush" is sad, and all you know is that a field type changed… somewhere because it changed type -- off to the git logs you go.
Proposed resolution
Well, we can do a little bit better than that. Along with saying a Field broke, we can say which Field broke, and what the attempted change was from/to. You'll still likely need to dig, but now at least you've got a hint where to dig. Fortunately, the data is already there to support this, we just need to change the error messages to include it.
Remaining tasks
1. The patch is needs review.
…
User interface changes
The proposed patch changes the output of some error messages.
API changes
This changes error messages in the core Field module.
Before:
[error] Cannot change an existing field's type.
After:
[error] Attempt to change type of an existing field my_cats from list_integer to list_text
Related Issues
Common Problem
https://google.com/#q=site:drupal.org+Cannot+change+an+existing+field's+type
Comment | File | Size | Author |
---|---|---|---|
#5 | 2077163-6.drupal.field-exception-messages.patch | 3.19 KB | joachim |
#1 | fieldexception-messages-2077163-1.patch | 4.36 KB | robcolburn |
Issue fork drupal-2077163
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #1
robcolburn CreditAttribution: robcolburn commentedPatch to provide more detail in FieldException error messages.
Comment #2
robcolburn CreditAttribution: robcolburn commentedPing Drupal testing bot
Comment #2.0
robcolburn CreditAttribution: robcolburn commentedUpdated summary to use the Issue Summary Template
Comment #3
joachim CreditAttribution: joachim commentedThis really improves DX with Features. Good idea.
However, I don't think these should be introducing a t(); format_string() should be used instead.
Comment #4
dcam CreditAttribution: dcam commented@joachim is right. We no longer use t() in exception messages.
This patch no longer applies. I know that's at least partly because #1231710: Field exceptions should return the name of the field that has exceptions already made these changes to a couple of the messages. This issue really should have been closed as a duplicate and had its scope added into the other issue. Since the other issue is committed and closed, this one can move forward.
It may not be best to do a straight reroll. Anyone working on this patch should check D8 and make D7's exception messages match what was done there, if possible.
Comment #5
joachim CreditAttribution: joachim commentedA few of the changes in the earlier patch here appear to have already been dealt with in other issues.
Here's a reroll with just the changes that are still needed.
Comment #8
thursday_bw CreditAttribution: thursday_bw as a volunteer commentedWas thinking of opening a ticket, the title of this one matches what I'd put on the other issue. Please comment if you think this should be it's own issue.
Talking D8 now, but same module and same description, just a different error specifically.
The error as generated:
"Attempt to create a field body that does not exist on entity type node."
Grepping for the error in question elicits this:
The has at least 3 possible interpretations. And it's wording is contradictory as one can't create something that already exists, that's called acquisition, so how is creating something that doesn't exist possibly an error?
I had a quick chat with @larowlan in slack #australia-nz and he suggests:
If that's correct then that could help us come up with a clearer error message.
In case someone happens to search that error and land on this page, in my case the error occured during a configuration import on a fresh site install via
drush cim
. Simply runningdrush cim
resolved the error in my case.Comment #9
thursday_bw CreditAttribution: thursday_bw as a volunteer commentedSome related in the wild links on the internet where others have come across the same error and have failed to interpret it's meaning:
attempt-to-create-a-field-body-that-does-not-exist-on-entity-type-node
drupal-8-upgrade-error-attempt-to-create-a-field-body-that... there is no suggested solution on this one though.
And a related issue: #951566
So there are plenty of answers on the internet for "how to make this error go away", with a clearer error it increases the chances of being able discern the solution directly.
Comment #10
thursday_bw CreditAttribution: thursday_bw as a volunteer commentedoops: related issue: #951566