what is the article_image field for?

NicolasGraph · 2015-06-19 07:11:18

Hello,
I know how to use the article image field but as it supports only one image, what does it really do that a custom field does not? In fact, for me, it’s often better to consider it as custom field as you can display several images with this kind of well know code: <txp:images id='<txp:custom_field name="article_image" />' />
So why this “custom field” is native? and restrictive?
Wouldn’t it be better to easily allow multiple images display with custom fields if the user has a need for?

philwareham · 2015-06-19 08:20:48

It’s for the sake of simplicity I guess. I quick way to assign a ‘hero’ image to an article. You are correct that there are other ways to achieve a similar result.

One of my plans around 4.6 (or maybe soon after) is to allow removal of certain fields in the write tab is a user doesn’t want to see/use them. That comes with the new custom fields feature, hopefully.

Bloke · 2015-06-19 08:20:49

NicolasGraph wrote #291675:

as it supports only one image, what does it really do that a custom field does not?

It is essentially a custom field but has some special properties. Firstly though, you can (as of Txp 4.3.0+) put multiple comma-separated image IDs in, and <txp:images /> will pick them up and display them as a gallery without any extra fuss.

The field is closely tied to the <txp:images> tag and in its native form will “just work” as far as it can to try and make sense of what you put in there. You can also put image names in, and full URLs to images (which may or may not be under the control of Textpattern’s Images panel). The <txp:article_image> tag (and to some extent <txp:images>) will try to figure it out, with varying degrees of success.

<txp:images id='<txp:custom_field name="article_image" />' />

That is equivalent to putting a comma-separated list of IDs in the field and doing this:

<txp:if_article_image>
   <txp:images />
</txp:if_article_image>

And of course you can use <txp:images> as a container to design your own gallery layouts. You have the flexibility to treat the article field as a regular custom field, as in your example, if you wish to do something a little out of the ordinary, but it’s usually not necessary.

If you’re only using one image, it is also tied to the <txp:article_image> tag such that it always tries to render a full <img> tag without any extra code on your part. Using a custom field you would have to construct the <img> tag manually, so it works as a shortcut.

Finally, and semantically, it’s also nice to have a dedicated image field for input instead of having to roll your own every time. We intend to enhance its appeal at some point with a better method for adding images to it, but that requires some changes to the Content->Images panel first (primarily a grid layout, which has been done rather nicely in the plugin tom_image_grid and I’d like to port into core at some point).

Does that help at all?

[Edit: one second too late!]

Last edited by Bloke (2015-06-19 08:21:42)

philwareham · 2015-06-19 08:22:03

Maybe th

Bloke wrote #291679:

Firstly though, you can (as of Txp 4.3.0+) put multiple image IDs in, comma-separated, and <txp:images /> will pick them up and display them as a gallery without any extra fuss.

The documentation needs to be updated to reflect this, it seems.

Bloke · 2015-06-19 08:32:53

philwareham wrote #291680:

The documentation needs to be updated to reflect this

Good catch. Done and done.

Edit: And done.

Last edited by Bloke (2015-06-19 08:53:24)

NicolasGraph · 2015-06-19 08:51:05

Bloke wrote #291679:

It is essentially a custom field but has some special properties. Firstly though, you can (as of Txp 4.3.0+) put multiple comma-separated image IDs in, and <txp:images /> will pick them up and display them as a gallery without any extra fuss.

Oh, I didn’t realised.

That is equivalent to putting a comma-separated list of IDs in the field and doing this:

<txp:if_article_image>...

Ok, shame on me; it even resolves a limit attribute problem I had…

Does that help at all?

Yes, as usual, but one day I’ll take my revenge and I’ll teach something to you! :)

philwareham wrote #291678:

It’s for the sake of simplicity I guess. I quick way to assign a ‘hero’ image to an article. You are correct that there are other ways to achieve a similar result.

One of my plans around 4.6 (or maybe soon after) is to allow removal of certain fields in the write tab is a user doesn’t want to see/use them. That comes with the new custom fields feature, hopefully.

Like bot_admin_write_tab? Good idea.

Thanks guys!

Last edited by NicolasGraph (2015-06-19 08:53:24)

Bloke · 2015-06-19 08:59:08

NicolasGraph wrote #291684:

it even resolves a limit attribute problem I had

Glad it helped.

One other nice thing about the <txp:images> tag is that you can use its offset attribute to slice up your article image list. I’ve done this on “news” websites. The first image is the “Hero” at the top of the article, displayed using:

<txp:images limit="1">
   <txp:article_image />
</txp:images>

and then later on I can drop in:

<txp:images offset="1" limit="3">
   <txp:thumbnail />
</txp:images>

to display up to three more supporting images, all taken from the single Article Image field. That’s a tad more laborious to achieve with tags-in-attributes using custom fields.

jstubbs · 2015-06-20 00:46:22

Entering a comma separated list of full URL’s to images in the article image field hasn’t worked for me in the past, maybe I need to try it again. Thanks for the tips Stef!

Bloke · 2015-06-21 15:27:21

jstubbs wrote #291722:

Entering a comma separated list of full URL’s to images in the article image field hasn’t worked for me in the past, maybe I need to try it again.

Not sure if it will. As far as I can remember, it only works with a list of IDs, but I can’t remember now. Since the field is only 255 chars, it’s not going to go very far if using full URLs anyway.

Destry · 2015-06-30 22:54:00

Bloke wrote #291685:

One other nice thing about the <txp:images> tag is that you can use its offset attribute to slice up your article image list. I’ve done this on “news” websites. The first image is the “Hero” at the top of the article, displayed using:

