Improving TXP Image Management

hakjoon · 2010-06-13 21:38:09

Bloke wrote:

Regarding resizing and auto-thumbnailing, doesn’t that slow stuff down a lot when viewing a gallery/the admin tab? Or are the thumbs cached somewhere once they’re made? Sorry for the naive question.

Also if you decide to increase the size somehow (somewhere) and the images are cached, would such a script make sure the stale versions are purged/overwritten? That would take time, right? Especially on an image-heavy site.

You’d have to do caching. The way EZ-publish did it back when I used it was that you defined certain sizes and every image you uploaded got those sizes created. If your images are number 15 and 17 you had /images/original/15.jpg, /images/150×150/15.jpg, /images/200×300/15.jpg,/images/original/17.jpg, /images/150×150/17.jpg, /images/200×300/17.jpg.

You can offset the cache creation if desired and only create the size needed for the admin screen at upload, and then create the other sizes when requested the first time. Conversely you could put that load upfront in the image saving screen which really is where any slowness should be and no in the public site. If you have a lot of sizes and kill an image I guess it could be a bit slow but it shouldn’t be too bad I don’t think. Killing a size would just be killing a directory.

Using this method you don’t actually run the auto-thumbanil for the request only when creating new images, which i think is an acceptable time to be slower.

masa · 2010-06-14 02:39:30

Bloke wrote:

Multiple thumbs would be useful though for many an application. Whether the number of people using them outweighs the number of people who use just one would be an interesting debate on its own. I suspect the ratio is about 80:20 or 70:30 in the favour of single thumbs. But maybe that’s because there isn’t the option to make more!

I always generate thumbs at a size, that is convenient for reviewing in the backend – for instance 160px – and then use CSS to scale them down on the actual site as required with no ill effects.

Purists might discount that approach, but it’s being used all over the place and the general public doesn’t mind. For those that can’t live with that, there are alternative solutions such as Smart Image Resizer

thebombsite · 2010-06-14 15:32:35

I did think about the backward compatibility issues. Couldn’t the tag check to see if a “t” version of the image exists first, and if it does display it as normal or if not parse the whole tag and get on with creating the scaled image.

Yes always cached. The timthumb.php script includes cache cleaning and if an image has already been created it can check the dimensions.

Bloke · 2010-06-14 15:37:26

thebombsite wrote:

Couldn’t the tag check to see if a “t” version of the image exists first, and if it does display it as normal

Based on what you said above and Patrick’s insight into the way it’s been solved before, I might have a better idea.

Will reveal all if it’s viable after some poking and prodding under the bonnet.

^{spark plugs: check.}
^{carburettor: check.}
^{timing belt: don’t need that (*chuck*)…}

thebombsite · 2010-06-14 15:41:09

Ooooo. Ummmmm.

Bloke · 2010-07-01 01:11:31

As of r3368 the Images tab is now a little more open to plugin authors.

This means that, while we’re waiting for the consensus on improvements to the overall workflow of images in TXP, clever plugin authors can now augment or replace the existing functionality to ease the task of managing images. Here are the new callbacks and some notes on their usage for geeks:

event / step	where it is	notes
image / image_data	just after an image is uploaded / replaced	allows post-processing of new images, e.g. watermarking
image / image_delete	just before images are deleted	allows tidy up of any extra stuff done by plugins when images are batch-deleted
image_ui / extend_controls	just after the upload/search boxes (before the List view)	add extra controls and image filters like lam_browse_by
image_ui / extend_detail_form	after the Caption in Edit view	add any custom data to images
image_ui / thumbnail	the thumbnail in List view	augment, alter or replace the thumbnail
image_ui / image_edit	the image and its upload form in Edit view	augment, alter or replace the main image
image_ui / thumbnail_edit	the thumbnail and its upload form in Edit view	augment, alter or replace the thumbnail
image_ui / thumbnail_create	the thumbnail’s width/height/crop tools in Edit view	augment, alter or replace the thumbnail controls

As a proof-of-concept and to demonstrate how useful these callbacks can be, I’ve thrown together a plugin called smd_thumbnail which allows an arbitrary number of thumbnails to be defined. It’s based on Hakjoon’s description a few posts ago. I have some willing volunteers testing it in the field right now and I’m refining it as we go. The plugin will be on general release (from the beta part of my site for now) once I’m happy it’s solid enough.

