Improving TXP Image Management

Bloke · 2009-11-17 14:22:24

philwareham wrote:

Anyone know if there are planned improvements to the admin images section

Planned yes. Implementation time scale depends on whether I still have a job next week or not :-o

A better gallery view structure for the images section

Some kind of grid-based layout would be nice, though I’m struggling to make the multi-select a reality. Nothing seems intuitive enough, and loading jQuery UI as a component to allow draggable selections is not really an option (it’d double the size of TXP’s codebase for a start!). Needs some more thought.

A way to find and delete unused batches of images, or an indicator as to if and where an image has been used at all in articles.

Unlikely to be implemented. Think of the myriad different ways an image could be used: it could be a number in a custom field, the image name or number itself in an article image (perhaps as a list if using a gallery plugin), it could be used in a txp:image, txp:thumbnail or gallery plugin tag, or simply referenced by category in a Form. And that’s just off the top of my head. Keeping track of and/or finding all instances of an image is probably not going to add any conceivable benefit compared to the amount of code it’d take to make it bulletproof. Always willing to be shown a way of doing it, but I can’t see it happening.

A more intuitive way of inserting images into articles instead of jumping between multiple pages of the admin area.

Plugin territory. There’s no way the core could anticipate all the needs of users and present something usable. Some might simply want a dropdown list of images near the article_image field. Some might want image thumbs to be shown down there. Some might want the fullsize image to be shown on hover. Some might want a full lightbox image chooser. Whichever one we choose, someone will want something else or it won’t fit.

Given the intense platformisation effort that wet undertook for 4.2.0 and the effort I’m going to behind the scenes to make the admin-side DOM a little more pleasant to work with, hooking into the existing markup and providing plugins to fill the above needs is the way forward.

I would add that a personal item (4) on the list should be better client-side image display tags and to (internally) promote images to first class citizens alongside files and links. That’s also very much a goal of mine. Balancing the number of tags required to get stuff out of the database vs making it too unwieldy is the focus of my current inner turmoil :-) For example: <txp:image_width />, <txp:image_height />, <txp:thumbnail_width />, <txp:thumbnail_height />, <txp:image_extension />, <txp:image_date />, blah blah is waaay too much clutter. <txp:image_info type="thumbnail_width" />, and so on is perhaps too terse and some of the tags require options which need to be served to specific tags. So there has to be some compromise between functionality and verbosity. I whittled it down to a group of tags with related attributes (I can post my current thinking if you’re interested). Any pointers, thoughts or improvements greatly appreciated.

As far as renaming images goes, I think the numbering system is too ingrained to change. But if anyone knows more about search engine image meta data and how it’s used, please enlighten us. I can’t believe that an image becomes unsearchable on Google Images, for example, just because it’s called DSC_1783.jpg instead of MyShavedPoodle.jpg. Somewhere along the line, the search engines must grab some meta information about that image so it’s indexable. If that’s all it takes to make the images more visible then that’s what we should do, imo. Is that where alt and title come in, or are there new attributes in HTML5 that we can support?

Last edited by Bloke (2009-11-17 14:23:08)

lunchbox · 2009-11-24 02:28:08

Having read through the majority of this thread’s 300+ posts, I’m still at a loss as to why Textpattern insists on renaming images when they’re uploaded. I understand the bit about conflicting file names, but I don’t see why images can’t be treated like other files: with a unique ID for hooking purposes and a proper filename for semantic ones. Am I missing something? Is there perhaps a plugin or established workaround that allows for this functionality? Do I need to upload all of my images via the Files tab and forgo the help of the various image tag hooks just to have functional filenames?

I apologize if I’m way out to lunch on this, but it just seems like a peculiar way of doing things, especially when all other file uploads are treated in the way that I’d like images to be treated.

Quite apart from that, it’s incredibly disconcerting that this thread has been around for what will soon be four years, with (as near as I can tell), very little to show for it. I saw several offers from people in this thread to “ransom” (which means “fund the development of,” I presume) a plug-in if one was forthcoming, and still nothing has happened. Can someone explain this to me? I’m brand new to Textpattern, and would very much like to like it – I bought the book and everything – but this sort of thing is frankly terrifying to someone approaching the platform from the outside.

masa · 2009-11-24 13:51:29

lunchbox wrote:

I understand the bit about conflicting file names, but I don’t see why images can’t be treated like other files: with a unique ID for hooking purposes and a proper filename for semantic ones.

This comes up every now and then, but telling from past discussions, this is highly unlikely to change. Textpattern has worked like this since the beginning and the required changes would probably be substantial.

