Link node fields to arbitary link field

I would use Views for doing this – bringing in both fields and then doing a rewrite.

I guess this could be a part of generalized formatter in Panels (or even for the image field), but I don't see how it can be made generic enough without getting something similar to Views rewrites and stuff. So I would go for Views.

Second best suggestion is to write a custom formatter for the image field, and somehow make it aware of token replacement patterns, or just any link fields on the same node.

Oh, HERE's another solution.

Write a CTools relation plugin, that takes a string (including token replacement patterns) and returns a new string. That would basically do Views rewrites, without the need of the full Views framework.

@Itanglo
What about moving the Views re-write functionality down the stack, making it available to Panels as well?

#5: I don't know enough about the re-write functionality to say how possible this is, but in general I am all for it. Making components of a module accessible to other modules is goood.

@merlin How feasible would it be to expose the "re-write this field"-functionality to content panes in Panels?
Adding a content "before" another, hiding it as we exclude in Views, and then getting a token in a "later" content pane? Would it have performance consequences?

One thing I don't really like, and that I feel could speak in favor of the solution in #1, is that keeping this functionality within Views keeps a nice separating between what content we generate and were we place it.
Other comments on that?

Yes, and I suppose I agree. It probably wouldn't be very good for performance at all once you do it in a few places. On the other hand, the panel could render cache the entire View.

Mostly, I completely agree with you, it's just the part about duplicating Views functionlity I don't like. :)

@merlin, Please see my question in #7 :)

In Panels, instead of using rewriting, you use context + content types.

Data is loaded in context, output is in content types. If you need to do custom manipulation, then that should be done in the context itself, where possible. With entities and formatters I think a LOT of the things you might ordinarily do with rewriting can be accomplished this way.

You can also use custom field panes and tokens from contexts to do a lot of custom text with the tokens, especially now that field tokens are working via token.module. This is something that probably could use a little tutorial, in fact.

/me takes notes about the "tutorial" thing. It is now on my (pretty long) list.

#12: The issue there is that there may need to be a formatter that does what you want. Right now the entity pane can do the first part of that (image field with specific image style) but I don't believe the formatters currently allow linking to arbitrary paths.

Also, potentially a "custom" pane (in the UI) with token support enabled with something like this could do the trick:

<a href="%node:field-link">%node:field-image</a>

How about a formatter, that allows attaching to a text field and/or link field, which takes a "field-argument".

The formatter would then get the render of the "argument", and output l($argument, $link-field, HTML => true);

I'm not entirely sure how this would work myself, so I guess I'll just have to try. :)

http://drupal.org/project/semantic_panels has been built partially to fix this. Won't be fixed in Panels.

Better description.