Community @ The Turning Gate

Netcraft ranking are a moot point for our products.  Nginx is not at all common on shared hosts, which many if not most of our customers are using.  One of the main reasons behind that is the reason we're here in this thread: lack of .htaccess support, and no way of getting rewrites going without being the web server admin.

Hi Bernard, we're working on Backlight updates.  I'll look to put a fix in for this.

Can you share details on your server setup?  I'm assuming that you're running Nginx behind a proxy of some sort?  The code that had a bug in it yesterday is using logic that doesn't make sense to me -- it detects that the outward-facing URL does not include a port, and then adds the port of the backend web server to any URLs.  So if you were visiting a site on a URL like this:
http://yoursite.com

That in turn proxied to Nginx on something like this:
http://127.0.0.1:8888

The web site would end up using URLs like this:
http://yoursite.com:8888

Which is incorrect.  The logic should be the other way around: if the back-end web server indicates that it's running on a non-standard port, to omit that port from any URLs sent back to the browser.

Something important for you to note.

Without mod-rewrite support, you'll need to add lines into your Nginx config to prevent access to the data files and digital purchases, if you're using those with the cart.  To do that, see the Wiki documentation for Nginx, on Backlight 1:

http://backlight.theturninggate.net/doc … web_server

In particular, your server config should have these two entries:

# protect against direct downloads of data files
location /backlight/data/ {
    return 404;
}

# protect against direct downloads of digital purchases
rewrite ^(.*)/(.*)/photos-for-purchase/* / last;

Ignore further URL-related entries in that document for now.

Further again, try visiting /backlight/ on your server.  It may just be that the 'continue' link doesn't work.

Thanks for testing it.  Wait for me to fix it.  I'll look into this tonight.

Hi Perry, can you provide a link where we can see that error?

Hi Michael, I meant to follow up on your post.  I don't believe there is such a thing as a standard PHP environment.  There are two aspects in which environments differ: feature support and configuration.

Upon seeing your post I downloaded the full PHP source code and compiled it from scratch to see what features vanilla, unadulterated PHP provides.  The vast majority of functionality is compiled in by default, but some functionality that I would consider quite generic, is not compiled in unless explicitly configured.  That includes features such as multibyte string and exif support.  The list of optional features that ship with the PHP source code is not extensive, and since it comes from the PHP project itself so should be of pretty dependable quality, I can't see why hosts wouldn't compile in most, if not all, of them.
To see what has been built into the version of PHP on your server, click on the View PHP Info button on the Backlight landing page and look for the --enable flags in the Configure Command section.

Configuration is another kettle of fish.  There are a myriad of settings available to system administrators through the php.ini file and huge scope for them to mess something up.  PHP is unique in that the language features themselves are also configurable through the php.ini file.

All I can suggest is that you use a well-reputed host, and if you encounter configuration issues, that you hound the technical support to fix it.  We have jumped through hoops over the years to make our code as portable across hosts as possible, but there are some misconfigurations that we can not code around.  A host configuring the PHP mail log to a location that is not writable is something beyond our control.  It is so far out of our control that even if we stripped out all emailing functionality from our code, the error would still exist.

I realise it's frustrating, but that's the state of the PHP world, which unfortunately is the only option we have for ubiquitous back-end language support.  If I were deploying PHP code for a business (which I do for my day job), I would avoid shared hosts altogether.  The only dependable way of running PHP in a state that doesn't break over time is to manage your own server.  I'd love to offer a hosted solution for TTG, but we do not have the resources to do so, and it also goes against the grain of self-hosted sites that is the target of our software.

I can see it, thanks.  Is this an example: Clicking from this page to "Afrique Sud 1": http://www.bleverd-photo.net/galleries/ … single.php

It's not advisable to run early betas such as Catalina on work machines.

Hi Perry, I've found the problem and fixed it on your site.  The client info for editing clients was being drawn from the old clients table from the Client Response database.  This needed updating to instead draw the client details from the clients table of the Admin database. 
The location changed with the upgrade from BL1 to BL2, but this query had been missed.

I'll release an update to CR to address this in coming days.

Hi Scott, please see my reply to your email.  This should all be good now.