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 Daniel and Ben for your support.
Bernard
Hi Daniel,
Thanks, it's OK now!
Bernard
PS : BTW, do you know what's the problem ?
Hi Rod,
I have tried with another browser, same result.
Since last time when it worked, I changed nothing at all.
If I remember, it was solved last time by Ben moving the TTG server to another host.
We were several users hosted by OVH to have the same problem.
Bernard
I had this problem in the past, it was solved , and now again I can't access backlight modules.
I am using OVH in France.
I am currently at 2.0.10 , would like to update to 2.0.14
Error message :
Something went wrong
Backlight was unable to connect to https://get2.theturninggate.net. Please wait a few minutes and try again.
Thanks,
Bernard
Thanks Ben !
Bernard
Hi Ben,
Have you been able to find something concerning this problem ?
Thanks,
Bernard
The URL to 'afrique Sud 1' looks completely wrong.
Bernard
It happens only after doing some navigation using the left and right arrows (upper right corner).
Before navigation it's ok.
Link to the site via http ?
www.bleverd-photo.net
Hi,
I have a similar problem : intermittent 404 error, but only when I go one (or two) level higher via bredcrumb.
.htaccess is present at the root, and I have only one menu set.
Thanks,
Bernard
Hi Ben,
I tried to update to 2.08 and again got the same problem : "Your sendowl orderid ....". (I had cleared the cache before)
I know Regine (also using OVH host) was able to upgrade approx 3 weeks ago.
Bernard
Yes the production is functioning as it should, from a browser.
From LR , I have edited all albums, except one or two on purpose to be able to do further tests that you would require
Bernard
Rod, yes the publisher instance used for the test site is now set to publish to the production site, the API url has been changed.
I did what you suggested, deleted an album from the test Publisher, and it went ok : the album was deleted in test (and not in production!).
Ben, before doing an edit on the album :
'go to published' functions in LR do not work , but modify a photo and republish, delete a photo , add do work OK.
after an edit on the album :
everything I tested in LR (and checked in the browser) went ok in production : go to published album or photo, change a photo and republish, delete a photo and add a photo.
Bernard
Hi Rod, let's take one album containing one photo, from LR 'go to publish album' or 'go to published photo' point to the wrong URL.
As I understand it, any change you do, edit the album (without modifying anything) or republished the photo is performed by the plug-in with the URL defined at the publish service level, so production, and then is shown correctly by a browser.
The 'exception' is : if one photo is republish, the photo then becomes OK, but not the album's URL.
As far as I can see now, to set everything right, one has to edit each and every album without modifying anything, and then all URLs are ok, same as defined at the publish service.
I did not try to delete an album or a photo, as I don't know what is involved, the plug-in and/or LR.
Bernard
Hi Ben, thanks for this very interesting info.
It confirms what I thought and which is not documented anywhere : within the TTG publish service environment, target URL is not only defined at the publish service level, but also duplicated at the album and photo levels.
I guess that the URL at the publish service level is used by the plug-in for publishing, and the URLs at album and photo levels are used by LR for displaying.
That's fine, except that the procedure I used to migrate from test to final is not correct. Unless I missed something, that procedure is the one mentioned in this forum and related sites. An official procedure should be published in the TTG documentation ?
I will use your info to update my final LR environment, and keep you updated concerning the third scenario .
Bernard
Can someone reproduce this issue ?
Thanks,
Bernard
Yes, latest version of LR publishing.
It was strange, I checked several times, several images...
Bernard
If I select one photo and republish with update metadata only, 'go to publish' photo goes to the test URL.
If I select one photo and republish without update metadata only, 'go to publish' photo goes to the www URL.
If I select all photos of an album and republish without update metadata only, 'go to published' photos goes to the www URL, ok, but from the album, 'go to published album' still goes to test URL.
If I select the album and republish without update metadata only, 'go to published album' photo still goes to the test URL.
Bernard
When my test site was ok , I migrated following some advice I saw here :
Using Filezilla FTP, I downloaded the test folder to my computer : everything, BL2 and galleries.
I then uploaded the whole thing to the root of the site,
changed the LR publish service (API URL),
changed BL2 settings (site and company URLs)
and everything was looking OK : from Firefox, using the test URL is going to test, and using www is going to the final site.
But from LR, it's a different and strange story.
In the 'www' publish service, from an album, 'goto to published album' goes to test URL
and right click on an image, go to published photo goes to test URL.
And if I select one or several photos and publish them again, the album displayed is from www, and right cliking on these photos will show them with the www URL.
Bernard
Hi Ben, it works for me as well !!!!
Would be interesting, just for curiosity, to know a bit more why it works now ?
Bernard
Hi Ben,
I did a test this morning and gave the time stamp to OVH support.
Looking at the log, their answer is 'we see the connections and from our side all web requests went thru' .
I don't know if that log is sufficient for you, will send it to you by pm .
If you need some kind of trace, please tell me what kind, and I will ask OVH.
OK, I found your request for a traceroute, will ask them to do it.........
Thanks,
Bernard
Any help please ?
Hi Richardd,
welcome to the club of unhappy OVH customers, we are now 3 with the same problem.
Please start a request for help to OVH support .
Bernard
Hi Ben, Thanks,
new questions from OVH support :
. is it a script trying to connect ?
. if yes, which one ??? (humm I don't know what they really mean)
. is it a GET request ?
BTW, in the case for which I will send them the timestamp, it was a 2 step process, first the message saying no match with order id, and the second : unable to connect to ...
Maybe it's necessary to give an answer for each step ?
Bernard