It bothers neither me nor my clients. I prefer simple sequential numbering to the randomish, long, alphanumeric text strings that some other CMSs assign to images.
Are there actually any CMSs, that don’t assign their own internal names to images?

If you’re worried about search engines, you should make sure to write descriptive alt texts and captions for your images. Google image search examines the surrounding text to decide whether an image is relevant. And it does a really good job of finding images despite them having cryptic names.

That said, this thread, as far as I recall, is mostly about improving the Images tab and image handling from a user’s perspective. Some issues, like the ability to change the category/delete multiple images at once, have been addressed since. Others, such as a multi-column display, would be very nice to have and present a real improvement in terms of usability.

Last edited by masa (2009-11-24 16:08:41)

photonomad · 2010-01-09 22:29:12

I would love to be able to edit and view image alt and captions in the list view without having to click on each image in the list individually, scroll down, etc.

jonlandrum · 2010-02-23 22:23:03

Bloke wrote:

As far as renaming images goes, I think the numbering system is too ingrained to change. But if anyone knows more about search engine image meta data and how it’s used, please enlighten us. I can’t believe that an image becomes unsearchable on Google Images, for example, just because it’s called DSC_1783.jpg instead of MyShavedPoodle.jpg. Somewhere along the line, the search engines must grab some meta information about that image so it’s indexable. If that’s all it takes to make the images more visible then that’s what we should do, imo. Is that where alt and title come in, or are there new attributes in HTML5 that we can support?

Actually, that’s exactly how Google et al index images. The main factor is the image name itself. They also give points on title and alt attributes, as you mentioned.

Last edited by jonlandrum (2010-02-23 22:23:32)

PascalL · 2010-02-23 22:35:45

Try to search for the word “lizard” with google image search. As far as I can see, all images’ names in the first 10 pages contain the word “lizard”. The name is an important criteria for SEO (if not the most important).

Last edited by PascalL (2010-02-23 22:40:52)

uli · 2010-02-23 22:39:23

I think the context is a very important factor, at least for Google. I’d never have found many images if Google weren’t scanning the context during image indexing.

jonlandrum · 2010-02-24 23:47:09

I still say image name is number one, though. Google does not read the meta data on the image, as far as I’ve been able to tell. And text around the image does play on it some, just like with text around a link. But the text within the link itself is the big one. And the name of the image is the same.

Gocom · 2010-02-25 00:32:30

jonlandrum wrote:

I still say image name is number one, though.

We all can say whatever we want and believe what we want :-) We all can speculate if Santa is or not. Like I will say that Uli is spot on, and everything that Google rates is about visibility, link-juice and context.

From Google’s Webmaster Center:

If we’re unable to find suitable text in the page on which we found the image, we’ll use the filename as the image’s snippet in our search results.

For example, if you have a picture of a polar bear on a page about home-grown tomatoes, you’ll be sending a confused message to the search engines about the subject matter of polarbear.jpg.

Wherever possible, it’s a good idea to make sure that images are placed near the relevant text. In addition, we recommend providing good, descriptive titles and captions for your images.

From where I stand, it seems that the name plays a part in contextual linking of the file. Uli’s Answer + Jonathan’s = Something like that. That’s my slice of troll-in.

Last edited by Gocom (2010-02-25 00:39:04)

maniqui · 2010-02-25 02:24:13

Re: filename for images (aka image name)… since a few months ago, I’ve been wondering if it wouldn’t be possible to the following (which I think is “almost-backwards-compatible-and-friendly-and-SEO-friendly”).

Current behaviour:

1) you upload an image with name “DSC02392.jpg”
2) it gets renamed to “1.jpg” and its thumbnail is “1t.jpg”
3) the image_name field records “DSC02392.jpg”, and user can change it, but it doesn’t affect the filename on the filesystem.

New behaviour

1) you upload an image with name “DSC02392.jpg”
2) it gets renamed to “1_DSC02392.jpg” and its thumbnail is “1t_DSC02392.jpg”
3) the image_name field records “DSC02392” (without extension), and user can change it. If user changes it, it does affect the name of the filename on the filesystem. So, if user changes the image_name field to “pretty-name”, filename changes to “1_pretty-name.jpg” and “1t_pretty-name.jpg”.

So, to sum up, a filename for an image is: id_image-name.ext. That way, you (and anyone who suffers from OCD) still can craft your HTML using atomic stuff, like <txp:image_id />_<txp:image_name />.<txp:image_ext />.
This will let your clients play with the image_name field without breaking any reference to the image on your code.

