Adding more consistent image functionality

Zanza · 2008-06-23 19:48:09

It’s not better. But I couldn’t use it because my plugin use a single tag to output different things in one (image, title, caption…). So I couldn’t simply wrap that in another tag.

Back to my request, 2 questions:

Are you saying that wrap the text in another tag that textilize it is a better way to textilize pieces of text like image captions or link descriptions?
If yes, why not provide such a tag as a standard txp tag rather than a separate plugin?

Despite of the method, I simply feel that some pieces of texts could be displayed both as simple texts and both with some html structuring. It depends on some circumstances. So I think that an option or a tag (you decide) may be provided.

wet · 2008-06-23 20:19:20

Zanza wrote:

Are you saying that wrap the text in another tag that textilize it is a better way to textilize pieces of text like image captions or link descriptions?

I think so, it avoids a lot of repeat code in each single taghandler funtion to handle said attribute.

If yes, why not provide such a tag as a standard txp tag rather than a separate plugin?

A plugin is just as fine. I haven’t noticed a swamp of feature requests for a built-in tag so far, so I think demand is low.

kemie · 2008-06-24 10:52:44

kemie drools at the thought of getting her hands on this txp image goodness.

Zanza · 2008-06-24 13:05:14

wet wrote:

A plugin is just as fine. I haven’t noticed a swamp of feature requests for a built-in tag so far, so I think demand is low.

Fine. I’ll live with that. Thanks for clarifications. Irony that a cms built on textile lacks of a “textilize” function/tag, but it’s true, there’s not that big demand.

Last edited by Zanza (2008-06-24 13:05:43)

jstubbs · 2008-06-24 17:08:13

Stef, not sure what you are looking to do with these new tags – is it going to be possible to have an txp:image tag that allows for one than one height/width?

Not read this thread, so sorry if I am off topic. One of the major things I would like to see in TXP is to be able to decide which size of image to display – for example: txp:image size=“t” for a thumbnail size, “m” for medium size and “l” for large. That would make me drool…!!

Bloke · 2008-10-22 00:40:53

3rd iteration of the patch submission is here for your general perusal. This one is patched against r2987

publish/taghandlers with images v3 (complete file)
publish/taghandlers with images v3 diff
lib/txplib_misc with images v3 (complete file)
lib/txplib_misc with images v3 diff

As before, this is not a complete patch because there are a few things ToDo based on feedback and ultimate acceptance:

Add error_image_context to txp_lang
Possibly add an undeletable form in the image category instead of relying on the horrible defaults stolen from <txp:image_index />. If this is done, set the form attribute of image_list to the new form by default.
Look at article_image (?)
Perhaps deprecate <txp:image_index /> and <txp:image_display />

Features:

New container tag <txp:image_list /> which will pull images from the given name, id, category (comma-separated lists allowed). The options are cumulative, meaning you can grab stuff from a category and add some named files to it as well if you like. You can also check to see if an image has_thumb and include it if so. The usual plethora of label, labeltag, wraptag, class, break, limit, offset, sort and form are all accepted.
New single tag <txp:image_info /> to pull out pieces of information about an image. Give it an image name or an id (only one this time) and the type of information you want and it’ll return it. Valid types are: id, name, category, category_title, alt, caption, ext, author, w, h, date. You can specify more than one type if you like (comma separated) to pull out more than one piece of information at once. Other attributes are escape (defaults to html), wraptag, class, break and breakclass.
New single tag <txp:image_url /> to return an optionally linked URL to the given image (by name or id). With link="1" you get a full anchor tag, without it you get the raw URL. Use thumb="1" if you want a link to the thumbnail instead.
New single tag <txp:image_size />. Since images sizes are sometimes a specialist case there’s a specialist tag to cater for them ;-) You can choose which part of the size you want returned via the type attribute. It defaults to width, height but you can choose one or the other if you wish. By adding thumb="1" you get the thumbnail sizes. If you choose the dual values, by default they are separated by a space character but this can be changed with the join attribute. Finally, as_html="1" will return an HTML formatted string, e.g. width="200" height="100".
New single tag <txp:image_date />. Again, as with image_size, you can get the raw database values out via <txp:image_info /> but if you want more control over the output, use this specific tag. It takes the usual format attribute to specify how you want the date returned using the strftime() syntax.
New conditional tag <txp:if_thumbnail /> that only works inside an image context.

