Automatic thumbnails for Textpattern

Bloke · Today 07:28:13

phiw13 wrote #341820:

the width and height dimensions (and the equivalent <txp:image_info type='w' />, etc) are given as if in landscape mode – always 4000px by 3000px.

That’s a ~~feature~~ bug in the way we handle uploads. We only switch the dimensions given by the orientation info for thumbnails (custom and automatic).

You’re right: we probably should do that for the main image too. If there’s opportunity to do that check during the upload process (if jpg, and orientation flag is one of the four anomalies) then we could flip w and h values before storing in the DB for the main image too.

I won’t be able to look at this until much later today, so if anyone fancies having a stab in the meantime, please commit or propose a PR. Most of the code can be cadged from class.thumb.php.

Edit: I presume only jpg images are affected by this? How do webp, PNG and avif etc handle orientation?

Last edited by Bloke (Today 07:30:10)

etc · Today 11:29:27

Bloke wrote #341812:

Okay, that works fine on a server but borks on localhost. Like, it sits there for 5 seconds or so with a broken/empty image placeholder space and then, eventually, the 301 redirects and the content loads. No idea why.

Might it be that your laptop was on low battery and took 5s to generate the thumbnail? The redirect happens right after the thumb is written to the disk, because before the file does not yet exist. And we do not (yet) optimise SLIR image processing, just its integration into txp.

To see how (too) much we care, the latest optimisations concern only the visitor that triggers thumbs creation, all the others already get them for free.

jakob wrote #341813:

The very first time I got some dropped out images but the images were generated. I couldn’t see why they weren’t appearing.

Could you clear the disk cache again and reload the page with browser console open? Then, inspect the response of dropped out requests, maybe there are some hints?

Bloke · Today 16:18:49

etc wrote #341824:

Might it be that your laptop was on low battery and took 5s to generate the thumbnail?

Unlikely :)

It’s on 100% now and I ran it again, uploading all 9 of those Landscape images from the Orientation test suite that Julian posted earlier. They all “uploaded” to localhost immediately and all the thumbs were empty squares. I drummed my fingers on the desk for 5 seconds and they all appeared.

The Network pane in the Inspector shows a 5s green bar ‘Receiving’ (see previous scrrenshot) for each image, except the first three that show a 5.11s red bar “blocked”. See screenie:

ibb.co/bjSTV3pL

No idea what that means, nor why it’s blocked. I watched the thumb dir and 6 of the 9 thumb files were generated immediately. but their thumb images did NOT appear on the Images panel. Then after the 5s pause, the other 3 landed in the directory and all 9 thumbs appeared.

I then emptied the thumbs directory, reverted the code to the version without the 301, and uploaded the other 9 images. This time, the first two blocked for 109ms, then 100ish milliseconds later, all the thumbs appeared instantly.

ibb.co/9k3j3Vtv

So something is causing it to ‘block’ but it doesn’t do it if the Redirect isn’t in the code. 🤔

EDIT: I wonder if, perhaps, MAMP is rate-limiting redirects? It can’t be the browser (Firefox) because if I repeat the experiment online, I get 9 redirects and 9 immediate thumbnails appearing in the Images panel.

Last edited by Bloke (Today 16:27:53)

jakob · Today 16:23:00

etc wrote #341824:

Could you clear the disk cache again and reload the page with browser console open? Then, inspect the response of dropped out requests, maybe there are some hints?

I was hoping to do that, but I haven’t been able to make it happen again.

What I am seeing in the Firefox web inspector is a series of 301s for the images with a token and a parallel 200 for each image without a token. I think that was intended based on Stef’s last commit.

EDIT: Managed to make it happen once in a clean DuckDuckGo browser tab, but only once and only for one image of 16 (the first one). It seems to be a very isolated problem. Response for non-showing 24.png and response showing regular 26.png for comparison.

etc · Today 16:52:51

Bloke wrote #341825:

So something is causing it to ‘block’ but it doesn’t do it if the Redirect isn’t in the code. 🤔

EDIT: I wonder if, perhaps, MAMP is rate-limiting redirects? It can’t be the browser (Firefox) because if I repeat the experiment online, I get 9 redirects and 9 immediate thumbnails appearing in the Images panel.

We can revert 301, there is no much UX difference:

with 301, the triggering client establishes two connections per image, but only the second one results in thumbnail transmission and caching for further visits.
without 301, the thumbnail is downloaded and stored first under its temporary URL. If the client accesses the page again, a new copy will be downloaded, with its ‘permanent’ URL this time.

So, 301 is slightly better for multiple visits, but all this concerns only the unlucky visitors who trigger thumbnails creation.

jakob wrote #341826:

EDIT: Managed to make it happen once in a clean DuckDuckGo browser tab, but only once and only for one image of 16 (the first one). It seems to be a very isolated problem. Response for non-showing 24.png and response showing regular 26.png for comparison.

