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.
That's good to hear. How did you solve it? If you've gone back to your old API Key then there could still be problems with old settings being there. Let me know, so that I can clean them up.
Hi Martin, vacation was nice thanks. We were on the opposite site of the state (Victoria) from where the bulk of the fires have been happening. The scale and damage across the country has been enormous, and heartbreaking to see.
I've fixed the issue with the Publisher upgrade. There had been some conflict with the various upgrade scripts both within the Backlight 1 series and the upgrade to Backlight 2. Does that solve the problem you were having?
There are a large number of albums within the Publisher that don't actually exist under galleries/ Do you know how that came about?
I think a possible cause could be your old API key still kept in the database. Can you provide me with a Backlight admin login via email so that I can look into this and clear out the setting if needed?
Thanks Stephen. Can you check that the API URL is set exactly to this:
http://stephencase.ca/casefamily/images/familyphotos/backlight/publisher/Hi Marty, please see my email reply that I just sent.
Can you post the actual address to your site here, so we can advise?
Hi, that should work well. Extract the files from the installer zip into the directory public_html/mysubdomain.com
The 'backlight' directory is one that's already part of the file structure from the zipped files.
Hi Paul, that's great to hear. Thanks for confirming!
Hi Paul, sorry but I bungled the deployment (it's been a while between updates). Can you please download and update the LR Publisher again?
Hi Dave, GoDaddy's security mechanisms will be the issue here. There's not much that can be done. Some (of many) users have had success by hounding GoDaddy's support, but I'd say any efforts to get them to make changes to fix this will be futile.
These are all symptoms of the same problem. Please email me access so that I can try and solve this.
Hi Rick, I've deployed an update that should fix this. Please give it a go and let me know in the other thread whether it solves it for you: http://community.theturninggate.net/vie … 126#p63126
Logging problem solved - the latest LR puts log files in a subdirectory of Documents called LrClassicLogs.
I've deployed an update that should address the minimizeEmbeddedMetadata issue. I haven't been able to replicate the problem but can see where it was being caused. Please download the the latest LR Publisher, version 4.0.10 from https://get.theturninggate.net/install/ … r/release/ and update it on your desktop.
Can you let me know if this solves it?
I'm on the verge of deploying the 'minimizeEmbeddedMetadata' fix, but have run into a problem with my own Lightroom setup -- it seems that LR isn't able (or willing) to log to the ttg.log file in the Documents directory under MacOS Catalina. Once I get this working again I'll verify the fix doesn't break anything and deploy it.
As the systems administrator on a dedicated machine, my approach would be to do the following for all directories that a site (e.g. Backlight) has to be able to write to:
1. Change the group of the directory to the group that Apache is configured to write files as. On my local setup, that group is specified in the Group setting in httpd.conf
2. Change the permissions recursively to allow users in the group to write to those directories
e.g., if the group name is apache:
sudo chgrp -R apache /var/www/html/mysite.com/backlight/data /var/www/html/mysite.com/galleries
sudo chmod -R g+w /var/www/html/mysite.com/backlight/data /var/www/html/mysite.com/galleriesThis assumes that you have the necessary permissions to become the root user, in order to run those commands and in order to delete or move the directories and files that Backlight has created as-needed in the future.
I've found something that may be the cause. Have you embedded a top-level gallery in the page? (e.g. Galleries)
Have you upgraded from Backlight 1 recently? There was an upgrade step in version 2.3.4 that added the template to the top-level galleries. 2.3.4 is part of Backlight 1 (BL2 is using version 3.*). This upgrade step should have automatically been performed either during the BL1 upgrade process (if you'd kept it up to date) or during the upgrade to BL2.
Can you log into Backlight and visit the Publisher page, to see if there are any additional upgrades performed that may solve it?
For now, assuming the above is correct about embedding a top-level gallery, a possible workaround is to change your menu to instead point directly to the top-level gallery rather than to the page instead. However that may still have errors if the above upgrades haven't been performed.
Something's gone wrong, but I'm not sure what. I've looked through the code, and the $album variable should always contain a template field. Can you email me an FTP login, Backlight login and details of which URL you are seeing this error at?
Closed a similar topic: http://community.theturninggate.net/vie … hp?id=9087
This is proving to be very difficult to fix. I'm still looking into it.
Further conversation can be found on this newer topic: http://community.theturninggate.net/mod … =10726&p=1
That's great. I'm glad to hear.
Hi. There is not meant to be a publisher/ directory -- this is handled dynamically with the .htaccess file. Can you make sure that the API URL starts with either http:// (if you don't have an SSL certificate) or https:// (if you do). If that doesn't help, then please send me an email with your site details: URL of your site and Backlight admin login, so that I can look further into it.
Check that data and data/sessions have the same permissions and ownership. If not, change those for data/settings to match data.
Thanks Tom and thanks John! Wishing you a very merry Christmas and new year. Thanks for your support.
I’m sorry to say but it looks like your server has been hacked and what’s in your PHP files is malicious code.
Do you run WordPress on your server?
Matthew wrote:So the point of the thing is just to open the link in a new window. Try instead:
<a href="..." target="_blank" rel="noopener">...</a>Thanks for the code idea, it seems to work. But the actual point was why iframe and onclick won't publish via the LR plugin, but will publish OK using Backlight publisher in a browser. I have trouble getting my head around this -- how can this be a BlueHost problem? Maybe it can, but I can't see it.
The clients are two different technologies. Lightroom submits the form data in a different way to how a web form does. LR submits parameters as a JSON object with a checksum produced from the API Key and contents of the JSON object. The web is just a form submission. Two approaches, one of which seems to get past whatever mechanisms Bluehost has in place, one of them that doesn't.
At this point this is bordering on a won't-fix status. An edge case on one host with contents that the fields are not intended for when we provide a more robust and better-suited approach in PHPlugins.