Answers.Body: <p>According to Andris this is the expected behavior in this situation. The bug fix does make Craft work as intended but creates a slightly confusing workflow if you don't know what to expect. The good news is <em>my</em> expected behavior, which is to have assets available if {owner.slug} has been created in my assets folder already, is on the official list of features to implement. Well, assuming Andris doesn't go into a drunken stupor and forget to tell Brad or Brandon.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2023-08-18T13:18:43.870Z
Answers.Text: @Ian late to the party, but that seems to be the case yes, the "owner" is the entry in which the matrix field is used (not the author, as I'd assumed).  I'd been trying to use just `{slug}` as the asset location and getting an error when I tried to save an entry - using `{owner.slug}` now has it saving assets in a subfolder with the entry's slug
Answers.UserDisplayName: Roxy Walsh
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-24T15:39:24.647Z
Answers.Text: We talked about it :) We’re going to look into special-casing Matrix blocks.
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-24T17:33:12.367Z
Answers.Text: Hey @BrandonKelly I'm pretty confused on this issue. I was using a very similar setup to Stuarts - the differences were I had an asset folder setup on a Rackspace CDN and was using just {slug}. This was working properly before Craft 2.1.2566 and was uploading the files to my CDN appropriately... but after the update the files are going all over the place including places like **/cpresources/tempassets/field_67/** and when they do hit the CDN they're being uploaded to the root folder and not the one involving the {slug}. Could you shed a bit more light on what the expected behavior is?
Answers.UserDisplayName: Ian
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-24T17:42:21.583Z
Answers.Text: @Ian If it’s within a Matrix field you should be using `{owner.slug}` rather than `{slug}`, since the element that your Assets field is attached to is a Matrix block, not the entry, and Matrix blocks don’t have a slug. Calling `owner` will give you the parent element that the block is attached to (the entry, in most cases).
Answers.UserDisplayName: Brandon Kelly
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-24T17:45:30.610Z
Answers.Text: That did it. Does that mean that 'owner' pertains to the entry the Matrix is in?
Answers.UserDisplayName: Ian
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-07-24T14:49:39.543Z
Answers.LastActivityDate: 2014-07-24T14:49:39.543Z
Answers.UserDisplayName: Stuart McCoy
Body: <p>I have a Matrix field with four blocks currently, a header (text), explanation (rich text), slideshow (assets), and single image (assets). Both the slideshow and single image blocks have two fields, image and caption.</p>
  
  <p>The image field is the same in both with the exception of the slideshow assets field allows multiple images to be uploaded while the single is obviously limited to one. Both have "Restrict uploads to a single folder?" and "Restrict allowed file types?" checked and the latter only allows images. Both also have the same Asset Location selected and {owner.slug} as the path. Recently I discovered that I can no longer upload images to {owner.slug}, instead Craft is trying to upload images to /craft/storage/runtime/assets/tempuploads/field_##.</p>
  
  <p>I've checked file permissions for my assets directory and there shouldn't be a problem writing to it. I used to be able to create subfolders based on the entry slug and what's even more bizarre is that I can edit an existing single image or slideshow block image field and it will use/upload to the proper directory.</p>
  
  <p>Any ideas why it would stop doing this?</p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-23T21:06:28.957Z
Comments.Text: Hey Stuart, this may have been related to a bug we just fixed in today’s update. Can you try updating?
Comments.UserDisplayName: Brandon Kelly
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-07-24T04:06:25.883Z
Comments.Text: Updated and still having the same issue.
Comments.UserDisplayName: Stuart McCoy
Tags: <assets>
Title: Having problems with dynamic Asset folders and {owner.slug}
ThreadText: # Having problems with dynamic Asset folders and {owner.slug}
  
  (Asked by: username_0 on 2014-07-22)
  
  I have a Matrix field with four blocks currently, a header (text), explanation (rich text), slideshow (assets), and single image (assets). Both the slideshow and single image blocks have two fields, image and caption.
  
  The image field is the same in both with the exception of the slideshow assets field allows multiple images to be uploaded while the single is obviously limited to one. Both have "Restrict uploads to a single folder?" and "Restrict allowed file types?" checked and the latter only allows images. Both also have the same Asset Location selected and {owner.slug} as the path. Recently I discovered that I can no longer upload images to {owner.slug}, instead Craft is trying to upload images to /craft/storage/runtime/assets/tempuploads/field\_##.
  
  I've checked file permissions for my assets directory and there shouldn't be a problem writing to it. I used to be able to create subfolders based on the entry slug and what's even more bizarre is that I can edit an existing single image or slideshow block image field and it will use/upload to the proper directory.
  
  Any ideas why it would stop doing this?
  
  **Tags:** assets
  
  > **Comments:**
  > **username_1**: Hey username_0, this may have been related to a bug we just fixed in today’s update. Can you try updating?  
  > **username_0**: Updated and still having the same issue.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_0 on 2014-07-24. Score: 2 | Accepted answer
  
  According to Andris this is the expected behavior in this situation. The bug fix does make Craft work as intended but creates a slightly confusing workflow if you don't know what to expect. The good news is *my* expected behavior, which is to have assets available if {owner.slug} has been created in my assets folder already, is on the official list of features to implement. Well, assuming Andris doesn't go into a drunken stupor and forget to tell Brad or username_1.
  
  > **Comments:**
  > **username_1**: We talked about it :) We’re going to look into special-casing Matrix blocks.  
  > **username_3**: Hey @username_1 I'm pretty confused on this issue. I was using a very similar setup to Stuarts - the differences were I had an asset folder setup on a Rackspace CDN and was using just {slug}. This was working properly before Craft 2.1.2566 and was uploading the files to my CDN appropriately... but after the update the files are going all over the place including places like **/cpresources/tempassets/field_67/** and when they do hit the CDN they're being uploaded to the root folder and not the one involving the {slug}. Could you shed a bit more light on what the expected behavior is?  
  > **username_1**: @username_3 If it’s within a Matrix field you should be using `{owner.slug}` rather than `{slug}`, since the element that your Assets field is attached to is a Matrix block, not the entry, and Matrix blocks don’t have a slug. Calling `owner` will give you the parent element that the block is attached to (the entry, in most cases).  
  > **username_3**: That did it. Does that mean that 'owner' pertains to the entry the Matrix is in?  
  > **username_2**: @username_3 late to the party, but that seems to be the case yes, the "owner" is the entry in which the matrix field is used (not the author, as I'd assumed).  I'd been trying to use just `{slug}` as the asset location and getting an error when I tried to save an entry - using `{owner.slug}` now has it saving assets in a subfolder with the entry's slug  
  
  ---
  
  