Combined use of article_image and images tags?

Destry · 2017-11-07 09:10:53

I’m working on images documentation for a client build, just to explain how things are done a bit and where they need to give their attention. At this point the entire site architecture, almost, is done so they only give their attention to the Image details area for all images in the Images panel — which is logical. That way they don’t need to fiddle in articles and forms too.

But, with the exception of one I can’t quite figure it…

The site has a Paypal integration for a small store, and there’s a fair amount of tricky conditionals and forms nesting. The form that defines the product profiles (which is called from individual product articles) currently outputs the following markup for the respective image (there’s other markup but I’m just showing the images part):

<figure><txp:article_image /><figcaption><txp:excerpt /></figcaption></figure>

The image IDs are in the article image fields, respectively.

That works. But to make this part consistent with the rest of the site (for client benefit), so that Textpattern is pulling a caption directly from the images’ Caption field, I need to figure out how to still indicate the ID set in the Article image field of the Write panel.

What I’m after is something like this, I think:

<figure><txp:images id="<txp:article_image"><img src="../images/<txp:image_info type="id" /><txp:image_info type="ext" />" /><figcaption><txp:image_info type="caption" /></figcaption></txp:images></figure>

But the problem I foresee on the surface (I haven’t actually tried that markup) is that the article_image (and image tag, for that matter) outputs the image path (i.e. src="/path/id.ext"). But I don’t need the whole path, just the ID value.

Anyone see what I’m getting at, and have another way, if possible?

If not, no big deal, this will just have to be an exception to the site, but it would be nice to always make image content come from image data, not dissociate it as an article field hack, which breaks concept of managing article data. Even I had to comb through my own architecture to remember what I had done because it wasn’t pulling what made sense. Now I’m trying to fix it a bit without rewriting the entire store architecture, which isn’t going to happen. ;)

jakob · 2017-11-07 09:23:14

Hi Destry,

You should be able to do that using the custom_field="article_image" workaround:

<figure>
  <txp:images id='<txp:custom_field name="article_image" />'>
    <img src="/images/<txp:image_info type="id" /><txp:image_info type="ext" />" />
    <figcaption><txp:image_info type="caption" /></figcaption>
  </txp:images>
</figure>

Is that what you’re looking for?

Destry · 2017-11-07 09:30:48

That looks like it could work. I’ll give it a try.

It’s too bad there’s not a way to just grab the ID value in text format, like <txp:article_image data="raw" />, or something. Then we would not have to use a separate article field with false semantic or custom anything; just the dedicated image field.

Destry · 2017-11-07 09:38:00

On second thought about this, Jakob, and I have no doubt your code works, but I’m just going to leave it as is, if there’s no “cleaner” way to grab the ID. The reason, besides already being done, is the way I have it now is not much different and uses less markup. Plus the client is more likely to see the excerpt field versus the custom field. Seems good enough.

Destry · 2017-11-07 09:39:45

Maybe. Hmm… I’ll stew on it. ;)

jakob · 2017-11-07 09:42:17

I think you know this, but just for clarification: you don’t need to set up a custom field for this; you can leave everything as is. Using <txp:custom_field name="article_image" /> just grabs the string from the existing article_image field like your raw suggestion. You’re probably right about the semantics.

I guess that the txp:article_image tag could also be expanded on with a form attribute at some time in the future to output the corresponding image in an alternative way, e.g. so that you could use it to build a figure tag or include multiple img src tags…

Destry · 2017-11-07 09:47:56

jakob wrote #307665:

I think you know this, but … Using <txp:custom_field name="article_image" /> just grabs the string from the existing article_image filed like your raw suggestion.

I did not know that. That’s a step better to the goal, and I will if fact go with it. Though, yeah, still a bit of a “workaround” at the atomic level, I think, which is a nicer way of saying it. ;)

Thanks, good man!

jakob · 2017-11-07 09:57:10

We talked a little about this whole area last weekend, e.g. multiple thumbnail sizes for srcset output, the possibility of using ImageMagick, combined with that the possibility of auto-generating mini thumbs for the forthcoming grid view, perhaps also integrating etc’s new multi-file upload… Image tag options have changed quite a bit in HTML over the past few years – with the addition of figure, picture, srcset – and at present you can only realise these in textpattern using plugins like smd_thumbnail or workaround forms.

Destry · 2017-11-07 10:43:31

Well, that’s pretty slick: <txp:custom_field name="article_image" />. I had no idea you could treat the article image field like a custom field. That would have never occurred to me.

I wonder if that’s in the docs. (I’ll have to look.)

Bloke · 2017-11-07 11:09:55

Destry wrote #307669:

I had no idea you could treat the article image field like a custom field… I wonder if that’s in the docs.

Shhhhhh, it’s a bug :-)

You can in fact treat any field in the textpattern table as a ‘custom field’ with that trick – even Body.

This undocumented bug is so insanely useful that it’d break pretty much every one of my sites if we close it, so I’m in no hurry to do so. In fact, I think I even retained the behaviour in the custom-fields branch on GitHub, and that uses separate tables for custom data.

Destry · 2017-11-07 11:59:19

Bloke wrote #307670:

Shhhhhh…This undocumented bug is so insanely useful that it’d break pretty much every one of my sites if we close it

lol. I already doc-ed it before seeing this. And it looks like not covering full scope of things either.

Still, I think if you’re in no hurry to un-bug it, it should be doc-ed somewhere.

I think a “Tip” doc like this in context of each field on the Write panel doc, which gives a real use case of tags (as I’ve done there) is better than a single blanket doc somewhere that vaguely explains the concept. Just sayin’.

Maybe you don’t even need to cover all the bases. I mean, I never needed it before today, and only on the image field.

Last edited by Destry (2017-11-07 12:02:25)

Bloke · 2017-11-07 14:07:30

Destry wrote #307672:

I already doc-ed it

Cool. The secret’s out :-)

The tip format works for me.

Textpattern CMS

Textpattern CMS support forum

#1 2017-11-07 09:10:53