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.
I still have some issues trying to use font-awesome fonts on both the built in and mp page and template data. I added the .htaccess modules recommended by Matt and they work well on Chrome both desktop and mobile and on the native android internet app. Remains hit and miss on desktop IE and Firefox.
Rod was kind enough to test on his iPad. The font awesome font loads without problem on Chrome and FireFox on the desktop and Chrome and the native internet app on my Samsung Note 5 and now iPad.
I remain puzzled why IE 11 remains resistant to displaying them consistently. On further investigation IE has odd behavior when loading a top level gallery album set from the menu. I changed the menu from album set to the URL and everything seems to load correctly on all tested platforms.
I miss the slideshow feature of CE4 and am anxiously waiting for Stage, WP theme, FotoMoto, ....
Thanks
Jim.
Updated to version 1.0.2 last night. No difficulty with update and installed a new CRG module.
Like others have reported, some difficulty with the Photoswipe presentation and as noted elsewhere I appended to the URL in the top line of my browser "?reloadModel&skipCache."
For example for the gallery page:
http://www.jamesherman.net/galleries2/a … hday-2012/
I added the instruction so it looked like:
http://www.jamesherman.net/galleries2/a … &skipCache
Worked as expected. Needs performed only once. I also found that I needed to perform the same procedure on a mobile device to have all the Photoswipe galleries update. I do not have access to an Apple device, so they remain an unknown.
The good news is that Chrome, IE and Firefox all seem to have functioning menus and the menu load time is very quick. I had some issues in 1.0.1, now resolved.
I still have some issues trying to use font-awesome fonts on both the built in and mp page and template data. I added the .htaccess modules recommended by Matt and they work well on Chrome both desktop and mobile and on the native android internet app. Remains hit and miss on desktop IE and Firefox. MTF.
Overall, excellent work with an entirely new web application which can easily become a core for expansion beyond LR where web plugin development has remained an afterthought at Adobe for far too long. Nearly lost relevance.
When implementing the .htaccess module to suppress the www. problem, I discovered another problem.
My LR Publisher service was initially set to: http://www.jamesherman.net/backlight/publisher/ which now produces an error in LR. Just change to http://jamesherman.net/backlight/publisher/. I ignored the offer to republish all the images. Everything seems to work well otherwise.
Jim.
Had similar issues on my site: http:/jamesherman.net, see showcase for discussion, and I followed Matt's recommendation and found that suppressing the www. module helped. I also found that I needed to change my top level gallery menu entries to either absolute URL or to an album-set to make it work reliably.
Your comment regarding clearing the cache ... now I wonder if just adding the .htaccess module and clearing the cache would have done the job.
Not sure I'm up to further iterations for the moment everything seems to be working and now I can fiddle with my thumbnail presentation which I's still not happy with and may even tackle a graphic masthead.
JIm.
Looking good, though I've stumbled upon a cross-domain issue loading fonts.
When visiting your site at http://www.jamesherman.net/, all is well. And visiting at http://jamesherman.net/, without the "www", the fonts don't load, citing cross-domain errors.
Tried several variations and found that adding the Suppressing / Forcing the "www." module along with a change in how I linked my top level galleries in the menu to either an absolute URL or to the album-set resulted in the fonts being loaded correctly.
Adding either or both modules did not seem to correct the problem if I were using relative URL in the menu.
Thank you,
Jim.
PS - I may have just needed to clear the cache. Now I'm not sure if the menu change made any difference.
In Firefox (Damn Firefox, it's been causing all sorts of mischief with Backlight) your galleries page is not accessible from your home page because the drop-down menu is behind that "Search" image and your Galleries link looks like it's set to Non-Interactive.
Which version of Backlight are you using? I thought that the menu z-index issue had been fixed.
How did you construct the menu for the gallery links? Did you not set it to link to the galleries album set?
Backlight v1.0.1 downloaded 05/15/2016
Top level gallery links in the menu. I started with relative URL "galleries/" and now have tried absolute URL "http://jamesherman.net/galleries/" and finally with album set, current. They all seem to work and not significantly impact load time.
I have also now installed Firefox 64b on my WIn10 machine and I see your point on the drop-down menu. None of the above variations seem to have any impact on the menu problem in FireFox. I use Chrome almost exclusively where it works well as well as on IE 11
jim.
I had some issues with the menus and ultimately discovered a minor issue, with a work around, that Ben assures me will be fixed with the next update.
My request is, if possible, a 200-400 ms delay before the menu disappears if the mouse falls off the tree. Presently, when following a menu tree to a select page and the mouse falls off the tree, the whole tree disappears and the user is forced to start at the top again.
This is a very common occurrence in sites with similar menu trees. A small delay at the last open level would allow recovery of user mouse positioning and overall make Backlight driven sites much more user friendly.
Jim.
I had been testing Backlight on in a sub directory on my Bluehost main site running CE4. A cascade of bonehead moves resulted in my crashing my CE4 site. Ultimately, I chose to reconstruct using Backlight rather than rebuilding from CE4 backups.
I have generally tried to mimic my CE4 site but with the improved menu system. Looks reasonable. Some minor issues with embedded links as I also took the opportunity to reorganize some of the galleries to decrease clutter. Alas, I still have a few links that fail. Interestingly, i do not get an error page with a bad link, rather Backlight presents the next upward working directory. Unexpected but adds reliability to the overall site.
I am anxiously waiting for the Stage and WP updates. I have chosen not to try the Stage tweak elegantly presented by aebolzan, but am looking forward to the retrun of the Flip Home page.
I rarely, meaning once in 4 years and to my wife, have used FotoMoto, but also would like to implement on the new site.
Also still not happy with the thumbnails.
Slept on the problem. At 0530 EDT I had an epiphany. The problem is the drop-down menus. I went back to the basic drop-down to my 5 top level galleries and speed and time-out issues resolved.
Thus behavior I experienced above now makes sense. Over the course of a day I added about a hundred galleries and as the site tried to build ever more complex drop-down menus, it slowed to a crawl.
The question then becomes, how are menus built? Is this a one time event and the site speeds up after it gets a mature set of menu trees built or does it build them on the fly for each page request? If the latter, the lesson is KISS.
Keep It Simple Stupid
JIm.
Bluehost on the hosting service. I have sent the data directory .zip
Tried that and now everything is dead my main page now loads the following::
Something went wrong
Unexpected error: Maximum execution time of 30 seconds exceeded in PdoExtended.php on line 533
Please report error at http://community.theturninggate.net
Publisher initially complained but seems to be updating galleries without problem and webdisk indicates everything is in the correct place. Backlight has no difficulty with accessing the site. Indeed, as we speak, Publisher is happy updating galleries but none will display on the browser.
I managed to crash my CE4 site and have been frantically updating to Backlight. Clearly Turkey needs lots of help.
I really like the drop-down menu functionality. Please forgive my color choices, half of my 16 Crayon box is missing and my wife, has not yet approved of color choice. Clean install. No previous CE4 page migration.
I spent the last 12 hours creating and updating galleries. Previously, Matt noted that large galleries did not do well with masonry layout and I have converted to classic In anticipation of similar issues. Over the past few hours I noticed the site becoming slower and slower. Now I have a complete stop and the following error:
Unexpected error: Maximum execution time of 30 seconds exceeded in PdoExtended.php on line 533
Thoughts?
Regarding the ttg-be, I wanted to run the migration utility and understand any odd behavior and how to manage prior to turning it loose on my main site. I have had migration issues in the past and wanted to iron them out in a test environment.
The backup you describe should have been exactly what Bluehost's Site Backup Pro should have done. Now, there was some odd behavior on the Bluehost end as the weekly and monthly 'full' backups initially had dated from November 2014 and a call to Bluehost corrected the problem and restoration options included correctly dated full backups .... or did it.
I am actually more interested in preserving site look and feel. For example, if i make a series of changes and realize I liked the old layout better, is there a way to roll back just this part of the site without backing up all of the content as well?
Yes. Site testing with an ax, aka dumbass move. My CE4 site was running without problem and I decided to create a sub-directory and install Backlight and ttg-be for testing. I have never been able to get WAMP to run correctly. I was happily testing and had mostly learned the nuances of Backlight.
I then decided to test the CE4 migration function. Things went horribly wrong - most likely an ax/dumbass issue. I then thought "no worries," I have a backup. Another ax/dumbass move, I restored my entire site instead of just the test directory. That left the entire CE4 site down. Apparently, restoring the site somehow befuddles the MySQL database. Bit of advice, don't go there.
Now, what to do, reconstruct the entire site from CE4 off-line backups or forge ahead with Backlight. I only have a few CE4 stage dependent pages and over the past 4 years have only sold photos to my wife. I can manage without FotoMoto for a while. Backlight it is!
Finally, the question: How do I backup and restore the site layout, pages, templates, menus, etc. I am certain to have another ax/dumbass attack in my future?
JIm.
I was certain I replied yesterday. Now I wonder where the out of context post landed.
Thanks to Matt's reply and the CE4 db concept, I changed and uploaded 3 Gallery templates and the entire site is fixed. This is a big deal. With previous iterations of TTG or were I to use another product, I would have had to re-upload some 150 gallery pages. We love Publisher and the robust CE4 platform.
For what it's worth I am running LR 2015.2.1 with the GPU activated on a Windows 10 box with i7, 64Gb RAM, OS and apps on an SSD, a relatively new Radeon 390x video board, latest not beta drivers, and 3 4k monitors. I see a little load time difference in the web module. I would hope for faster but can live with it.
Regarding the Import module, I changed my workflow for importing images and rather than mucking around with explorer or some other third party app, I now do everything in LR. First step just get them into the catalog, I use a generic directory for all incoming photos. Then use the tools already in LR to add GPS coordinates either directly in the map module or with Jf''s geoencoder plugin, change name using LR F2 key and move to permanent storage. Done. And faster.
Worth reevaluating your own workflows periodically. Do the reasons for the current workflow still exist? Is there a better way?
Several months ago I converted my rather large site to CE4 and ttg-be. Overall I really like the db concept and it makes maintaining and updating via LR quick and robust. LR 2015 CC 6.2x issues not withstanding.
With my previous CE3 based site, as a requested page was being served up, images, thumbnails I think, were displayed as they loaded. Additional images load in the background and delays were only appreciable if I moved through them quickly. Minimal impact on the average visitor.
Now with CE4, my impression is that the entire page is loaded before the first image is displayed. On a page with a large number of images and an only moderate internet connection the circle of death seems to go on forever. I've had some visitors voice this very concern. In response, today I changed my Stage flip opening site number of images from 70 to 6 and the load time dropped appreciably on that page. No impact on other pages as I would expect.
I use BlueHost and do not see anything that has changed on the hosting or server end. The overall site size and number of images on the server is large but not significantly changed during the migration from CE3 to CE4.
Is this just me or are others seeing similar delays? Suggestions?
All better. Thanks
Jim.
Have an interesting problem with Breadcrumbs after updating Publisher. My existing galleries should have a breadcrumb like:
Galleries2 » Africa » Botswana 2006
Instead the following is shown:
Your Albums » Botswana 2006
When a user clicks on the "Your Albums" hyperlink, the site is directed to a 404 Error File Not Found page.
The fix is annoying and requires going to LR and Publisher and right clicking each gallery and editing.
1. Click on the features tab
2. Deselect display breadcrumbs
3. Re-select display breadcrumbs, do not need to make any additional changes
4. Click the Edit button to close the edit window, cancel won't work
5. Right click and select publish now, just right clicking and republishing without the above steps won't work
The breadcrumb now displays correctly with correct breadcrumb hyperlinks.
Galleries2 » Africa » Botswana 2012 1-3
Here are links to a broken gallery and one successfully fixed using the above approach.
Broken: http://jamesherman.net/galleries2/1_afr … a-2012-2p/
Fixed: http://jamesherman.net/galleries2/1_afr … a-2012-1p/
I am suspicious there is an issue with the ttg-be Publsher db but am most ineterested in anyone's thoughts.
Jim.
Sent file to Ben off-line and his response, " One strategy worth trying would be to copy the database in the same location, then rename the old database and rename the new copy to 'master.sq3'. Can you give that a try?"
Worked. I think I ran into the problem while updating a large Publisher gallery and made the mistake of simultaneously running a search which would produce a large number of results on my site with over a hundred galleries. Oops.
He also indicated he is fixing some issues with the search function due out in a few weeks. He also tweaked my DB and search no longer hangs.
Great work guys.
Jim
I'm afraid I may have broken my search function and possibly my ttg-be database. I have a rather large site and am slowly converting from CE3 to CE4. I now have approximately 100 galleries who use Pages and AI along with Gallery and Stage converted to CE4. There are a number of CE3 AI and Gallery sub directories but I don't think they are indexed for search and for the moment not relevant.
I tried a search on the site by typing in "Ephesus" which should have yielded at least one gallery and around a 100 images. The search took several minutes to run and the result was a blank page (as in white, empty, etc.). Search seemed to work OK several weeks ago when I had only converted 1-2 galleries.
Here is the problem, Now I get a DB error with any attempt to use Publisher within LR. Doesn't matter if I try to make a new gallery or if I attempt to add images to an existing gallery.
For a new gallery:
-I looked in my Blue-host directories and the new sub-directory fails to create.
-I tried deleting the gallery in LR and starting over - same problem
-Checked for illegal characters, none found; indeed I cut-pasted from the previously working CE3 gallery.
- have a screen capture of the LR error, unfortunately it won't allow a copy paste to include here, I do have a .jpg if needed.
For update to an existing gallery
-File structure appears correct on Blue-host and the page seems to run OK
-Different ttg-be DB error and new images do not upload.
-I also have a screen capture .jpg for this error
Both errors have the same first 2 lines, and I have tried to hand type them:
"An internal error has occurred: JSON.lua:458: JSON.lua:197: can't parse JSON at char 1 of: SQLSTATE[HY0000}: General error: 5 database is locked........"
-Tried to wait for a time-out reset, not successful.
-Tried to repeat a different search using a term with an expected empty result and one with an expected less than 20 elements result. Both take several minutes to run and produce an empty/blank page result.
-Tried using search from a Pages generated page, a Gallery page and an AI page - all with same result.
I' afraid I am now at a loss as how to proceed. I suspect that Search doesn't work well with very large sites and I can turn off until some future update but for the moment I need to fix my DB.
Jim.
Following the recommendations above, I was unable to get the block image to maintain the aspect ratio. I suspect that even by explicitly defining the path to the test environment phplugin directory, I have not been successful.
Ultimately, I searched for and found the setting in the style-component.css file:
.page-galleries .the-block-image {
width: 399px;
}
and added:
/* added 07/27/14 jrh */
.the-block-image {
height: auto;
}
Just above the setting. You can see the result. Correctly maintained aspect ratio.
Jim.
Sorry, I'm still finding my way through PHP. Where, to which file, should I add this fix?
Jim.
Try: http://jamesherman.net/CE4_test/galleries.php
It illustrates the problem. Most of the links don't work in the test environment at the moment.
Jim
I had been waiting for others to report a similar difficulty; seeing none, I can only assume I have somehow blown a setting. I am having difficulty maintaining the aspect ratio of an image when using the Max-Width slider.
For example, in the Galleries Page section under the 'Page Image,' I have selected 'Primary Content,' Float Left, Image ID 1 (tried others both landscape and portrait) and "Max-Width" set to 185.
The result is an image that is 185 pixels wide by whatever the original length is. A long skinny distorted image.
Could this be a LR 5.5 issue? No, I exported to a test server and the same occurs. I can attach screen shot snippets if needed.
Could this be an outdated plugin issue? Using CE4 Pages v7.0.5
How could I be loosing my aspect ratio?
Jim.