Automatic thumbnails for Textpattern

Bloke · Yesterday 21:45:23

Okay. Yeah, that’s a good shout too. Gotta get this cache working properly with only token generation on first hit.

The (simpler but yuckier) alternative is a horrible pref textarea where you can type in a list of sizes and crop ratios that you “allow” and if the one you’re attempting to create isn’t in that list, you get nothing spat back.

I don’t really want to go there because it’s less intuitive when your thumbnail tag fails to render anything.

Bloke · Yesterday 21:58:35

There is a potential simplification we could make, which fits with our ethos of convention over configuration. SLIR itself, out of the box, expects requests to be made to a /slir directory. In our implementation I’ve swapped that for a pref. But I don’t think there’s anything to prevent us hard-coding the ‘trigger’ to be two layers. That way, we might be able to do this:

/images/NN.ext (as usual)
/images/NNt.ext (as usual)
/images/thumbs/ (trigger for automatic thumbnail generation)
/images/thumbs/requests (first-layer cache)
/images/thumbs/renders (second-layer cache)

The only reason I didn’t do that was just in case someone has already got a subdir under /images for thumbs, which would mean their site breaks. We could mitigate that perhaps by setting it as /images/txp_thumbs/ perhaps? Unlikely to have anyone using that.

That means:

One pref less
It’s a fixed, well-known location.
It’s self-contained.
It’s relative to wherever your /images are stored.
It’s easier to match because it’s a fixed path.
No need for another possible check for clashes with a Txp-path and physical directory.
All image request URLs are then of the form example.com/images/thumbs/w200-h200-c1x1/images/NN.ext

So, lots to like. I’m not sure if it’s doable but I think it’s just a tweak to the ConfigDefaults file and then unhacking a load of junk I put in publish.php to cater for the pref.

Thoughts? Downsides?

jakob · Yesterday 22:10:16

Bloke wrote #341640:

/images/NN.ext (as usual)
/images/NNt.ext (as usual)
/images/thumbs/ (trigger for automatic thumbnail generation)
/images/thumbs/requests (first-layer cache)
/images/thumbs/renders (second-layer cache)

I like that. Feels very natural … especially without the txp_. The possibility of a thumbs subfolder already existing is only going to apply to people who are smd_thumbnail users, right? I presume there will likely be three upgrade paths for smd_thumbnail users:

The quick upgrade. Maintain custom thumbnails and smd_thumbnail as-is. There could be a notice in the diagnostics if the name clashes.
Switch to the new thumbnail generation, in which case the name clash becomes irrelevant
People who keep smd_thumbnail for those art-directing their content and uploading their own separately generated thumbnails. This is always a bit risky, as it’s easy to accidentally overwrite custom thumbnail variants. That kind of art direction is probably better made using several images.

bici · Yesterday 22:17:25

Bloke wrote #341640:

That way, we might be able to do this:

/images/NN.ext (as usual)...

Thoughts? Downsides?

so at the moment when a thumb is automatically generated and we have two files in images/: 12.png and 12t.png … and If we decide later on to have a different sized thumb image so we delete the current 12t.png and recreate a new one … what is the form of its new name in the images directory? Will it still be automatically associated with the 12.png ?
Or is it the case that in 4.9.0 this is no longer an issue?

Bloke · Yesterday 22:18:32

Yes, I don’t think there will be much fallout. And as you say, it feels a bit nicer.

Not sure how smd_thumbnail will play with all this. I guess it’ll coexists fairly well. That reminds me, I need to add the callback (it’s only one line to add to imageBuildURL()) as that will give people the opportunity to modify the URL that’s built so they can do other things with it.

I might try the fixed directory now on a local install and see what happens.

jakob · Yesterday 22:48:49

bici wrote #341642:

so at the moment when a thumb is automatically generated and we have two files in images/: 12.png and 12t.png … and If we decide later on to have a different sized thumb image so we delete the current 12t.png and recreate a new one … what is the form of its new name in the images directory? Will it still be automatically associated with the 12.png ?
Or is it the case that in 4.9.0 this is no longer an issue?

This is still a bit in flux in terms of the details but the basic situation is:

