Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug: Using asset field with {slug} as upload location #22

Closed
johanneslamers opened this issue May 25, 2016 · 4 comments
Closed

Bug: Using asset field with {slug} as upload location #22

johanneslamers opened this issue May 25, 2016 · 4 comments
Milestone

Comments

@johanneslamers
Copy link

Hi Benjamin.

First of all, LOVE the plugin. It's how the Matrix should work by default.
But I'm having a error when uploading an asset file (S3) with a preset upload location with {slug} as variable. The error is only showing when using the field inside Neo. As standalone field it's uploading fine.

This is the error: Could not resolve the subpath “{slug}”.

screencapture-portfolio-craft-dev-admin-entries-case-4-925-1464182877977

@benjamminf
Copy link
Contributor

Cheers mate! At work at the moment, but I'll look into this when I get home. Thanks for the report.

@benjamminf
Copy link
Contributor

Damn it's been nearly a week already? Sorry I haven't gotten around to this yet, kept busy with another project which will be done with on Monday. I haven't had a chance to check this out yet but after this week I'll be on it.

@benjamminf
Copy link
Contributor

benjamminf commented Jun 10, 2016

Finally had a look through this, and I've discovered the problem. When parsing the target directory, it applies any {property} tags to the fields' containing element. An asset field added to an entry will reference the entry, but an asset field added to a Neo block will reference the block. This is why the instructions change slightly when adding an asset field to a Matrix block - it says to use {owner.slug} instead of {slug}.

This is a tough problem, though I might be able to trick asset fields into thinking they're owned by the Neo fields' containing element when parsing the directory.

In the meantime, you will have to create a duplicate field that uses {owner.slug} instead of {slug} for Neo block types.

@benjamminf benjamminf added this to the 1.3.0 milestone Jun 10, 2016
@benjamminf
Copy link
Contributor

benjamminf commented Jun 10, 2016

I've found that in order to properly fix this, I'd have to override a few hundred lines of core code and monkey patch the front-end Javascript, which is far from ideal.

Aside from creating a duplicate field just for Neo blocks, I've come up with another way of accomplishing this. Since you can use anything Twig provides in the asset fields directory fields, you can use this to your advantage.

To begin, {slug} can actually be replaced with {{ object.slug }}. This shows that we have the ability to use double brace tags, which means we can use logic. So the idea is to check to see if object is a Neo block, and if so, use object.owner.slug instead.

Bad news is, there's no built-in way to detect this. But since this is for a plugin, I've just implemented a Twig extension into Neo (to be available in the next release) that allows you to test if some value is a Neo block model. Now we can do this: {{ object is neoblock ? object.owner.slug : object.slug }}

Yes, it's more verbose than {slug}, but it's the cleanest solution possible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants