Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Adding more consistent image functionality
Images — in contrast with files, links and articles — feel like 2nd class citizens. We routinely rely on plugins like the excellent upm_image to do our image handling. And from a programming viewpoint the fact there isn’t (yet) a $thisimage is a bit of a stumbling block in consistency.
————————————————————————————————————————————————————————————
IMPORTANT: This post is out of date. Please see the latest patch for download and detailed usage instructions
————————————————————————————————————————————————————————————
Since it’s a windy Sunday afternoon and I was at a loose end I’ve made the following changes to one of my stock 4.0.6 installs:
1) Added a global $thisimage which works the same way as $thisfile / $thislink.
2) Added functions:
- assert_image()
- imageFetchInfo() — works like filedownloadFetchInfo()
- image_format_info() — works like file_download_format_info() and adds the following to $thisimage:
- date (a unixified date offset)
thumbfilename
thumbwidth
thumbheight
thumbdims
filename
width
height
dims
- date (a unixified date offset)
The ‘dims’ entries are the HTML width="x" height="y" string. These image_format_info() names are not fixed, some may not be needed and most should probably be renamed to fit the TXP naming convention better. Ideas?
3) Added public tags:
<txp:image_list>...</txp:image_list>— with form capability<txp:image_name /><txp:image_category /><txp:image_url />— has an optional attribute to get the url of thethumb<txp:image_size />— defaults totype="width, height". Hasthumbattr to get the dimensions of the thumbnail andas_htmlto format the output as an HTML image string.joinallows you to change what characters get put between the width and height (unless as_html is used, because that always setsjoin=" ")<txp:image_alt /><txp:image_caption /><txp:image_author /><txp:image_date />— uses filedownloadFormatTime() because it can<txp:image_link>...</txp:image_link><txp:if_thumbnail>...</txp:if_thumbnail>— standard conditional that supports<txp:else />
<txp:image_id />
<txp:image_ext />
<txp:image_width />
<txp:image_height />
<txp:image_has_thumbnail />
4) Retrofitted <txp:image /> and <txp:thumbnail /> to work within a <txp:image_list /> form/container (i.e made them aware of $thisimage).
5) TODO, if this is an acceptable change to the core:
- add
error_image_contextto txp_lang - Possibly add an undeletable form in an image category instead of relying on the horrible defaults stolen from <txp:image_index />. Set the
formattr of image_list to this. - Perhaps as an alternative to a new image_list(), roll the functionality into image_index. Or perhaps deprecate
<txp:image_index />and/or<txp:image_display />as they are largely pants (!) - Look at article_image?
Here are the two unified diffs if anybody fancies giving this a whirl and supplying feedback on whether:
- This is useful (or not)
- I’ve missed anything
- It might stand a chance of sneaking into the core one day
txplib_misc v1
taghandlers v1
taghandlers v2
Any thoughts or otherwise on this…? Any more consolidation of tags anyone can see as useful?
[Edited to add: I’ve just spotted r2892 that removes the unused Fixed in v2$atts from functions. All the new single tags above should also have this treatment ]
Last edited by Bloke (2008-10-22 00:43:50)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Adding more consistent image functionality
image_format_info shouldn’t be needed. Al this info should be availably in the txp_image table.
I don’t think we should add that many tags. Most of them can probably be combined into one tag, using an attribute to select which type of information should be output.
<txp:image_has_thumbnail /> … shouldn’t that be an “if” tag (<txp:if_thumbnail />)?
- yes
- yes
- not in 4.0.7, but perhaps 4.0.8 (note: haven’t looked at the actual patch, just at what you posted here).
Offline
Re: Adding more consistent image functionality
ruud wrote:
image_format_info shouldn’t be needed. Al this info should be availably in the txp_image table.
Fine by me. Was just copying what was there already.
I don’t think we should add that many tags.
Again, fine by me. Ditto above. It’s a fine line between one tag and a selector attribute vs lots of dedicated tags. That balance is up to the development team to decide. I’ll take suggestions as to which ones should be combined. Perhaps wet has some ideas…?
<txp:image_has_thumbnail /> … shouldn’t that be an “if” tag (<txp:if_thumbnail />)?
Probably :-) Well spotted, thanks.
Last edited by Bloke (2008-06-22 19:00:19)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Adding more consistent image functionality
Perhaps combine <txp:image_ext /> and <txp:image_id /> into <txp:image_url />?
Offline
Re: Adding more consistent image functionality
ruud wrote:
Perhaps combine <txp:image_ext /> and <txp:image_id /> into <txp:image_url />?
Done (in my dev, not in the link in the first post… more to do yet). if_thumbnail() is also done instead of image_has_thumbnail.
I might also combine width and height into a <txp:image_size /> with an attribute, say type, that allows you to select one or more of width / height to output. Also maybe an as_html attribute to output it as "width="x" / height="y".
One thing I would like to see is the ability to get the thumbnail dimensions too, which is primarily my reasoning behind using image_format_info to add that info which isn’t in the DB. But if it can be rolled into a tag such as image_size (thumb=1 or 0?) then all the better. Will see what’s possible.
Last edited by Bloke (2008-06-22 19:23:29)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Adding more consistent image functionality
Updated the first post and uploaded v2 of the taghandlers diff which consolidates a few functions as ruud suggested. Any further thoughts from anyone, throw them this way.
The only thing I have found is that if a thumbnail doesn’t exist its width/height are set to "" (empty). Not sure of the correct way to handle this edge case; should the width/height be set to “0” instead? Anyone know? I can’t find any official word on whether it makes a difference.
It’s not a great hardship because <txp:if_thumbnail> can be used to circumvent displaying the info, but it’d be nice to do it “properly”.
Last edited by Bloke (2008-06-22 21:56:47)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Adding more consistent image functionality
Yesyesyesyes!!!
Keith
Blyth, Northumberland, England
Capture The Moment
Offline
Re: Adding more consistent image functionality
If a thumbnail doesn’t exist, it’s height and width have no meaning and shouldn’t be used, so it doesn’t matter what values height/width have in that situation.
Offline
Re: Adding more consistent image functionality
Nice work Stef. It would be great if this could make 4.0.8. :)
It’s been windy here too.
Last edited by thebombsite (2008-06-22 22:30:01)
Stuart
In a Time of Universal Deceit
Telling the Truth is Revolutionary.
Offline
Re: Adding more consistent image functionality
thebombsite wrote:
Nice work Stef. It would be great if this could make 4.0.8. :)
Thanks. Looks like I missed the boat for 4.0.7 :-( Shame because it would be mighty handy for my next major plugin, but these changes may need some heavy proving so it’s probably for the best.
For the most part I’ve copied existing functions from file_downloads / links and changed the references, so it should be a fairly solid base to work from. And I’ve only changed <txp:image /> and <txp:thumbnail /> the tiniest bit (4 lines each) to add a check to see if they’re being called from within the new <txp:image_list /> tag. Everything else is a new public-side tag so shouldn’t impact any of the existing core, nor anything on the admin side.
Anyone willing to give it a go and report any problems will be a massive help towards making this stable enough to consider for inclusion in the core. BTW, if anyone wants the complete taghandlers/txplib_misc.php (instead of the diff), e-mail me. Just remember it’s been written against a stock 4.0.6 so is probably not wise to replace any SVN version you may have.
And of course if you have any ideas for functionality/mods, let’s make a list and see if there’s anything missing or anything that should be taken out/consolidated. I would guess a good reference point is upm_image since that’s pretty much what everyone (aside from me, it seems) uses and is, from what I can gather, how images should be. Must get myself a copy and have a look one day.
It’s been windy here too.
Yeah, our poor vegetables have taken a real hammering today but I think they’ve mostly survived… I hope.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline
Re: Adding more consistent image functionality
ruud wrote:
I don’t think we should add that many tags. Most of them can probably be combined into one tag, using an attribute to select which type of information should be output.
Wouldn’t this be a little inconsistent with current way of retrieving content data, usually using specific tags for each chunk of data? At least, for files and links, which are a similar type of content inside TXP, there are tags for each kind of content.
I’m not against (I can’t be against, because I lack of proper knowledge to argue against) this “One tag to rule’em all” but I remember that sometime ago, someone suggested a similar tag (a hypotetical <txp:content />, if I’m not wrong) and Zem (or maybe Sencer) argued the idea.
Ok, I found the thread: it was mrdale who suggested it. I think that the end of that thread was the born of the first idea of a xpattern project (not the current one)
http://forum.textpattern.com/viewtopic.php?id=20598
Regarding this new tags suggested/created by Bloke, I think (as Bloke) that the “model” to follow is the one on upm_image.
Also, the txp:image_id could be useful for this kind of tricks, right?
Offline
Re: Adding more consistent image functionality
maniqui wrote:
Wouldn’t this be a little inconsistent with current way of retrieving content data, usually using specific tags for each chunk of data?
Perhaps, which is why I initially did a one-tag-per-function thing. But ruud is right that adding a tonne of tags doesn’t make sense when some can be consolidated.
The image_size one is a prime example. Why have individual tags for image width, image height, thumb width and thumb height when you mostly need the combined functionality? And on the odd occasions when you need the width and height individually you can either use the tag and get either the width or height, or use the same tag twice with a different selector. You have to use two tags anyway in the one-tag-per-thing model, and the number of times one will need individual width and height is probably fairly small so it’s a small price to pay.
Like I said earlier it’s a balancing act. At one extreme you have one-tag-for-everything with selectable types, at the other end of the spectrum you have one tag per entity. Somewhere will be a happy medium that delivers functionality without over-complicating things for users or bloating the core.
I think (as Bloke) that the “model” to follow is the one on upm_image.
Cool, do you have any specific knowledge of upm_image that is fundamentally useful, or a way in which upm_image is used that would benefit the core?
Also, the
txp:image_idcould be useful
Yes, I could probably live without the file extension but the image id should probably be reinstated. I’ll wait to see if anyone thinks there should be some more things for consolidation first. I mean, there could be a case for <txp:image_info type="blah" /> where ‘blah’ is one of alt, caption, id, name, ext… etc yet :-p It’s a case of how far we go with that idea.
What say the masses?
Last edited by Bloke (2008-06-23 08:07:37)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Offline