<txp:images limit="1">...

and then later on I can drop in:

<txp:images offset="1" limit="3">...

to display up to three more supporting images, all taken from the single Article Image field. That’s a tad more laborious to achieve with tags-in-attributes using custom fields.

Nice. That’s exactly the kind of example, nearly word for word, that should be in the respective Tag Reference page. If all examples in the tag pages had that kind of meaningful context/value, versus a lot of the arbitrary made-up stuff I see in the Reference, those pages would be dense and powerful.

I’m not suggesting you go through the book and address that in bulk, Ha!, but if everyone took the seconds to pull these things out of the forum when they recognize them and put them in place there, respectively… Man, mountains might move, or at least the help center’s overhead might go down as the service UX went up, saving the corporation money. ;)

hcgtv · 2015-06-30 23:15:01

Destry wrote #292409:

Nice. That’s exactly the kind of example, nearly word for word, that should be in the respective Tag Reference page.

What we could do is make it easier to contribute as we move forward, and the easiest way would be to build an admin side Send your tip to Textpattern button. Right there, in the backend, copy/paste the appropriate code from your Pages or Forms and write up a short explanation, send it away.

Make it feed a mailing list, whoever wants to can subscribe.

towndock · 2015-06-30 23:40:30

jstubbs wrote #291722:

Entering a comma separated list of full URL’s to images in the article image field hasn’t worked for me in the past, maybe I need to try it again.

As Stef points out, it is a list of ID’s that works. And it works great – have done it for years on many sites. Example – TXP used along with jquery Galleriffic.

Bloke · 2015-07-01 09:24:35

hcgtv wrote #292410:

Right there, in the backend, copy/paste the appropriate code from your Pages or Forms and write up a short explanation, send it away.

That’s not as crazy as it might seem at the outset. It’ll depend on how easy it ends up being to alter the documentation. The current wiki does give people the power to make changes directly, it’s just that comparatively few do, and there’s no nice link between the admin side and the docs. We want to change that.

We could perhaps use this opportunity to alter the tag builder and make it more useful. Instead of merely popping up that box to enter the fields, how about a link to the docs for that tag somewhere too, either alongside the tag in the builder list, or in the popup (whatever form that ultimately takes). Or even a link like the one you mention to submit a code example from that tag builder panel. It would mean opening up the Tag Builder first and finding the tag you want to add the example for, which is a minor annoyance. But a dedicated button in the UI for an incidental feature doesn’t feel like a good use of real estate. Might be wrong.

It’d be nice if it was possible for people to edit the docs themselves to add examples instead of sending to a moderated queue. The latter does give more control, but that’s not necessarily a good thing. Perhaps if it was easy to edit, the inclination might be there. My guess regarding the reason it’s not done much currently is because the entry barrier for mastering MediaWiki syntax is quite high. Looks a bit scary when you see the code behind it, although those familiar with Textile would probably be less intimidated.

When adding examples, there’s room for the little things helping out. Like if your example uses other tags, the list of “other tags used in this example” with links to the relevant tag doc pages can be scraped automatically, adi_form_links stylie, and added to the markup for you. I did wonder if an adi_form_links-esque plugin that scraped tags from your current Page/Form and showed you a list of those in use might be neat. The links would click through to the docs. The downside to that approach is that you only get to see the docs for tags you know about or are in use already, not those that you might want to use but don’t know about. That’s where the Tag Builder is handy, but as it’s not a complete tag reference, and the categorisation of tags isn’t always obvious, its appeal is diminished somewhat.

The idea of better docs integration is a core component of the admin-update branch and this kind of thing ties in nicely with that ethos, so let’s bust this topic into the Feature Requests area and hash out a good way to improve things for the entire admin-side help system. I have ideas, for one. Phil has ideas. I’m sure others have ideas too and it’d be good to get feedback in this area now, as work has begun on it.

I think Phil’s keen to use jQuery UI dialog boxes for help popups — ideally not modal so you can continue editing alongside. If nothing else, popping up the tag builder should allow you to reposition the cursor in the textarea and reinsert the current tag if necessary without having to close the tag builder panel, move the cursor and open it again.

For on-screen overview help (e.g. “The Pages panel allows you to…”), I quite like dockable drawers concept, but they take up more space and make the UI area smaller as you are viewing the docs. Plus they’re less flexible in terms of allowing you to position the popup out of the way while still referring to it while editing. But for a birds-eye overview of the entire function of the panel — like how it fits in with other building blocks — I think the drawer system that slides down to reveal that one piece of documentation from a little ‘help’ link near the menu bar (or something) is quite nice. But I ain’t no designer so I’ll leave that decision to those that have the chops, and will implement whatever is deemed necessary.

Bloke · 2015-07-01 09:41:20

Destry wrote #292409:

That’s exactly the kind of example, nearly word for word, that should be in the respective Tag Reference page.

Added, at least to the next gen documentation, not the current wiki.

hcgtv · 2015-07-01 12:11:20

Bloke wrote #292427:

We could perhaps use this opportunity to alter the tag builder and make it more useful. Instead of merely popping up that box to enter the fields, how about a link to the docs for that tag somewhere too, either alongside the tag in the builder list, or in the popup (whatever form that ultimately takes).

I have the Template Tags site open in a tab whenever I’m making changes to one of my Textpattern installs. I recently turned off comments at the tag site, comments were a way for users to contribute examples, but none were ever submitted in the almost 5 years the site has been running. My how time flies.

I would love popup help on a tag, maybe make it configurable so we can link to whatever version of the tag reference we would prefer.

Textpattern CMS support forum

#1 2015-06-19 07:11:18