You can stick with user-chosen (=custom) thumbnails as the direct upgrade path from earlier versions. That gives you 123.jpg and 123t.jpg image files in your /images/ directory.
You can choose to have Textpattern automatically generate thumbnails as and when you need them in the size you set in your txp:image(_url) tags. You therefore no longer need to pre-define a thumbnail size. You set it instead in your template by specifying a thumbnail width. Textpattern generates the thumbnail images and caches them on disk but the only file you need to worry about is 123.jpg. The rest happens behind the scenes, and the t-suffixed version of the image doesn’t exist.

gaekwad · Yesterday 23:13:32

Bloke wrote #341637:

Unless we can’t get the cache working reliably, in a performant manner. In which case I’m perfectly happy to roll back the commits and push this to 5.0

There’s a whole branch of 4.9.* available…plenty of scope to iterate and improve if it’s functional in 4.9.0…certainly doesn’t need to be shelved for a few years while 5.0 is in the works. Besides, what will jakob say?:

jakob wrote #341638:

quivering lip But, it’s so good!

There’s reason enough to work this into 4.9.*.

phiw13 · Today 01:14:33

jakob wrote #341641:

Bloke wrote #341640:

/images/NN.ext (as usual)...

I like that. Feels very natural … especially without the txp_. The possibility of a thumbs subfolder already existing is only going to apply to people who are smd_thumbnail users, right? […]

Idem ditto. Would /images/thumbs/ actually containing actual images? I suspect smd_thumbnail users might leave everything as is, depending on the complexity of their configuration and then progressively migrate. As far as I can see that would not cause problems, based on testing with a local copy of my partner’s website (8 smd_thumbnail profiles); all actual calls to images are inside <txp:images />.

The latest updates make txp:article_image work much more inline with the expected results.

Bloke wrote #341637:

Definitely. Unless we can’t get the cache working reliably, in a performant manner. In which case I’m perfectly happy to roll back the commits and push this to 5.0

sad face trigger… It does work quite well so far – and soo much more functional than smd_thumbnail. Iterating on improvements in a 4.9.x release is the path to go.

Bloke · Today 01:42:08

We’ll get it ship-shape enough. Preliminary tests with /images/thumb are good (on the admin side at least). Public tags need more prodding but I can barely keep my eyes open so it’ll have to be tomorrow.

phiw13 · Today 02:08:07

phiw13 wrote #341647:

I suspect smd_thumbnail users might leave everything as is, depending on the complexity of their configuration and then progressively migrate. .

I was kinda wrong about that progressive migration path for smd_thumbnail users. I hadn’t tested trying to mix, and use the new thumbnail/image handling together with smd_thumbnail . In a light test, with a freshly uploaded image:

setting an image to use an “automatic” thumbnail: no image displayed on the Edit panel, but an image is displayed on the list panel.
trying out some of the various tag combos discussed above: the full size image is used or nothing is displayed.

Bloke · Today 07:16:28

Ah, okay. Thanks for testing. Both this plugin and com_article_image will need testing and patching, I expect.

Textpattern CMS

Textpattern CMS support forum

#97 Yesterday 21:45:23

Re: Automatic thumbnails for Textpattern

#98 Yesterday 21:58:35

Re: Automatic thumbnails for Textpattern

#99 Yesterday 22:10:16

Re: Automatic thumbnails for Textpattern

Bloke wrote #341640:

#100 Yesterday 22:17:25

Re: Automatic thumbnails for Textpattern

Bloke wrote #341640:

#101 Yesterday 22:18:32

Re: Automatic thumbnails for Textpattern

#102 Yesterday 22:48:49

Re: Automatic thumbnails for Textpattern

bici wrote #341642:

#103 Yesterday 23:13:32

Re: Automatic thumbnails for Textpattern

Bloke wrote #341637:

jakob wrote #341638:

#104 Today 01:14:33

Re: Automatic thumbnails for Textpattern

jakob wrote #341641:

Bloke wrote #341637:

#105 Today 01:42:08

Re: Automatic thumbnails for Textpattern

#106 Today 02:08:07

Re: Automatic thumbnails for Textpattern

phiw13 wrote #341647:

#107 Today 07:16:28

Re: Automatic thumbnails for Textpattern

Board footer