When using the retroactive updating (which, I must say is fantastic if it wasn't for the side-effects), FFP resets that content type's placement and formatting of the file field. So, if you are using an image and have it set up and positioned just where you need it to be, once you use FFP to 'retroactive update' its file location, it alters the relative position of that image field and removes all the formatting you had set for it.

Steps to reproduce:

  1. Install Drupal 7.28 with standard profile
  2. Download, install and enable FileField Paths 7.x-1.0-beta4, Token 7.x-1.5
  3. Alter the Display of an image field at /admin/structure/types/manage/article/display:
    • Here, an Article's Default View mode is set to show image styles as: Image style: Large (480x480). Change those settings to anything else. I used Thumbnail (100 x 100), linking the image to the content just for the sake of setting to something else than what is default.
    • (Optional but part of the bug) Change the field order too, swapping its position with the Tags field, so the order of fields is: Body, Image, Tags.
  4. Create at least one article node, uploading an image. Note that file path has been untouched and is set to its default (but it doesn't matter - if you had set this to something else, the bug still occurs). The image should end up in /sites/default/files/field/image. View your node to see what it looks like and check that the image is linked when you hover over it.
  5. Now change the Image path by going to manage the image field for an Article (admin/structure/types/manage/article/fields/field_image) and open the File Field Path Settings dropdown.
    • Change the file path to something else. I set mine to: uploads/[node:content-type]. Check the 'Retroactive update' option.
    • Click on 'Save Settings' at the bottom of this page and view your content. Bang! Although FFP has correctly moved the file to sites/default/files/uploads/Article (sidenote to themers: you need the Transliteration module to keep files and directories lowercase) unfortunately, it has also reset the positioning of the image field and removed it's formatting. This happens to any field that is involved with files, so it could be an attachments field, etc.
CommentFileSizeAuthor
#4 field-settings-lost.patch979 bytesdavid_garcia

Comments

rajmataj’s picture

Issue summary: View changes

Specified versions of involved modules.

fxfx’s picture

I can confirm the bug, i was thinking was a display suit bug. All field display settings are erased after using retroactive update

david_garcia’s picture

I can confirm this is happening with latest dev.

david_garcia’s picture

Priority: Major » Critical
Status: Active » Needs review
StatusFileSize
new979 bytes

Field instance settings are lost when doing retroactive updates because field instance settings are being updated without fully populating the settings prior to saving. More details in that patch comments.

Attached patch fully loads field instance configuration prior to update.

david_garcia’s picture

Title: File Field Paths resets Image field placement and formatting after retroactive update » File Field Paths partially resets Field Settings (ex. placement and formatting) after retroactive update

Changed issue Title

gomez_in_the_south’s picture

I was also having the same problem as described, including with the latest dev.

The one line addition in david_garcias patch fixed the problem for me. Thanks David. It would be great to see this patch added to the latest dev version, if not a new beta release.

dxx’s picture

Good with current --dev version, thanks!

rovo’s picture

I can confirm this bug is still occurring as of 7.x-1.0-beta4+5-dev.

  • Deciphered committed ad0c355 on 7.x-1.x
    #2276435 by Decipherd, david_garcia, rajmataj: Fixed issue with...
deciphered’s picture

Status: Needs review » Fixed

Thanks for the extremely well detailed report and patch, appreciate the effort.

Ultimately I opted for an alternative location for the fix to potentially increase performance.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.