Community @ The Turning Gate

IF you're looking for more a more obvious way to submit feedback, the submission form can be launched by any control with the class "submit-large".  So you could add a prominent link to your Page Copy.  For example, this code adds a link named "Submit Feedback" in the page copy:

<a href="#" class="submit-large">Submit Feedback</a>

Similarly, for client-managed galleries, the following will provide an alternative logout link:

<a href="#" class="logout-large">Save and Logout</a>

That somehow needs to integrate with the cart functionality to disable it if the user opts out.

Ah okay.  I had assumed you were using the standalone mode, in which the only way to view unsubmitted responses would be by accessing the database directly. 
In any case, I'm afraid that the feedback is now lost.

The cart JS has its own hooks mechanism that we had previously used to adapt the code for various types of galleries, in particular Highslide.  This is handled via a file within your template or gallery at lib/js/ttgcart.hooks.js.  This is a good spot to add page functionality.

I've written a bit of code that pops up an alert when the customer clicks on a buy button.  If the customer clicks 'cancel' then the page reloads.  This isn't particularly graceful but the cart hooks don't provide a mechanism to prevent further actions.

The extra code includes two functions to handle cookies so that the browser can remember that a customer has allowed cookies, and code within the ttgCart.pre_open_modal function.  ttgCart.post_populate_buy_buttons  would be a more ideal location, except that the use of page reloading as an exit mechanism would continually bombard the user with the popup until choosing 'ok'.

To use this code, copy and paste it into lib/js/ttgcart.hooks.js in your gallery or template.  You may want to change the message.

/*
    Functions do not need to exist here - jquery.ttgcart.js checks for functions before trying to call them.
    However this file should exist, as the browser will get a 404 otherwise.
 */

function setCookie(cname, cvalue, exdays) {
    var d = new Date();
    d.setTime(d.getTime() + (exdays*24*60*60*1000));
    var expires = "expires="+d.toUTCString();
    document.cookie = cname + "=" + cvalue + "; " + expires;
}

function getCookie(cname) {
    var name = cname + "=";
    var ca = document.cookie.split(';');
    for(var i=0; i<ca.length; i++) {
        var c = ca[i];
        while (c.charAt(0)==' ') c = c.substring(1);
        if (c.indexOf(name) == 0) return c.substring(name.length,c.length);
    }
    return "";
}

if ("ttgCart" in window) {
    ttgCart.post_populate_buy_buttons = function() {}

    ttgCart.post_get_pricing = function() {}

    ttgCart.pre_open_modal = function() {
        var message = "We use cookies to ensure that we give you the best experience on our website. If you continue without changing your settings, we'll assume that you are happy to receive all cookies from this website. \n\nIf you would like to change your preferences you may do so by following the instructions at http://www.aboutcookies.org/Default.aspx?page=1";
        
        var cookiesAllowed = getCookie("cookiesAllowed");
        
        if (cookiesAllowed == undefined || !cookiesAllowed) {
            if (confirm(message)) {
                 setCookie("cookiesAllowed", 1, 7);
            } else {
                 location.reload();
            }        
        }
    }

    ttgCart.post_open_modal = function() {}

    ttgCart.add_success = function() {}

    ttgCart.add_error = function() {}

    ttgCart.post_cancel_modal = function() {}

    ttgCart.pre_load_widget = function() {}

    ttgCart.post_load_widget = function() {}

    ttgCart.post_click_add_button = function() {}
}

That's interesting. So was it failing at the same point every time?

Bluehost does not allow the sending of emails via SMTP, however sending using the 'mail' method on Bluehost is reliable.  It seems that blocking 'smtp' is the norm rather than the exception and isn't in itself a reflection of how good or reliable a host is.

After configuring TTG BE to use 'mail', I suggest that you set up the email address you've configured as the Vendor email in TTG Be settings within the Bluehost control panel.  In that way, Bluehost will be aware of the address you are attempting to send from and then correctly use that email address when the emails go out.  Such emails should successfully get through to your receiver and not be marked as spam.

If you are using a service other than Bluehost for that email address then the above step won't cause any issues.  Your other provider can still serve to send and receive emails.  Adding an email address in the control panel only makes Bluehost aware of it.

Hi Bernhard,  the first thing to try is authenticating with the default API Key, which is ttg9999.  If that works then it means that your chosen API Key hasn't been set of saved properly.
If that's not the case, please send me a PM or Email (via the links under my name) with the TTG BE admin login details on the site that you can't authenticate to.

You should be able to move everything within test to the level above.  I have something similar, moving the galleries, lib and ttg-be directories from /ttg/pages_ce4/ to /.  A gallery that had resided at http://mysite.com/ttg/pages_ce4/album-one/ then functioned fully at http://mysite.com/album-one/

I then changed the Publisher API URL from http://mysite.com/ttg/pages_ce4/ttg-be/ to http://mysite.com/ttg-be/ and was able to publish albums to the new location.

Hi, that's caused by your host not allowing SMTP mail from site.  I suggest trying the 'mail' send type instead.

I am a little perplexed as to why that error is coming back to the browser.  The email function has been coded in a way that emails be only sent out after responding to the client that the feedback has been submitted.  So whether the mail goes out or not, the client should not receive an error.

Hi Marc-André, your client fields all look properly configured and are being read properly by the form.
I think this is caused by a bug in CRG failing to handle the four grid items that are empty.  Specifically, since the four cells don't have thumbnails, the JavaScript is failing to find "id" attributes.

For testing, can you try editing Test2/index.php and commenting out these items?  That just means adding <!-- before and --> after, so that in index.php you'll have:

<!--
    <div class="gridcell cell-empty clearfix">
    <div class="griditem">

    </div><!-- .griditem -->
    </div><!-- .gridcell -->
    <div class="gridcell cell-empty clearfix">
    <div class="griditem">

    </div><!-- .griditem -->
    </div><!-- .gridcell -->
    <div class="gridcell cell-empty clearfix">
    <div class="griditem">

    </div><!-- .griditem -->
    </div><!-- .gridcell -->
    <div class="gridcell cell-empty clearfix">
    <div class="griditem">

    </div><!-- .griditem -->
    </div><!-- .gridcell -->
-->

If that solves the submission form issue, then options to work around this are to either make sure their are no empty cells (Rod or Matt, do you know how to do this?), and for us to add a fix to the CRG Javascript.

Hi Chris, are you having success with the *-single.php pages now?

If you do find missing files in published galleries (such as .htaccess) then you may want to try clicking on the link 'Update Album Files' on the Publisher admin dashboard.  That link re-copies the stub files that should be found in each of the galleries, such as index.php, single.php and .htaccess.

(The actual intention of that function is to give customers way of upgrading the stub files should we ever need to change those files or put bug fixes in them.  So far we haven't needed to change them.)

You may need to enable the display of hidden files within your FTP program.