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.
Also, see that the info icon on the WordPress URL allows for a relative path. If both your blog and Backlight are on the same server then using this approach should work.
For example if your server had the following directories:
yoursite.com
blog.yoursite.com
Then a setting of ../blog.yoursite.com should work.
A workaround would be to create the wp-content/themes directory where Backlight is expecting it, and then after exporting the theme from Backlight, manually copying the saved files into the equivalent location of your blog
Hi Nico, I’ll look into this. I’m not sure whether we’ve ever looked into support for Cart-enabled embedded albums.
Hi Peter, can you provide me with the Publisher database file via email or Dropbox, so that I can run performance tests on my PC?
The file can be found at backlight/data/publisher/master.sq3
It’s probably quite large, so may need to be zipped before sending.
Also, it would be helpful if you could provide me with FTP access and a Backlight admin login.
It's likely a combination of too many images and an under-resourced server. Who are you hosting with, and what kind of plan are you on? (e.g. shared, dedicated server).
I've almost completed getting the main Backlight functionality working without needing URL rewriting. That is, galleries, publishing, etc. Which other plugins do you use? Cart, Client Response, Galleria, Theater, Wordpress?
Since this remains as much a mysterious as a recurring problem, I thought I'd add some more technical information from the PHP-corners of my site/host hoping that you "cracks" might discover some trace of a structural solution.
I’m glad that it’s working, but there is no possible structural solution to our code. This error occurs outside of our code before any of it is executed.
Sorry, I keep getting dragged away by other tasks. I will revisit this, again.
Thanks for the kind words, John! Here’s to the next twelve years.
^ That’s very helpful.
This entry in your own php.ini file may work:
mail.log = /dev/null
That sends any logging to the null device, effectively making it disappear rather than try to write to a file.
That sounds like a misrepresentation of our software. As I wrote in the other topic, the issue is a misconfiguration of your host. Backlight does not attempt to write to that location or that file. You’ll need to push harder with your host’s technical support.
Hi LeMa, that sounds like they didn't look closely at it. There's nothing that can be optimised in code to fix the slow speed of static files, which I see as an indicator of poor server performance in general. Backlight is already heavily optimised, using an efficient caching mechanism and cache headers for files.
Backlight should be performant for sites with tens of thousands of photos. Do you have that many?
Have you removed Backlight from your server? I can no longer reach it at http://www.world-traces.com/backlight/
Thanks for the access details. It looks to me as though your host is just slow in general. For example, static images are taking far longer than they should. This image took over 4 seconds to load: http://world-traces.com/f1galleries/f1_ … D-7949.jpg
A similar sized image on my own site (shared hosting at Bluehost) takes about 0.3 seconds to load.
I suggest taking this up with your host. There may be more load on your server than there should be. They would need to either provision more capacity, or move you to another physical server.
Your host is blocking calls to the gmail server. This is quite usual.
Your best option is to send using the ‘mail’ setting rather than ‘smtp’, and setting a from address that matches your domain.
Hi Michael, that's an interesting approach. Have you looked at using sessions instead? Ephemeral data related to site visits shouldn't need to be saved in a database.
Hi Michael, can you share how you solved this? My comments about wholesale updates to the Cart don't apply to CR or Backlight as a whole.
Hi Patrick, if Rod's suggestions don't solve it, please provide me with FTP access my email so that I can look into it.
When does this error happen?
You'll need to take this up with your host's technical support. This error occurs outside of Backlight code execution. There's nowhere in our code that attempts to write to that location.
Sorry I'm late to the party. The exif_read_data could probably be solved by reinstalling the Backlight Publisher module. To do so, visit Backlight Modules and click 'reinstall' for the line relating to Publisher. That should solve it for publishing from LR, but will still leave publishing from Backlight broken, until the exif module is added to your site.
Can you provide me with FTP access via email so that I can look into what's causing the 500 error?
It should be compatible. I'm not aware of anything in the BL2 Publisher that would break in LR5.
Some information on the compatibility between our two LR plugins: There are two things that make a Lightroom plugin unique - the install location and the unique internal identifier. To have two operational Publisher plugins, both need to be unique. The install location is straightforward. The plugins have different names so will appear as different sets of files to LR. We only use two internal identifiers. One for the CE3 plugin, and another for the CE4, BL1 and BL2 plugins. That means you can have operational plugins for CE3 and one of CE4, BL1 and BL2. The BL2 plugin is compatible with CE4, BL1 and BL2 websites, so there is nothing missed from only being able to install one of the CE4/BL1/BL2 plugins.
We still endeavour to have CE4 work on the latest version of PHP. What errors are you seeing?
The Category is only used for mixed pricing and only saved when mixed pricing is enabled in the associated template. In that case it can be retrieved with:
$photo->getMetadata('itemPricing');
Edit:
Another way of getting this would be to set either the Metadata One or Metadata Two field in your album template to {Caption}, republish the photos and then get the value with either:
$photo->getMetadata('metadata_one');
or:
$photo->getMetadata('metadata_two');
That approach would be independent of any cart settings.
Hi Pierre, please check your email.
Backlight 2 does not store plain text passwords, so is unable to retrieve passwords. All it can do is provide links to reset the password. When you visit the Forgotten Your Password? link, if the Username and Email are found, then an email is sent out, and also, the reset link is logged to the latest file under backlight/data/admin/logs/. For example, after trying it on my development environment, I have the file:
./backlight/data/admin/logs/2019_03_08.log
containing the following contents:
[08-Mar-2019 20:38:13] TRACE: To reset your password, visit the following link: http://backlight2.local/backlight/admin/reset/339c22e403d7063cd630fa2f1b279da4d1c25b18/
The logging is useful as a fallback when emails aren't going out or being received.
Of course, that won't help if Backlight doesn't recognise your username or email. Have you set an email address for your admin account? After installing or upgrading to Backlight 2, you should have been prompted to update settings on the next login, including adding an email address to your admin account. If you hadn't set that, then there probably isn't an email address associated with your admin login.
If that's the case then the only way to solve this is to edit your database directly. I can do that for you if you can provide me with FTP access via Email.
Oh, I forgot that with Backlight 1 there is no need to login in order to upgrade..... Installing the latest version should fix this issue.
Another trick, in Backlight 2, is to visit backlight/installer/ again. Doing so will fetch the latest core modules (e.g. admin, framework, designer, publisher, pangolin-* modules) and install them over the versions of the modules that are already there. That should help recover from any code issues within the Backlight admin that prevent logging into the Backlight admin in order to update modules. That of course assumes that the installer code doesn't have issues on that server.