considering images

colak · 2019-01-02 09:48:18

This is not so much a feature idea but considerations regarding the way images are stored and handled by txp.

We have previously discussed these issues and hope that they can be improved in the next txp release. the reason for this post is mostly to collate the various discussions into one focused thread.

Images currently all reside in txp’s designated folder, renamed to the id they have in the db. This creates a very large, and somewhat unmanageable, content for old or gallery sites.

An idea was for txp to save the images in separate directories/subdirectories named after the category/subcategory they belong to, but this might break some existing sites which may link to the images directly. A solution should nevertheless be considered as this problem will steadily get more difficult to handle.

Another issue which was discussed is the plan to add more (unlimited?) categories to images, which might also make the above obsolete.

Finally, the html5 introduction of the picture tag, allows for multiple size images, rendering the image and thumbnail tags inefficient when wanting to use modern website design techniques.¹

Another minor problem is the issue of linked images. These could include banners, adverts, or just linked images because of design decisions.

At the moment, the title field could be used for most of such cases but what about adverts² (which we admittedly never have in any of the sites I manage) or any other time limited visual display only images can offer? Although the expired field is present in articles, it is not present in links, files, or images.

I know that txp is flexible enough to deal with most of the above, but the two issues of picture³ and the bloated images directory remain.

¹ The images and image_info tags can be used but the default install would require uploading the same image in various sizes, and this could mean that for the same image we would have at least 2 ids. see also note 3:)

² Stef had the answer with smd_random_banner some time ago, but shouldn’t this functionality become part of the default arsenal?

³ I am aware of smd_thumbnail but what I am discussing is a vanilla install approach.

philwareham · 2019-01-02 10:29:18

Stef is already gathering ideas from the team internally regarding image improvements for Textpattern 4.8. Say tuned and we will share some info at a later date when plans are more solid. Cheers!

colak · 2019-01-02 11:10:20

Thanks so much Phil,

I hope that some of the above will be of help anyway.

Bloke · 2019-01-02 11:59:52

This is all good stuff, thanks Yiannis. I’ll PM you later about it, if I may.

colak · 2019-01-02 16:14:50

sure stef… any time.

towndock · 2019-01-02 18:15:48

Agreed that image handling is key for the future of Textpattern. We have over 26,000 images on one site. It scares me when I think about it, but it does work in practice. It would be nice to have orderly sub-directories instead of that one big bucket though.

I’m not enthused about sub-directories based on image categories (never have used categories with images), but I can see sub-directories that are date based (by year, month) being useful.

I don’t believe Textpattern needs to have code to manage advertising images. We do run ads on our key site – it is all done with 3rd party software that is designed just for that purpose. Most users that are seriously selling advertising space will use 3rd party software and integrate that into the site templates.

Something like smd_thumbnail built into core would be welcome.

How future image handling changes work with existing sites will effect most of us. An option to select 4.8 or Legacy image handling may be needed.

I do hope the Dev Team shares some of the ideas before making the plans concrete, so users can respond on the forum with any usability concerns.

philwareham · 2019-01-02 19:40:15

The plans will be shared and we will listen to feedback prior to making any sweeping changes – don’t worry! We just need to thrash out some foundations internally before we open it up for discussion (as we don’t want to lose focus with many many suggestions right at the start).

Bloke · 2019-01-02 20:15:53

Yep, as Phil says, I’ve prepared a document with some ideas and we’re going through it to try and flesh out some basics. And also, crucially, outlining what’s not in scope.

Once we have something we feel is workable and doable, we’ll present them here and see whether people agree we’re going in the right direction, then iterate from there. Watch this space.

ia278 · 2019-02-12 13:10:23

Hey guys – thought I’d add an SEO suggestion on here.

From what I’ve been told, Google uses the name of an image to help index it – and so, it’s good practice to name it something that includes your desired keywords. For example, a picture of the moon would rank much higher if it the URL linked to an image ending in its name moon.jpg instead of ID 143.jpg – which is what currently happens now.

At the same time, I know that the decision to name images by their ID was probably taken years ago – and with years of code and releases based on this, any solution needs to be backward compatible.

“Here’s my attempt of a fix on the front end.

The dropdown could have a few options (/id, /name, /name/id etc.), but here’s where my knowledge starts to get strained. I know that there’s a txtptrn_txp_image table inside the database – is there a way of being able to use this to rewrite the names of files inside the images folder depending on the option selected in the Preferences panel?

Last edited by ia278 (2019-03-21 14:32:13)

jakob · 2019-02-12 13:30:07

That might be an option that offers a way forward for newer sites.

FWIW you can gain the SEO benefit with the help of a RewriteRule in .htaccess. See this thread for further information.

hilaryaq · 2019-05-22 14:31:09

Great point on picture which is an important tag coming up! Something I’ve wanted for so long is to be able to generate code for a thumbnail in the images tab, it only outputs tags to full res images.. :) I know you can manually edit image to thumbnail but it would save a lot of time and be more user friendly for end users too!

Textpattern CMS

Textpattern CMS support forum

#1 2019-01-02 09:48:18

considering images

#2 2019-01-02 10:29:18

Re: considering images

#3 2019-01-02 11:10:20

Re: considering images

#4 2019-01-02 11:59:52

Re: considering images

#5 2019-01-02 16:14:50

Re: considering images

#6 2019-01-02 18:15:48

Re: considering images

#7 2019-01-02 19:40:15

Re: considering images

#8 2019-01-02 20:15:53

Re: considering images

#9 2019-02-12 13:10:23

Re: considering images

#10 2019-02-12 13:30:07

Re: considering images

#11 2019-05-22 14:31:09

Re: considering images

Board footer