Community @ The Turning Gate

See my reply above on all the details you need to get you started.

Steen, are you here to criticise or to have your problem solved?
The ‘backlight’ in the documentation is the backlight directory you get from uploading the contents of the zip file. It is the entry point to the admin and not a directory you create and then upload to. Does that make sense?

Plans are on hold.  The implementation is complicated and there is little demand for it and even for the Cart as a whole.

What was the problem and what was the resolution?

It may not be your intention, but the double-talk of praise and damnation doesn't help as we spend time trying to solve this.
We make changes to improve our product for a variety of reasons, some glamorous and others less so.  In this case, we added further protection on key folders that ultimately serves to protect your site from malicious users. 
There are many, many moving parts to Backlight, and many, many permutations of how it is used and configured.  All this across desktop, mobile, a variety of browsers and servers, and upgrade paths and backwards compatibility spanning years.  Sometimes changes cause things to break in ways that we can not foresee.

I have put in an another attempted fix, which is in our _testing_ stream.    Can you take the time to try out the following album: https://somethingchanged.com/photos/hol … ighlights/   1) see whether the links now correctly either force the file to download, where browsers support that function, or otherwise display the image in the browser.  And 2) if the latter see whether images save with the correct filename.

If that still does not work then we have another approach to try.

Those steps remove the .htaccess files from photos-for-download. That is all.

Richard, we're taking time out of our weekends to fix this.  Clearly this is not a straightforward problem to solve.  Those .htaccess files that you curse are part of a system that makes your site possible and aren't put in there for the sake of it.  Be polite.

Unless we've missed something, removing the .htaccess file won't restore the types of links returned to mobile devices.  Are you suggesting that with the .htaccess files intact that you're still getting the forbidden error?

Hi Richard, All files and director is in your photos folders are created by Backlight. .htaccess files are used to prevent direct access to files. Unfortunately that causes mobile users to be unable to download photos-for-download renditions.. Is it the case that those users are using mobile devices?
We have a fix for this in development that should be put in the next week or so. In the mean time, can you try changing your settings in Designer to use the ‘photos’ rendition instead.

Our code runs from PHP 5.4 through to PHP 7.2 and presumably 7.3 but not tested with Backlight 1.

It definitely does NOT require PHP 5.4 or anything earlier than 7.2.  Can you ask your host what specifically he has found that requires PHP 5.4?

From the PHP reference manual, curl_init is available from PHP 4.0.2 to PHP 7: https://www.php.net/manual/en/function.curl-init.php There is no mention of it not being available in 7.3 or requiring version 5.*.

I've run a compliance test on https://somethingchanged.com through Cookiebot, and it returned a result of Compliant.  It found one cookie (as describe above), that it deemed a 'necessary' cookie for the site to run.  According to the report, necessary cookies don't need consent, so the consent pop-up that BL2 does provide should be more than necessary to cover this.
Where things get murkier is in data retention.  That applies to Client Response and the Cart.  Do you use either of these?

Hi Terry, there is a common misconception that cookies are only used to store personal or identifiable data.  Backlight 2 (and Backlight 1) uses cookies for the most benign of reasons, and a reason that just about all dynamic sites on the web do: to know that a page view is by the same browser as a previous page view and use that information for usability and performance.  For example, the site settings and language values are loaded once per session and associated with the user, who is otherwise anonymous.  This improves performance.  When language dropdowns are used, this association enables the server to return pages in the same language as chosen in prior page views.  Without this the user would need to choose the language for every single page load.  For shopping carts and client response, the cart contents and feedback associated to the browser are kept on the server, so that they are not lost from page view to page view.
None of this information is identifiable to the user, and none of it is kept in the browser.  Instead, all that the browser cookie stores is a unique identifier (you can see this by browsing to a Backlight 2 site such as https://somethingchanged.com and viewing the cookies in the inspector - there is one, PHPSESSID).
The identifier and associated data isn't tracked to identifiable information, isn't saved beyond the lifetime of the session, isn't shared outside of the system to us (TTG) or anybody else, and isn't used to track you from one site to another.

Another use case for cookies is to identify logins.  Without knowing that a page view came from the same browser that was logged in to client managed albums or the Backlight admin, there is no way to maintain a log in session.

Hi Neville, I’ll look into this. I had to-date thought the ordering issue pertained to standard thumbnails, so had never been able to see the problem.