I hope this idea makes sense and I’m not missing anything too obvious.

hakjoon · 2010-02-25 02:59:04

Why keep the id? If the physical file will change pretty much all the image building functions would need to be rebuilt so why not just kill the id all together?

Another option would be to allow TXP to handle image urls kind of like it handles the special file_download urls. Something like (don’t know if we need the extension might be able to handle it all with mime headers)

/image_magic_section/image_name.image_ext

Might need to create a url_title like field to sanitize the image names, but it would allow the files in the file system to still just be ids and have nice valuable urls. For the most part it seems to be backwards compatible since any old links/urls/functions would still work.

Just a thought.

Last edited by hakjoon (2010-02-25 03:00:31)

jonlandrum · 2010-02-25 04:21:54

Gocom wrote:

We all can say whatever we want and believe what we want :-) We all can speculate if Santa is or not. Like I will say that Uli is spot on, and everything that Google rates is about visibility, link-juice and context.

That’s true, we can all speculate. The only people who can say for sure how it works won’t for reasons of not revealing corporate secrets. My site at one time got most of its traffic from Google Images. Nowadays I get none from there because of an .htaccess booboo (forgot to allow hitting the image without a referer when I made a rule to get rid of the image scrapers). Now, I don’t blame any of that on Textpattern’s naming scheme, because I’m uploading my images myself using ftp. I’m just pointing out that I had at one time a very successful SEO scheme via image naming and relevant title and alt text. Even with very little text in the article, images were scoring high for search queries containing either the image name or text from the title and alt attributes.

wet · 2010-02-25 05:41:48

hakjoon wrote:

Another option would be to allow TXP to handle image urls kind of like it handles the special file_download urls.

Please keep in mind that this would diminish the performance of image requests by one or two orders of magnitude as we would have to pipe them through PHP and the DB. Bad idea, unless we build some caching apparatus around et cetera yadda yadda…

philwareham · 2010-02-25 09:15:55

I think the best situation (not even sure it’s possible) would be a plugin that takes the original filename (which is stored in the database anyway at upload) and use that as an alias applied onto the html output. Users could even change that filename without breakage – as the image is still (for example) 431.png in the actual system. That would keep everyone happy – and as it’s a optional plugin it would not affect the core performance, but the functionality is available if someone wants to use it.

I’m not a plugin author but that is my two pence worth.

hakjoon · 2010-02-25 14:39:34

wet wrote:

Please keep in mind that this would diminish the performance of image requests by one or two orders of magnitude as we would have to pipe them through PHP and the DB. Bad idea, unless we build some caching apparatus around et cetera yadda yadda…

True but it wouldn’t have to be the only way to handle images. Since the idea was to be backwards compatible the old ways would still work. If performance were to be a bootleneck there many non-txp solutions that could be applied to solve it (CDNs, memcache). I mean TXP is orders of magnitude slower than static pages right ;)

Alternatively you could implement this strictly on the apache side and just generate proper urls from txp. The new image tags could probably accommodate this. Basically recreate a /section/id/title.ext scheme for images, sort of what maniqui suggested.

So you have /images/2/mytitle.jpg have mod_rewrite yank out the id and ext and pass that to apache with something like /images/(0-9])/.*\.(.*)/ => /images/$1.$2 (regexp guaranteed not to work).

That should give you seo juice without any db overhead. urls for the images would just have to be built appropriately.

Textpattern CMS

Textpattern CMS support forum

#346 2009-11-17 14:22:24

Re: Improving TXP Image Management

#347 2009-11-24 02:28:08

Re: Improving TXP Image Management

#348 2009-11-24 13:51:29

Re: Improving TXP Image Management

#349 2010-01-09 22:29:12

Re: Improving TXP Image Management

#350 2010-02-23 22:23:03

Re: Improving TXP Image Management

#351 2010-02-23 22:35:45

Re: Improving TXP Image Management

#352 2010-02-23 22:39:23

Re: Improving TXP Image Management

#353 2010-02-24 23:47:09

Re: Improving TXP Image Management

#354 2010-02-25 00:32:30

Re: Improving TXP Image Management

#355 2010-02-25 02:24:13

Re: Improving TXP Image Management

#356 2010-02-25 02:59:04

Re: Improving TXP Image Management

#357 2010-02-25 04:21:54

Re: Improving TXP Image Management

#358 2010-02-25 05:41:48

Re: Improving TXP Image Management

#359 2010-02-25 09:15:55

Re: Improving TXP Image Management

#360 2010-02-25 14:39:34

Re: Improving TXP Image Management

Board footer