Hi @naveenbachwani,
Thank you very much for requesting the Description feature. I have tried before and failed. Based on your request I tried harder – and succeeded 🙂
The NIKON-NIKON info was a small bug. The {camera} placeholder got a bit of intelligence by now and also I exposed {camera-make} and {camera-model} as the pure EXIF info with zero modifications.
Both will be released in 2.0.12, latest this weekend.
Many greeting from a CANON guy 😉
Jan
That’s great to hear! Thanks again for the prompt fixes. Looking forward to putting them to work…
Hi @naveenbachwani,
Please try 2.1.0. You will find there both {decription} as well as improved {camera} and more 🙂
I hope I did not introduce any other issues as it turned out to be a larger version change at the end due to requests from multiple users…
BR, Jan
Thanks, @janzeman. I can confirm that these now work as intended, and I have incorporated both in my gallery.
I am concerned about the notes mentioning: “Each photo requires one background HTTP request (~1 MB). For large albums this adds significant bandwidth.”
1 MB per pic seems a lot of fetch for just a little bit of text. Any way to reduce that? Or call on EXIF type placeholders only on demand by clicking a button eg More info?
Hi Naveen,
The heavy fetch is mostly a cold-cache cost, not something every visitor keeps paying forever.
The EXIF and description data are cached server-side per photo ID after the first fetch, and all later visitors are served from that cache immediately. So for a given photo on a given site, the expensive Google Photos page fetch happens only the first time, or again if the plugin cache is cleared manually.
I did a bit of measuring. The album data is small, and the separate filename probe is tiny. The extra round trip for EXIF is usually less than 1 MB per photo, but it is still not negligible. So the concern about first-time warm-up bandwidth is valid, but I believe the cache is the guard and the remedy here. From that perspective I am not currently convinced that switching EXIF-type placeholders to an on-demand click flow would be worth the extra complexity.
Please check version 2.1.2. I have updated the plugin’s Settings text to make this clearer and to warn users not to clear the cache unnecessarily.
BR, Jan
-
This reply was modified 1 month, 2 weeks ago by
Jan Zeman.
Thanks, @janzeman. The separate links for Album & Metadata cache helps. Do I understand correctly that the ‘cache-refresh’ attribute only clears the album cache, and previously fetched metadata (for previously fetched pics) remains unchanged? If so, maybe you can make that clearer in the description of the attribute for the next version.
My use case is that I intend to keep adding new albums, and new pics to existing albums, which I need refreshed in the gallery being displayed via the plugin. But I don’t need to delete older fetched data, nor add any overload by re fetching EXIF info on older pics. Hope that makes sense.
Hi Naveen,
You understood it correctly. To make it clearer, I renamed it to album-cache-refresh while keeping the old name backward compatible. So in your case, you will only need to click the “Clear Album Cache” button.
In the next version (2.1.3), you will also find a “How the cache works” section with an even more detailed description.
Best regards, Jan
That’s helpful, @janzeman. In my view, the last line of the explanatory note is the key and perhaps should be included in the description at the top.
Great. I will consider it for the upcoming release. Thank you for the feedback!
Just for the record, line moved in 2.1.5 version 🙂
