Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

#21 2008-06-23 16:12:37

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,049
Website

Re: Adding more consistent image functionality

Zanza wrote:

The reasons: To insert link. To format caption. To have Unicode character correctly converted.

OK, I’m not sure I quite follow (since old-fashioned ASCII is good enough for English!) but the caption and alt both automatically set the escape function to “html” as stuart suggested and wet implemented recently.

I’m not sure that directly addresses your concern but I shall look at bos_image_display and see what you have done in the code. If I can understand it — I’m not very good with character set issues — and it looks useful I’ll see what could be rolled in here.

I do want to try and keep the tags working the same as other TXP tags in terms of how they escape things and deal with character set issues so it may be that there’s not much I can do in this case without complicating this further!

Thanks for the info.


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

#22 2008-06-23 17:11:01

ruud
Developer emeritus
From: a galaxy far far away
Registered: 2006-06-04
Posts: 5,068
Website

Re: Adding more consistent image functionality

The reason for not adding separate tags just to display various bits of image info is mostly to avoid a truckload of duplicate code. It doesn’t reduce functionality, just the amount of code needed to achieve that functionality.

Offline

#23 2008-06-23 17:37:39

Zanza
Plugin Author
Registered: 2005-08-18
Posts: 699
Website

Re: Adding more consistent image functionality

Bloke wrote:

Zanza wrote:

The reasons: To insert link. To format caption. To have Unicode character correctly converted.

OK, I’m not sure I quite follow (since old-fashioned ASCII is good enough for English!) but the caption and alt both automatically set the escape function to “html” as stuart suggested and wet implemented recently.

Yes, this is good to put them in alt and title attribute. i.e., if you have single quote or ampersand in them and you not escape them, you’ll get an error in validation.

But this is not enough for some “extended” uses of caption. If caption is meant to be displayed in the html, just below the photo, then is reasonable to have some options to control the markup a bit.

I’m not sure that directly addresses your concern but I shall look at bos_image_display and see what you have done in the code. If I can understand it — I’m not very good with character set issues — and it looks useful I’ll see what could be rolled in here.

My code is a messy. But I can post here the concept, that is very easy and uses standard txp funxtions. I just provided a textilize attribute and then check for it:

if ($textilize == 1) {
include_once txpath.'/lib/classTextile.php'; 
$textileThis = new Textile();
$caption = dumbDown($textileThis->TextileThis($caption));
}

I just demand for an option as simple as that where the caption can be displayed.

Obviously, if there was a txp tag that can be wrapped around the image_caption tag and tha does the same (textilize and dumbdown), than it won’t be necessary. Added: Actually, I realized that maybe dumbDown is not needed… As that function transform unicode special characters and entities in a “sanitized” plain english letter. I just have to remember WHY I put it there, there should have been a reason… The textile part anyway is valid.

So I don’t know what’s the right way to do this. I used this solution, but a better one is welcomed.

I just think that, for internationalization and better caption formatting, they should be included.

Discussion opened, of course!

Last edited by Zanza (2008-06-23 17:52:49)

Offline

#24 2008-06-23 18:24:58

wet
Developer
From: Lenzing, Austria
Registered: 2005-06-06
Posts: 3,267
Website

Re: Adding more consistent image functionality

Zanza wrote:

…I just provided a textilize attribute…

Why is this better than, say, using upm_textile?

Offline

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

Zanza
Plugin Author
Registered: 2005-08-18
Posts: 699
Website

Re: Adding more consistent image functionality

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:

  1. 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?
  2. 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.

Offline

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

wet
Developer
From: Lenzing, Austria
Registered: 2005-06-06
Posts: 3,267
Website

Re: Adding more consistent image functionality

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.

Offline

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

kemie
Plugin Author
From: mexico<-->sweden
Registered: 2004-05-20
Posts: 495
Website

Re: Adding more consistent image functionality

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


~~~~~~~~~~~~~| monolinea.com | pixilate.com | istockphoto.com/kemie |~~~~~~~~~~~~~

Offline

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

Zanza
Plugin Author
Registered: 2005-08-18
Posts: 699
Website

Re: Adding more consistent image functionality

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)

Offline

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

jstubbs
Moderator
From: Hong Kong
Registered: 2004-12-13
Posts: 2,394
Website

Re: Adding more consistent image functionality

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…!!

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 9,049
Website

Re: Adding more consistent image functionality

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

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.


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

Board footer

Powered by FluxBB