Problem/Motivation

When creating a new image field, you can select a default image for the global field settings. Upon saving, you then see another default image widget that applies only to the field instance. It can be confusing as it might seem that the default image you set was not saved.

To reproduce:

  1. Install Drupal
  2. Add a new image field to a content type
  3. In the first screen, select a default image and save
  4. On the next screen, see there is an empty default image widget

Proposed resolution

Based on #17, update the wording of the text to make it more obvious that one is the global field setting and one is the instance setting.

The wording of the field settings note is "These settings apply to the [field name] field everywhere it is used. These settings impact the way that data is stored in the database and cannot be changed once data has been created."

And on the edit settings "If no image is uploaded, this image will be shown on display and will override the field's default image."

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

Confirming that you cannot remove/change the default image for a field after creation, attempting to resolve.

tlherr’s picture

Status: Active » Needs review
FileSize
601 bytes

File Ids were not being cleared for non multiple file fields. Patch removes relevant file ID.

Anonymous’s picture

Component: field system » file system
Status: Needs review » Reviewed & tested by the community

Appears to solve issue and allows changing default image. Impacts the file field in general.

Anonymous’s picture

Status: Reviewed & tested by the community » Needs review

Setting back to needs review to get some more eyes on it

aspilicious’s picture

We need a test.

Anonymous’s picture

Needs further investigation.

Something else is happening with regards to the the managed_file field used. Image/file fields run through the same submit callback and don't exhibit the same issue.

harry99’s picture

I tried to work out few more things in details about this issue.

When you create new content types for "image", you get two options for choosing upload destination 1. Public flies 2. Private flies.

On FIELD SETTINGS we get option to choose default image. The text below says: "If no image is uploaded, this image will be shown on display."
Next, moving on EDIT menu default image box appears empty, Here text below says: "If no image is uploaded, this image will be shown on display and will override the field's default image." So, we really don't need to upload the same image here even though its empty and it will still display the same image which we uploaded on FIELD SETTINGS after you create content. However, the words had been used to explain under the box are very confusing!!

Second thing is, try choosing different image on EDIT menu than it will override the image we uploaded on FIELD SETTINGS while creating image content and it will display the image we have chosen on EDIT menu.

harry99’s picture

Choosing upload destination as Public Flies.
Everything seems working fine either choosing different image on EDIT menu or leaving blank or choosing same image as FIELD SETTINGS.
However, after uploading image either place it's not letting remove it!

Choosing upload destination as Private Flies.
Here, image does not show up on the page after creating content type. Even though choosing same image or different or not choosing any image on EDIT menu.
Once, image is uploaded, it's not letting it remove from EDIT menu or FIELD SETTINGS.

harry99’s picture

After creating & publishing content type with upload destination as Private Files, image will not be displayed on content page.

1. On content published page try copying broken image URL.
2. Paste that URL on new tab and you will get message saying ACCESS DENIED

This message will pop up even though you are logged in as ADMIN.!!

I think image is uploaded on private files but for some reason its not accessible.

I tried this same thing with iTerm to see if image file is there or not. Same thing happened it shows you image is there but will get message saying Permission Denied.!! to access!

So, I think default image filed is working but the real issue is something else.

swentel’s picture

Component: file system » image.module
Status: Needs review » Needs work

This is indeed a weird situation. The default image on the 'Edit' tab work fine. But you can also upload a default one on the 'Field settings' tab. Weird, we should fix that :)

swentel’s picture

Title: Default image field not working when creating content type » Default image upload on edit and field settings tab is confusing and redundant
YesCT’s picture

Iirc, one sets the gloval default for all field instances, the other sets a default for that particular filed instance.

Next steps:
Verify and Summarize the current behavior in the issue summary with exact steps to reproduce for the various situations.
Suggest what the behavior *should* be.

claudiu.cristea’s picture

Well, the original issue is talking about something totally different from the last part.

For the behavior described by @hardik.patel99 in #7, #8, #9 I opened #2107455: Image field default value not shown when upload destination set to private file storage.

swentel’s picture

Title: Default image upload on edit and field settings tab is confusing and redundant » Default image upload on edit and field settings tab is confusing

Renaming title also a bit, it's probably not redundant, but still confusing I guess.

ifrik’s picture

I came across this problem while writing the hook_help text #2091337: Update hook_help for Image module - and I'm not sure what the functionality is supposed to be.
In any case it is currently a usability bug that you the site administrator can set two Default images, one of which overwriting the other.

ifrik’s picture

I forgot to add the description of how you can currently add two different default images:
In my current D8 installation, I can add a default image on the "Field settings" tab - and it does not show up on the "Edit" tab. Instead I can either leave the default image on the edit tab blank (then it displays the one from the field settings tab with new content) - or I can add a second default image that is then displayed.
If I re-use the image field then it takes default image on the Field settings page, but not the one on the Edit page.

jhodgdon’s picture

I don't think this is so bad now.

When you create an Image field, there is still a setting for the Default Image.

Then in the instance settings (or whatever they are called, the specific settings that say "these are the settings for this content type", it says:

If no image is uploaded, this image will be shown on display and will override the field's default image.

So... This text is not all that prominent and maybe it's not all that clear, but probably all we would need to do here is to update this text and make it more obvious... but at least the explanation is there.

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.6 was released on February 1, 2017 and is the final full bugfix release for the Drupal 8.2.x series. Drupal 8.2.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.3.0 on April 5, 2017. (Drupal 8.3.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.3.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.6 was released on August 2, 2017 and is the final full bugfix release for the Drupal 8.3.x series. Drupal 8.3.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.4.0 on October 4, 2017. (Drupal 8.4.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.4.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

Bug reports should be targeted against the 8.5.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

Bug reports should be targeted against the 8.6.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.8.x-dev

Drupal 8.6.x will not receive any further development aside from security fixes. Bug reports should be targeted against the 8.8.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.9.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

pameeela’s picture

Version: 8.9.x-dev » 9.1.x-dev
Issue tags: -Needs issue summary update +Bug Smash Initiative

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

larowlan’s picture

Status: Needs work » Closed (works as designed)

On the basis of #17 and #27 this sounds like it is done now