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.
Wordfence provides a valuable defence, so I wouldn’t suggest leaving it switched off.
I’m looking into a way of detecting that notices and warnings are generated outside Backlight and ignoring them rather than displaying errors. Once I have that working Wordfence and publishing should play nicely together.
On second thoughts, this looks to be Wordfence doing it's thing, and not the insane line that I mentioned above. The steps above may still solve it. Another option may be to configure Wordfence to exclude scanning of requests made to /backlight/ and subdirectories. I'm not sure how you'd go about doing that.
Can you email one of the images that is giving you issues?
Hi Mark, fist of all please don't spend hours and hours on issues like this. We're here to help via the forums or email.
[EDIT: please see my post below]
Wordfence has added an insane line of code in rules.php that throws and attempts to suppress an error. I'm not sure why they're doing it, but it causes Backlight to throw errors. To get around this:
* Visit Backlight > Backlight Modules
* Reinstall the Backlight 2 Framework Module, by clicking Reinstall next to the module-framework line.
* Copy the file backlight/env.php.skel to backlight/env.php
* If the file already has this line in it:
//define('SUPPRESS_NOTICES', true);then uncomment it by removing the leading slashes so it looks like this:
define('SUPPRESS_NOTICES', true);or just add the line like the second example above.
I’m glad that worked. I suspect that with your initial approach the .hfaccess file continued to do additional processing after the 301 line. By using RewriteRule, there’s the opportunity to tell the web server to stop processing further rules after that rule matches. That is what the “L” in the square brackets does.
Hi Pete, the logout link for BL2 should point to http://yoursite.com/backlight/clients/logout/ (replacing yoursite.com with your actual site URL).
That's strange. I usually find that control panels are completely separate from the main site, typically at a different URL or port.
Can you check whether there is a folder within public_html called cpanel, and whether there is an .htaccess file within it (you may need to tell your FTP software to show hidden files). If there is a directory, but there is no .htaccess file then try creating one with the following contents and see whether that solves it.
<IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>For the contact page problem, can you share your site URL and which addresses aren't working as expected?
This rule should do what you need, added directly under RewriteEngine On:
RewriteRule ^travel$ http://yoursite.com/gallery/gallery-travel/ [R=301,L] Change yoursite.com to your actual site URL. I've tested this, and the other .htaccess rules still work as expected.
Thanks for the access. I can see the problem now. The check for valid Album Title looks for any type of letter, from English to Chinese characters. But I didn't realise that all-numeric titles aren't included in that test. I've put in a fix in my working code, which will be updated in the next maintenance release.
Hi Edwin, can you please provide a Backlight admin login via email so I can look into this?
The first issue isn't something I've come across. Can you share a Backlight admin login and details of an album via email?
The publishing mechanism hasn't changed between Backlight 1 and 2. That's either been an ongoing problem from earlier versions, or something that's come about as Lightroom has been updated. The programming interface with Lightroom is quite limited, so there's not much we can do to improve the handling of cancelling tasks. Some of the problem may be due to our approach to have multiple rendition published for each photo and that not playing well with the task lifecycle management within Lightroom.
Hi Mark, it's strange that the metadata is broken on that one image. Can you email me another image from Capture 1 that does upload? I'll see how the metadata structures differ.
I've found the problem. That image has broken metadata. There is a tag to start the metadata (An XML opening tag for xmpmeta) but there is no tag to denote the end of the metadata. The backend is therefore trying to scan the entire image to find the end of the metadata, timing out in the process.
Where did the image come from? Any application that you've exported it from? If so, I suggest exporting it again and trying that image.
Thanks, Mark. I can see an error on my side - Maximum execution time of 30 seconds exceeded in XMPMetadataSource.php on line 164
Fetching the metadata from the image should only take a second or less, so something is amiss there. I'll look into the code and see what can be done.
Please email me one of the images that is failing, and also provide a Backlight admin login and details of an album you are trying to upload the image to.
Hi Pete, that's the most suitable way of contacting me.
Hi Pete, there was a bug in the file backlight/.htaccess that prevented 2fa from working. I suspect this is what you’ve encountered. To get around this, visit Backlight > Backlight Modules and update to the latest modules, then on the main Backlight admin page visit a link called Update Index Files. You should then be enable 2fa and use it.
If that still doesn’t help then please provide me with a Backlight admin login and FTP access via email so that I can look further into it.
See if this helps: http://community.theturninggate.net/vie … 223#p55223
Hi Pete, can you explain more about "that was it. No access was granted to BL2". What did you actually see? A blank page, error message? Can you provide a link to your site?
We've thought about notifying you when you log in, but that would cause a delay upon every login as your website would need to check for updates from our website. Depending on the host, that delay could be several seconds. To see what the delay would be like, click on Backlight > Backlight Modules. You should find that the page takes longer to load than other Backlight admin pages.
Hi Rainer, we support PHP 7.2. I am not aware of any issues between the latest version of Backlight 2 and PHP 7.2. If there are any issues that you encounter then we will fix them as soon as reasonably possible.
There isn't a class called 'Requests' within Backlight, so this looks like an issue in your WP includes not finding what they need to find within WP itself.
Hi TBC, can you provide a Backlight admin login via email so that I can look into this? It would also be helpful to have FTP access.
Backlight updates are handled from within the Backlight admin page. Have you visited Backlight > Backlight Modules and updated any modules that have new versions available?
It just needed the main index.php file to be uploaded
Hi Barry, please see my reply to your email. This is something related to PayPal not returning an order number.
Hi Xevi, looking at the album I see that the images that can't be sold have a pricing scheme set to '15'. As there is no such pricing scheme in your cart, the photos come up as being unable to be sold. That's most likely set in the Category field for the photos in Lightroom. Does that look to be the case? If so, does '15' make sense as the name of a pricing scheme?