Support community for TTG plugins and products.
NOTICE
The Turning Gate's Community has moved to a new home, at https://discourse.theturninggate.net.
This forum is now closed, and exists here as a read-only archive.
You are not logged in.
Thanks. The key point here seems to be Bluehost. It is rejecting the requests with iframes and onclick in the contents. I've been able to replicate it with my own Bluehost account. It's likely to be a security layer called mod_security. This intercepts requests on the server before they reach Backlight. I haven't yet found a way to disable mod_security, to verify that it's the cause.
Looking into this, this looks to be a server issue. Perhaps a security layer that is balking at receiving submissions that contain JS and iframes, which could be construed as a cross-site scripting attack. Are you running a security layer on your server, such as mod_security? If so, can you look for errors in the security logs, or if you're able to, temporarily disable the security service.
On that, who are you hosting with?
Note that we only classify something as a bug after triaging it. A failure on your setup doesn't necessarily make it a bug in our code. As this can't be replicated by others then that does seem to be the case. It works without issue with me, using LR on a Mac.
As Matt has suggested, we strongly recommend other approaches when trying to add code to pages, irrespective of the cause of this particular problem.
1) 'minimizeEmbeddedMetadata' error - I have a fix for this, which will go through the normal updates.
2) Concurrent error. No fix likely. This is a low-level issue with how LR executes code.
3) Code within Copy fields. I'll look into it, in case there's something that can be improved in terms of escaping special characters. However, that's looking unlikely since the code works for some and not for others.
Can you post the onclick code here.
FWIW, copy fields were only ever designed for copy, not complex markup and JavaScript. I will have a look to see whether there’s anything in our code that can enable this but I can’t promise anything.
Can you see whether the Publisher entry within the LR plugin manager shows any errors immediately after seeing this issue? Also if you can find the ttg.log file in the Documents directory of you Mac immediately after seeing the error, and email it to me?
These are two distinct issues.
The minimise metadata issue is caused by our code trying to print a value that's invalid. I have never seen this happen, and can only surmise that this is triggered by publishing multiple albums, under certain values for metadata. I'll put in a fix for this.
The stack overflow error is caused by what looks to be a bug in LR when it attempts to publish multiple albums in parallel. This should only happen if you start publishing to one album while another publish is in process. This should not happen if you trigger a single publish action by instructing LR to publish all albums in an album set. In that case, LR will publish to each album one by one.
I've found what looks to be the problem, and it is a bug. Everything is ordered nicely when returned from the server, but the programming language (Lua) that the LR plugin is written is ignores the ordering when getting the values out. I'll try and work out how I can get the code to honour the order.
Hi Neville, I've only just had a chance to look into this. In my testing custom thumbnails are being returned in alphabetical order.
In my list I get the following:
Random
Custom
[the list of images in alphabetical order from custom_thumbnails under the album on the server]
[the list of images in alphabetical order from thumbnails under the album on the server]
Just to confirm: is this an issue with the drop down you're seeing for Cover Image when editing *Albums* (not Album Sets) within Lightroom?
Can you email me a screenshot of the list that you're seeing in Lightroom, and also a screenshot of the contents of your custom_thumbnails directory in the respective gallery?
Thanks for that, Mark. In that case, you don't have the latest version. Can you download the latest Cart zip file, named Cart-416.zip, and replace the contents of the backlight/modules/cart/ directory?
(FYI, the difference in that one file is line 8, which should look like the following. There are other changes across various files, so the directory needs to be updated with the latest
protected $errors = array();)
Hi Mark, unfortunately the manual updating process of Backlight 1 makes it hard to make sure that we've provided the right files and that you have them.
Can you view the contents of the file backlight/modules/module-cart/application/models/OrderDetails.php on your server, and paste the top ten or so lines here?
Hi Mark, this was addressed in an update a year ago. Can you download the latest version of the Cart and replace the directory on your server backlight/modules/module-cart with the same directory from the zip file?
What error did it end in?
Hi Mike, there are a number of classes added to the <body> tag that can be used by CSS to target specific albums and templates. For example, on your album at http://www.michaelrichardsphotography.c … y/c-olden/ there are these classes (amongst others):
template-identifier-Bez-Tray
album-template-id-143
slug-c-olden
The first two can be used to target all galleries with a given template (one using the identifier, and the other the unique ID that Backlight uses). The last can be used to target just galleries with the slug c-olden. That will apply to any galleries with that slug. It doesn't look like we provide a class that targets a specific gallery, but the chances are that the slug is unique across your galleries.
Hi Rainer, I'm not sure why that fix hasn't come through. Can you send me FTP access so that I can look into it?
The second error is something I will need to fix for both BL1 and BL2 before they will work properly on PHP 7.4
In recent years it usually hasn't been necessary to alter permissions at all; hosts are configured to be able to write to locations as needed.
There's no universally correct set of permissions that will work across all environments. The permissions and ownership needed for the server to create files and directories as-needed can vary from host-to-host.
A reasonably-safe set, if you do need to change them is:
All directories: 755
All files: 644
1) Safer still would be these for these directories and contents within them for backlight/data, backlight/modules, 'galleries' (and other top-level gallery directories):
directories: 755
files: 644
2) And all other backlight/ locations
directories: 555
files: 444
777 is dangerous, especially on shared hosting. Any rogue script or user under any user account on that server can overwrite your directories and files.
A good way to test what your server is configured to set writeable locations, is to create an album through Publisher or Backlight admin, then log in via FTP and check the permissions of directories and files within the newly-created album.
We've resolved the problem. The Backlight 1 to 2 upgrade moves database tables around. Earlier Backlight 1.* upgrades also try to upgrade the same tables. Fixed by checking for the existence of the localisation_value during the Backlight upgrade step to 1.1.0. I'll add this check into the deployed code, so that it won't affect any other users upgrading from an earlier version of Backlight 1 to BL2.
Hi Brian, this is likely an edge case in the upgrade process. Can you please provide me with a Backlight admin login via email, and preferably with FTP access as well? I’ll then look into it and hopefully get you on track.
I hope you got *some* insight into my earlier answer even if it wasn't what you needed.
Since you are in the EU then it's a moot point, isn't it? We can adjust the logic if Brexit ever happens.
OK - I can answer my own question, although I had to look at the code in ShoppingCart.php, function tryingToSellVirtualItemsToBlockedCountry()
All you had to do was wait a reasonable amount of time for a response rather than trying to reverse engineer the code.
The restriction on digital purchases to other EU countries is precisely due to the tax complexities. Handling all of the tax variations is beyond the scope of the Cart product, so we added that option so that photographers wouldn't be able to sell digital copies locally without having to be concerned with sales to other European countries that may not be their intended audience. If you do plan to sell to other EU countries then the onus is on you and your business to manage your tax obligations. We are simply too small a team to deal with complexities like this.
Hi Andy, when digital downloads are set to be taxed and other-EU country is set to no, customers will see a country dropdown on the main Cart page. Changing that to any EU country that is not the UK won't let you checkout. If set to the UK and the customer checks out through PayPal, then the country information of the user account is sent back to the cart, and if from another EU country, the user will not be able to finalise the checkout.
Hi Andy, the sale is restricted based on the country of the buyer as specified during checkout.
No updates yet. It’s on my list. Not a bug.
As a side note, the graphical PayPal buttons are a real problem to deal with. The former location that we drew the images from has disappeared and I’ve been unable to find a replacement. So for now it’s the one button, or text.
I've just applied the patch to the publisher. To update it:
1. Visit Backlight Module
2. Click Reinstall on the line for module-publisher, if the link is present. Otherwise click Reinstall All under Backlight 2
There is no requirement to create a folder. There is only the requirement to transfer everything from within the zip to the location on your server where you want the site to reside. How you manage that is up to you, and dependent on the software on your PC or Mac, and your preferred workflow. e.g. creating a folder and unzipping into it, or browsing the zip file and dragging the files to the location open in your FTP software. This is basic stuff, and to date you are the very first person to have trouble with this. I feel that you are projecting your frustration on to us and that it completely negates our efforts to assist you; here we are exchanging a lot of words about this while you still don't even have a working site. Priorities.
The base Backlight files that you upload to your server are structured for a reason. There is a lot of history to the product with a great deal of experience built into the process that accounts for permissions, a variety of server environments, and ease of upgrade. Once you are up-and-going and have updates to apply you might start to appreciate the structure that the initial files put in place. It is semantically almost identical whether you upload the 'only' single file onto the server, or update 'all' contents of the zip. The contents are minimal and take just a few seconds to upload.
I don't know of many single file installations. Wordpress, the most popular CMS in the world (analogous to Backlight, which is also a CMS), requires uploading 1,907 files totalling 48 Megabytes. Backlight requires only 44 files totally 336 Kilobytes.
Now, what else do you need to do to complete the installation? I have FTP access, but at the same time you have already realised the steps I outlined above that you have missed.