As a taster, the current List view looks like this:

Notice you can define as many thumbnail profiles as you like. After that, each time you create or replace an image a thumbnail is generated for each active profile and stored in the file system. A new tag <txp:smd_thumbnail /> is a direct replacement for <txp:thumbnail /> and allows any of the thumbnails to be displayed in your site.

Here’s a shot of the multiple thumbnails that have been created on the Edit pane:

All this is subject to change right now, but it’s shaping up rather nicely and has some useful applications. Incidentally, changes to the classes/IDs on the tab are coming later this week too.

I hope these callbacks can help generate a slew of plugins to enable TXP image handling to become a bit more palatable for those of you that have been waiting years for some movement. Since we can’t hope to get it right to suit everyone, the best we can do right now is allow someone else to customise the workflow to suit people’s needs.

philwareham · 2010-07-01 07:26:32

Looks great Stef, slightly off topic is there a roadmap for textpattern? I personally prefer the textpattern schedule of infrequent but large feature updates as opposed to wordpress’ constant minor updates but when evangelising your lovely CMS to others that is something they notice and count against it.

Bloke · 2010-07-01 07:46:52

philwareham wrote:

is there a roadmap for textpattern?

Probably the closest you’ll get at the moment :-)

As 4.3.0 draws closer I’ll be posting some stuff in the weblog about alterations to the admin side that will help plugin authors and themers transition more smoothly towards TXP 5. Keep your eyes peeled!

monkeyninja · 2010-07-01 12:19:42

These enhancements sound great and a good move for TXP core.

Stef, you’re new plugin that makes use of these changes looks really useful. I’ve been using lam_dynamic_image on a site, but found that at times the image quality isn’t great and would have liked to have had slightly more control, which I’m guessing this new plugin would provide. If it then worked well with bot_image_upload then that would be really great!

Bloke · 2010-07-01 12:31:16

monkeyninja wrote:

If it then worked well with bot_image_upload then that would be really great!

It will depend on whether bot_image_upload uses the TXP functions to upload its image or redbot used custom code. If it calls image_data() to do the insertion then the multiple thumbnails will automatically be generated. If not, they won’t. Only redbot can answer that (short of someone else going through the code…)

lam_dynamic_image is great if, as you say, you don’t mind the browser scaling stuff as you view your site — and the inherent delay this may cause as it does the first image.

One thing the smd_thumbnail plugin doesn’t currently do is allow you to replace individual thumbnails with your own uploaded ones: they are all generated from the main image. This feature is planned once I can figure out a streamlined workflow for it.

redbot · 2010-07-01 13:20:02

monkeyninja wrote:

If it then worked well with bot_image_upload then that would be really great!

Bloke wrote:

…It will depend on whether bot_image_upload uses the TXP functions to upload its image or redbot used custom code. …

Hi,
bot_image_upload (which is still in a beta state) uses an iframe which links to the ‘image’ tab (hiding some items through jquery).
So in theory there should be no problems.

Last edited by redbot (2010-07-01 13:23:59)

monkeyninja · 2010-07-01 17:14:05

Thanks for the responses Stef and redbot. Keep up the great work on your plugins!

Textpattern CMS

Textpattern CMS support forum

#385 2010-06-13 21:38:09

Re: Improving TXP Image Management

#386 2010-06-14 02:39:30

Re: Improving TXP Image Management

#387 2010-06-14 15:32:35

Re: Improving TXP Image Management

#388 2010-06-14 15:37:26

Re: Improving TXP Image Management

#389 2010-06-14 15:41:09

Re: Improving TXP Image Management

#390 2010-07-01 01:11:31

Re: Improving TXP Image Management

#391 2010-07-01 07:26:32

Re: Improving TXP Image Management

#392 2010-07-01 07:46:52

Re: Improving TXP Image Management

#393 2010-07-01 12:19:42

Re: Improving TXP Image Management

#394 2010-07-01 12:31:16

Re: Improving TXP Image Management

#395 2010-07-01 13:20:02

Re: Improving TXP Image Management

#396 2010-07-01 17:14:05

Re: Improving TXP Image Management

Board footer