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

#951566: FieldException: Attempt to create an instance of field comment_body on bundle comment_node_...

Common Problem

https://google.com/#q=site:drupal.org+Cannot+change+an+existing+field's+type

Issue fork drupal-2077163

Command icon 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:

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

robcolburn’s picture

Patch to provide more detail in FieldException error messages.

robcolburn’s picture

Status: Active » Needs review

Ping Drupal testing bot

robcolburn’s picture

Issue summary: View changes

Updated summary to use the Issue Summary Template

joachim’s picture

Status: Needs review » Needs work

This really improves DX with Features. Good idea.

However, I don't think these should be introducing a t(); format_string() should be used instead.

dcam’s picture

Issue tags: +Needs reroll, +Novice

@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.

joachim’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
3.19 KB

A 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.

Status: Needs review » Needs work

The last submitted patch, 5: 2077163-6.drupal.field-exception-messages.patch, failed testing.

Status: Needs work » Needs review
thursday_bw’s picture

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

grep -r "Attempt to create a field.*not exist" .
./web/core/modules/field/src/Entity/FieldConfig.php:        throw new FieldException("Attempt to create a field {$this->field_name} that does not exist on entity type {$this->entity_type}.");
./drupal-8-blank/web/core/modules/field/src/Entity/FieldConfig.php:        throw new FieldException("Attempt to create a field {$this->field_name} that does not exist on entity type {$this->entity_type}.");

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:

In this specific case I think you're missing field.storage.node.body and it is trying to create field.field.node.(something).body

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 running drush cim resolved the error in my case.

thursday_bw’s picture

Some 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.

thursday_bw’s picture

oops: related issue: #951566