Now, while all the above single tags take an id and name attribute, if they are used within a <txp:image_list>...</txp:image_list> pair, they automatically get assigned the info from the current image. Thus the tags act as the file_download and link tags do when used inside a form/container. Similarly, the standard <txp:image /> and <txp:thumbnail /> tags have been retrofitted with the ability to be used within an image form.

In doing the above I think I have brought images in line with the standard way of working with files/links and combined it with the sentiments from Mary’s upm_image (without the plethora of tags). So in theory you can now do most things you can do with upm_image, natively (with the exception of the article_image stuff — see later).

The proof now is, as they say, in the eating. This’ll need some heavy testing and some feedback on whether you can make image lists and pull out useful things like caption/alt, width, height, the url, etc etc. Also feedback on options, defaults, whether this is the right approach, the right balance of tags vs functionality, stuff like that is most appreciated.

As stated before, this won’t be in 4.0.7, it needs an army of people to run it through its paces and check I’ve not done anything stupid, as well as rationalise the functionality (if required), consolidate or explode tags as deemed necessary and generally make this into a patch that could perhaps be accepted into the core.

In the process of writing this (and to answer jstubbs, finally!) I have resisted tinkering with article_image or the core workings of the image screen. In order to facilitate different size images, the upload facility will need to be modified and that’s beyond the scope of this patch. This is simply to bring images into line with the other content types and give access to the image database fields so you can do what you like with them in forms and stuff.

There is one omission compared to upm_image. I would ultimately like to update article_image to do the following:

Allow multiple, comma-separated images in the field
Add form/container support
Retrofit it with $thisimage support so you can use the above new tags to pull out caption/alt/width/height/blah blah inside the container/form for each article image
Add if_article_image

But I can’t decide if it should be part of this patch or if it should be done later. What’s the general feeling out there (especially from the devs)? My gut feeling is this patch is big enough already and article_image updates should be done as a separate step, even though it’s reasonably simple to do.

This patch as it stands is largely only extending functionality based on copying and pasting code from the file_download mechanisms and applying them to the image type. To mess with article_image requires changing its behaviour, which is why I’ve left it alone for now. But I’m willing to incorporate the changes if the consensus is that it fits in this patch.

Anyway, enough of my rambling. Those of you on SVN, please give this a grilling and report back. Thanks.

lee · 2008-10-22 12:40:14

This is great news, will try it out soon.

mrdale · 2008-10-23 01:09:11

my brain hurts… in a good way.

the_ghost · 2009-08-28 19:18:29

Was this inserted in RC1 4.2.0?

Bloke · 2009-08-28 19:22:45

the_ghost wrote:

Was this inserted in RC1 4.2.0?

No. But something of this ilk sure will be included at some point in the near future if I have my way¹

¹ Disclaimer: my way is subject to revision based on the community/dev team ;-)

Bloke · 2010-01-27 03:32:28

^singing … and I’ll do it myyyy waaaayyyyy…

Natalya · 2010-01-27 05:52:18

New single tag <txp:image_url /> to return an optionally linked URL to the given image (by name or id). With link=“1” you get a full anchor tag, without it you get the raw URL. Use thumb=“1” if you want a link to the thumbnail instead.

Looks like the link attribute now has a possible value of auto. How does this differ from link="1"? I think, most tags use either 0 or 1 as attributes for such switches, don’t they?

Textpattern CMS

Textpattern CMS support forum

#25 2008-06-23 19:48:09

Re: Adding more consistent image functionality

#26 2008-06-23 20:19:20

Re: Adding more consistent image functionality

#27 2008-06-24 10:52:44

Re: Adding more consistent image functionality

#28 2008-06-24 13:05:14

Re: Adding more consistent image functionality

#29 2008-06-24 17:08:13

Re: Adding more consistent image functionality

#30 2008-10-22 00:40:53

Re: Adding more consistent image functionality

#31 2008-10-22 12:40:14

Re: Adding more consistent image functionality

#32 2008-10-23 01:09:11

Re: Adding more consistent image functionality

#33 2009-08-28 19:18:29

Re: Adding more consistent image functionality

#34 2009-08-28 19:22:45

Re: Adding more consistent image functionality

#35 2010-01-27 03:32:28

Re: Adding more consistent image functionality

#36 2010-01-27 05:52:18

Re: Adding more consistent image functionality

Board footer