Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#349 2010-01-09 22:29:12
Re: Improving TXP Image Management
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.
Offline
#350 2010-02-23 22:23:03
Re: Improving TXP Image Management
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
andtitle
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)
\\//_ Live long and prosper.
Offline
#351 2010-02-23 22:35:45
Re: Improving TXP Image Management
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)
Offline
#352 2010-02-23 22:39:23
- uli
- Moderator
- From: Cologne
- Registered: 2006-08-15
- Posts: 4,306
Re: Improving TXP Image Management
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.
In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links
Offline
#353 2010-02-24 23:47:09
Re: Improving TXP Image Management
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.
\\//_ Live long and prosper.
Offline
#354 2010-02-25 00:32:30
Re: Improving TXP Image Management
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)
Offline
#355 2010-02-25 02:24:13
Re: Improving TXP Image Management
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.
Offline
#356 2010-02-25 02:59:04
Re: Improving TXP Image Management
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)
Shoving is the answer – pusher robot
Offline
#357 2010-02-25 04:21:54
Re: Improving TXP Image Management
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.
\\//_ Live long and prosper.
Offline
#358 2010-02-25 05:41:48
Re: Improving TXP Image Management
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…
Offline
#359 2010-02-25 09:15:55
Re: Improving TXP Image Management
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.
Offline
#360 2010-02-25 14:39:34
Re: Improving TXP Image Management
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.
Shoving is the answer – pusher robot
Offline