We need to see the response content here, sorry.

Bloke · Today 17:39:28

etc wrote #341827:

We can revert 301, there is no much UX difference:

I don’t want to be the wet blanket if it’s just my setup that’s causing issues. But there’s a chance it’s not just me.

all this concerns only the unlucky visitors who trigger thumbnails creation.

Yeah, but it’s blazingly fast enough now, thanks to your genius idea of using the 404 to trigger creation, that I don’t think (m)any people will notice.

etc · Today 17:56:59

jakob wrote #341714:

the behaviour is ever so slightly different between the two with respect to whether the height attribute is shown.

I know it’s getting ~~late~~ close to release, but this thumbnail="2" looks a bit arbitrary. What if we delegate all ‘auto’ functionality to <txp:thumbnail />, which currently is just (more or less) an alias for <txp:image thumbnail />? This way, without any ambiguity, setting width or other parameters would trigger thumbnail generation.

Bloke · Today 18:07:02

etc wrote #341829:

this thumbnail="2" looks a bit arbitrary.

Honestly it was only there to differentiate it from the current situation of custom thumbs (which are ‘1’ in the tags) so there are no backwards compatibility issues. If there’s a better way, that’s cool.

The ‘2’ also allows people to search on the admin side by thumbnail type (“2” or “auto” in search box). And allows you to override any existing thumbnails you might have currently set as custom NNt.ext thumbs, by just tweaking your existing tags to add a width="value" thumbnail="2".

Then, when/if you like it, you can go to the back-end and bulk update your existing thumbnails to automatic so from that point on, it becomes the default for all new images unless you explicitly override it. I think it still sets the per-user pref on thumb creation so it uses the ‘last’ chosen system for future thumbnails. Either none, custom, or auto. Not sure if that’s a good thing, lol, but it’s kinda the way it’s always worked.

What if we delegate all ‘auto’ functionality to <txp:thumbnail />, which currently is just (more or less) an alias for <txp:image thumbnail />? This way, without any ambiguity, setting width or other parameters would trigger thumbnail generation.

By all means try it. I’m just concerned that anyone who has an existing site with width="value" set in their <txp:thumbnail> tags will get a surprise when their carefully-crafted thumbnail images they’ve specifically uploaded to be different from the main image for art direction purposes, suddenly get replaced with an automatically-generated pic on upgrade.

Last edited by Bloke (Today 18:11:36)

etc · Today 18:17:46

Cool, less work :-)

Bloke · Today 19:10:28

Okay, the 308 works a lot faster. Instant on localhost and near-instant on my live server. Woohoo.

However… try this:

Generate your admin-side thumbs.
Visit the cache in file explorer.
Delete all the thumbnail subdirs.
Revisit the Images panel.

Expected outcome: Thumbs regenerated.

Actual outcome: Broken thumbs, until you force refresh.

Same on public site via <txp:thumbnail> tags.

By design? Just me?

EDIT: further, after you’ve force-refreshed to regenerate the thumbs, click through to the Edit panel. The automatic thumbnail is missing there too, until you force refresh.

Last edited by Bloke (Today 19:18:13)

etc · Today 19:30:43

Misery. 302? 307?

Bloke · Today 19:36:44

etc wrote #341835:

Misery. 302? 307?

Not with my tests. In fact, if you delete stuff from the cache, any 30x (including 301) doesn’t regenerate thumbs now unless force refreshed :(

EDIT: is that to do with the location of the redirect in the serveRenderedImage() method? Was it better in serveFile()? I dunno.

Last edited by Bloke (Today 19:38:16)

Textpattern CMS

Textpattern CMS support forum

#229 Today 07:28:13

Re: Automatic thumbnails for Textpattern

phiw13 wrote #341820:

#230 Today 11:29:27

Re: Automatic thumbnails for Textpattern

Bloke wrote #341812:

jakob wrote #341813:

#231 Today 16:18:49

Re: Automatic thumbnails for Textpattern

etc wrote #341824:

#232 Today 16:23:00

Re: Automatic thumbnails for Textpattern

etc wrote #341824:

#233 Today 16:52:51

Re: Automatic thumbnails for Textpattern

Bloke wrote #341825:

jakob wrote #341826:

#234 Today 17:39:28

Re: Automatic thumbnails for Textpattern

etc wrote #341827:

#235 Today 17:56:59

Re: Automatic thumbnails for Textpattern

jakob wrote #341714:

#236 Today 18:07:02

Re: Automatic thumbnails for Textpattern

etc wrote #341829:

#237 Today 18:17:46

Re: Automatic thumbnails for Textpattern

#238 Today 19:10:28

Re: Automatic thumbnails for Textpattern

#239 Today 19:30:43

Re: Automatic thumbnails for Textpattern

#240 Today 19:36:44

Re: Automatic thumbnails for Textpattern

etc wrote #341835:

Board footer