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.
Definitely not a no brainer, so don't expect this soon.
Hi Martin, I'm seeing a 500 error at http://www.martinsharrott.com/ttg-be/publisher/
Do you still have the permissions set to 777 for galleries? If so, can you first try changing it to 755.
Hi Thomas, thanks for the further explanation. The URL is constructed using the port information of the server that the software is running on. This should be resolved when you move from your home setup to your production environment.
hi Thomas, I'm struggling to understand what you're describing. Firstly, what is the actual URL of your contact form?
Where does it display 81, and in what way is it failing?
Hi Darrell, thanks for the log files. I've replied to your email with a possible solution.
Hi, this was addressed very late in the CE4 Cart 3.0.4 update. It may be that you applied the update before the fix got in. Can you try downloading the latest cart files, again, and re-copy the ttg-be/cart/application files?
This should fix the problem for future digital purchases (but not those already saved). The Filename you see on the downloads page for new orders should include a .jpg extension.
The log files are under ttg-be/data/publisher/. Please send these, as well as ttg.log found under your Documents directory of your PC.
Those steps are specific to your exact setup. We've never had to provide that advice before, and I doubt it will be useful in the setup instructions.
You'll need to ask your host about disabling register_globals. Again, this is not a setting we have had to advise anybody else about. In any case, phpLiteAdmin isn't a function you're likely to need. It provides direct access to the database which we sometimes use for support.
You shouldn't need a systems administrator to have basic PHP functionality, but as we often find, that is often too much to ask of some hosts.
The error is caused by a misconfiguration of the session path for your setup. Specifically, the directory /home/users/web/b2683/moo.gothic1/cgi-bin/tmp/ either does not exist or is not writable. You may be able to fix this yourself, by checking that the directory cgi-bin/tmp exists for your account (that's assuming that when you login via FTP that you're really in the
/home/users/web/b2683/moo.gothic1 folder.) See if you can find that directory. If not, try creating it. If it is already there, then try setting permissions to either 755 or 777.
If none of that works, then you'll need to contact your host's technical support. I would tell them that PHP sessions are not working, and that it appears that /home/users/web/b2683/moo.gothic1/cgi-bin/tmp/ either does not exist or is not writable.
I'm not sure if that's possible. One feature I wish fetchapp had was to allow us to add notes with the fetchapp update notification emails. We can't enter details, such as which files have been uploaded, in the notification emails.
Hi David, thanks for pointing this out. This was an issue introduced with 3.0.3 with the product and package ordering feature, and fixed in 3.0.4. I have emailed you a copy of 3.0.4, which hasn't yet been released publicly. Please try it out and let us know whether it fixes the issue for you.
Hi Stig, that sounds strange. Have you been trying to publish to Web-module-exported galleries? If so, then that won't work.
Can you provide a link to a gallery where I can see the line that appears?
The Highslide and Magnific popups do differ though they may look similar with the default settings.
Hi Stig, a fix was found, which hasn't yet been pushed out in a maintenance release - pending further testing.
Please try the following:
1. Edit ttg-be/publisher/application/skeleton/gallery/htaccess so that it contains this text
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_URI}::$1 ^(.*?/)(.*)::\2$
RewriteRule ^(.*)$ - [E=BASE:%1]
RewriteRule ^(.*)-single.*php$ %{ENV:BASE}/single.php?id=$1 [L]
</IfModule>2. Login to Publisher admin
3. Click 'Update Album Files' on the Dashboard
That last item re-copies the common files to every gallery, including the htaccess file edited above, which is copied as .htaccess, a hidden file.
If you can try that and report whether that solves the issue for you that would be great.
PS, the underlying cause of the issue seems to be that some hosts set the paths to the current directory differently, causing the shipped .htaccess to be unable to find single.php.
Hi Chris, Thanks for going to all the effort in trying to work out a cause. I still haven't been able to replicate any errors, which doesn't help. Can you provide me with the Outlet information that you're trying to use? e.g. {LUA=return Caption}
The code that handles outlets wasn't written by us. We adapted the code to work with Publisher. The code is quite straightforward for all of the tokens, other than for LUA, which is a large and complicated function. If I could replicate the error, then I would at least have a chance of working out where in that function it was failing. Another option would be if I add log statements after every line of the function and pass you a Publisher build to try out. Then by looking at the log file, we should at least be able to work out the last line that has been reached before the function hangs.
Hi Mark, looking at this gallery: http://www.markhoffmanphotography.com/g … ands-2010/
A file is failing to load: http://www.markhoffmanphotography.com/l … agnific.js
I'm not sure why that file wouldn't be there. Can you see if you have a copy of it in your exported files to upload to that location?
That's a server-side issue. I doubt that restarting your PC fixed it. Perhaps just a temporary glitch on your host?
Also, you're not running the latest version of cart, details here: http://ce4.theturninggate.net/docs/doku … _changelog
That would explain why the error message appears as a large white popup, an issue that was fixed with Cart 3.0.3.
Thanks for the access. I can see the problem now. The photos in the gallery have pricing schemes named "1 / 8", "2 / 8", etc. Of course these don't match any of the pricing schemes you've setup. I'm assuming that you've set your Category values to "1 /8", etc.? If not, is there another field that you have set to these values?
Would you be able to grant me guest admin access to your TTG BE admin? I'll then be able to see if anything's amiss with your cart setup.
Hi Jan,
Depending on your setup, some of the gallery templates won't generate 'thumbnails' renditions, instead generating 'thumbnails-for-mobile' (which are then used in both the standard and mobile views). The most recent version of Publisher, 2.1.2 addresses the need for 'thumbnails' by duplicating thumbnails-for-mobile into thumbnails during publish.
Are you running Publisher 2.1.2? If so, can you try republishing one of your galleries to check that the thumbnails are being created successfully?
You'll need to have the Publisher setting 'Push metadata without updating existing photos' *unchecked* for the images to be re-created.
Hi Gary, I'm glad that worked. IIS is a tricky one, since we don't have the resources to test against it, and some of the behaviour of PHP differs from that on Apache. We try to fix issues that customer's encounter, but don't provide any guarantees or assurance that we will solve problems encountered on Windows servers, especially those running IIS.
Hi Chris, unfortunately I have never able to replicate the problem in order to fix it.
The first thing to try is changing the name of the gallery URL to remove the ampersand from PrivateShowingJohn&AmyWedding.
The ampersand has a special meaning in URLs and can trip up the JavaScript needed by the gallery and cart.
Apache servers do not supply a setting for $_SERVER['HTTPS'] when viewing through http. The framework therefore only checks that this value is set or not set to determine whether links should use the http or https protocol.
Your site is running on IIS, which always creates a setting for $_SERVER['HTTPS'], set to 'on' or 'off' depending on how the site is accessed. Therefore the assumption that a set value implies access via https fails on your server, and links are created with https in all cases.
You can fix this by changing line 165 in ttg-be/framework/helpers/URLHelper.php from:
if (!empty($_SERVER['HTTPS'])) {to:
if (!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') {I'll add this IIS-specific fix to the framework for a future maintenance release. Let me know if you're not comfortable in updating that line and I'll email you the amended file.
These are simply the old CE3 files renamed with _ce3. If you are confident that the migration was successful then they can be safely removed.
The purpose of leaving the old files (as renamed copies) rather than deleting them is to have some hope of reversing the migration if it went horribly wrong. We don't have a process to reverse the migration, however the files are there so that a process could be created if needed.