Textpattern Forum

You are not logged in. Register | Login | Help

#381 2010-06-13 18:22:07

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,815
Website

Re: Improving TXP Image Management

jameslomax wrote:

the Images tab also sucks. That single column display is appalling use of white space

cf. Suffice to say it’s grid-based :-)

txp uses some kind of locked grid structure to organise the thumbs in that tab

Yup. It’s awful markup. That’s another reason why it’s taken so long to sort this out; the tab needs a complete rethink. And rethinking one tab means rethinking a lot of the way TXP’s markup looks. Hence it’s a job for TXP 5.

I should clarify that the image I posted above (of the edit screen) was primarily intended to be my attempt at a simple shuffle around to ease image editing in the next version of TXP. Whether it sees the light of day remains to be seen. To do it properly, as you say, requires new markup and deletion of the tables that litter the tab. I don’t think any image plugins aside from lam_browse_by et al, and EBL_Upload/Image_Edit et al would be affected by such a massive back-end reshuffle on this tab. But to commit to doing it now in time for 4.3.0 would mean it would need to be done again in TXP 5 when the rest of the admin side changes (unless I somehow knew what TXP 5 will look like via my crystal ball!)

with the various plug ins that change the Admin interface quite drastically, something similar could be done with the Image tab design…..

Sadly not. It really is a mess in terms of markup. Any mods would be restricted to CSS as there are no plugin hooks on that tab (just one on the Image Edit screen).

It is a huge undertaking to unpick it all and build it up again from — almost from scratch. I’m not averse to huge undertakings, as you may have noticed(!), but I’m not a designer, nor am I a hardcore image editor. So the best I can do is take as many different viewpoints as possible — and this thread is a great place for that — split them into “yes, makes sense for core” and “no, this is better as a plugin/theme” and then proceed accordingly to build a framework for the tab that can benefit as many Image-minded folk as possible while keeping TXP’s options open in terms of future markup and plugin rejiggerisation.

I’ve begun the process of releasing us from the shackles of tables by refactoring the classes and IDs. I’m going to revisit this tonight now I’ve thought about it a little harder to see if I can do more to help this tab be more easily alterable.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Online

#382 2010-06-13 18:37:22

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,815
Website

Re: Improving TXP Image Management

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.

Removing the sole thumbnail from the database: not sure. I don’t really know what’s involved here or whether it’s a good idea from a backwards compatibility viewpoint. Essentially you’re advocating removing the /images/NNNt.jpg files from existence. That’s pretty drastic; and up there with renaming the images from integer.extension to true filenames!

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’ve only had one site where it would be a real boon to have more. But since my design experience is limited I wouldn’t base any judgement on me; I might be waaaay off base with that estimate.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Online

#383 2010-06-13 19:18:36

Gocom
Developer
Registered: 2006-07-14
Posts: 4,471
Website

Re: Improving TXP Image Management

Bloke wrote:

Got a script in mind? I could check it out.

Umm, something like the following?

$('img').click(function(){
	$(this).removeAttr('width');
});

Or with two images. One hidden, other one is the smaller version and shown by default.


Rah-plugins | What? I’m a little confused… again :-) <txp:is_god />

Offline

#384 2010-06-13 19:20:00

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

Re: Improving TXP Image Management

jameslomax wrote:

Looks good. I’ve said it before several times so I’m not going to labour it, and others have also, that the Images tab also sucks.

This is recognised by all but that doesn’t change the fact that the TXP architecture at this point makes it very difficult to change. As Stef pointed out, its almost better to start from scratch and there is always the pressing need to provide for backwards compatibility.

The current way forward is to provide markup hooks for TXP 4.3 leading to a wholesale change in TXP 5, which is planned to have better markup and styling.

Having worked a little on the Images tab I can tell you this is no walk in the park – but you should realise that a lot of the work and planning has already been done.

Please don’t forget that Stef has also made a lot of changes and additions to the front-end TXP tags.


TXP Tips | @txptips | Me | @jonathanstubbs | Github

TXP Builders – finely-crafted code, design and txp @txpbuilders

Offline

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

hakjoon
Moderator
From: Arlington, VA
Registered: 2004-07-29
Posts: 1,631
Website

Re: Improving TXP Image Management

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.


Shoving is the answer – pusher robot

Offline

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

masa
Member
From: Reykjavik, Iceland
Registered: 2005-11-25
Posts: 1,079

Re: Improving TXP Image Management

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

Offline

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

thebombsite
Plugin Author
From: Exmouth, England
Registered: 2004-08-24
Posts: 3,251
Website

Re: Improving TXP Image Management

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.


Stuart – The BombsiteProText ThemesTextgarden

In a Time of Universal Deceit
Telling the Truth is Revolutionary.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,815
Website

Re: Improving TXP Image Management

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*)…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Online

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

thebombsite
Plugin Author
From: Exmouth, England
Registered: 2004-08-24
Posts: 3,251
Website

Re: Improving TXP Image Management

Ooooo. Ummmmm.


Stuart – The BombsiteProText ThemesTextgarden

In a Time of Universal Deceit
Telling the Truth is Revolutionary.

Offline

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

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 5,815
Website

Re: Improving TXP Image Management

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.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern.

Txp Builders – finely-crafted code, design and Txp

Online

Board footer

Powered by FluxBB