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 cloned the WP database in the past as well, but then it happened that I added new content to the staging area instead of my main site. Now I use a new WP database with just a few dummy entries. This way I see my changes, but it is obvious that this is the staging area.
i've done it this way too. In fact, this time around I started with a clean WP install only to then find out I spent too much time configuring it (new WP DB, passwords, WP config, etc). I found it was just easier/quicker to clone the entire WP site.
Unfortunately, all too often I've not noticed I was modifying the staging site when I meant to be doing so on the main site. The opposite is also just as problematic. Moments ago I deactivated several plugins I didn't need/want on the staging site, only to later realize I had done so on the main site. D'oh!
I'm thinking there must be some quick trick to make it very clear which site i'm on. Maybe something like a yellow menu bar or something on the staging site just to make it clear where I am. We can even change the admin color scheme in the staging/development site too (e.g. I find the sunrise theme is really annoying).
I think I'll try that idea, now that I'm suggesting it. It's an easy thing to switch the BL theme for WP once I'm ready to publish live. For those not using the WP theme, it's not an issue.
Thanks Rod!
You've always been quick with helpful replies. You do have "too much time" on your hands (which is good for us).
Now that I know the BL2 Publisher inside of Lightroom is backwards compatible, I can update LR and continue with development on the new environment.
I've got a staging/development sub-domain setup as a clone of my current site (minus the 1,000+ photos). Your new guide on setting up a development site is helpful. Thank you!
My site is Wordpress, and I'm also using the BL WP theme. Setting up a clone of WP on a staging/development site is a bit tricky. Something you might add in your guide.
Here's a few things that might help others if they're using WordPress. It's advanced and only needed for WordPress users. Search the internet for articles about how to setup a WP staging/development site.
Some hosting services offer a staging tool to make this a one-click operation. That costs extra, and on the big sites I manage it's worth it. But for my own site, I can't justify the cost. So a WordPress staging/development site is a manual thing (and an advanced topic).
A few things to be aware of before starting:
In the staging/development site, add a robots.txt entry to block all crawlers. You don't want anything on that site crawled or indexed by search engines. Consider password protecting it to keep everything out.
The WP staging/development site needs it's own copy of the WP DB. Clone the DB, and then modify the WP config file in the staging site to point at the clone.
Update the new WP DB
Best to avoid making changes to WP while on the staging/development site. If you do, then the cloned WP DB will be different from the live/main site. Attempting to merge WordPress DB changes is something you'd rather avoid. This is very advanced. Just say no!
While working with WordPress on the staging/development site, keep your work isolated to just Backlight. Develop your WP theme and the rest of the customizations limited to Backlight.
You can create albums, upload photos, and experiment with all the features without effecting your live site.
Then when you're ready to update the live site, copy (not move) your BL files.
Further references:
https://www.wpbeginner.com/wp-tutorials … ress-site/
https://themeisle.com/blog/wordpress-staging-site/
I'm going to setup a staging site, based on the current snapshot of my live site. I'll update the staging site to BL2, then workout any issues there. Once I've got the staging site, I can migrate all changes to live. The staging site will be in a completely different sub-folder (and I may even set it up under a sub-domain).
While I'm working on the staging site, I'll still have the live site running BL1. When I'm in Lightroom, I'll create some test albums and upload those to the staging site. This means I need BL2 installed within Lightroom.
My questions...
Can I have both BL1 and BL2 installed within Lightroom? I won't use BL1 during the entire time the staging site is under developed.
If I can't have both installed in Lightroom, if I upgrade to BL2 and don't modify/update any albums in the live site can I create/modify new albums for the staging site with BL2 and not effect anything on the live site of the existing BL1 albums.?
Otherwise, any recommendations on the workflow for keeping the live site on BL1 while I'm working with BL2 on the staging site?
The model release should include an ID (e.g. drivers license), especially to show the date of birth. It also needs a signature, which isn't easy to do on a web page. I don't know if clicking (e.g. click through licensing agreement) will hold up in court.
Another thing, you want the model release signed before the shoot (or immediately after).
I highly recommend this app. It has a very good legal contract, and you can customize it. It makes capturing the ID easy, and an easy way for the model to sign it.
There's a version of the app for you phone or tablet, so it's very convenient to get this completed during the shoot.
I use this trick, and it's a great feature. I can create custom sized thumbs and easily change which is used in the gallery page.
Using the code Ben provided, after monitoring logs for a few days I think I've figured it out.
My hosting service uses a malware scanning service Sucuri. Looks like it's their scanning software that is directly accessing files.
So I'll ignore these PHP errors. It happens once a night at 1am.
Ah, another clue. Something called /backlight-theme/404.php and generated an error.
[08-Jan-2018 05:43:30 CST6CDT] PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /home/reekes/public_html/wp/wp-content/themes/backlight-theme/404.php:1
Stack trace:
#0 {main}
thrown in /home/reekes/public_html/wp/wp-content/themes/backlight-theme/404.php on line 1add an extra line so that it reads like this
I've added the newer chunk of code to /backlight-theme/index.php
I'm not sure where the path: entry is coming from.
I thought it would have come from the debug code you wanted added. I added the code you suggested from you comment
Here's some example code to add at top of the index.php file:
Logging the IP address of the caller may shed light on it.
OK, what's the change to your debug code and I'll add that. I'll bet it turns out to be my server, meaning some code running on my site is doing this (which is what I've already assumed, but what is it?).
Hmm, last two entries have been:
[06-Jan-2018 00:08:21 CST6CDT] wordpress theme direct access referer: none
[07-Jan-2018 00:18:36 CST6CDT] wordpress theme direct access referer: noneand now I found this as well in backlight/publisher/php_errorlogf
[05-Jan-2018 22:56:15 UTC] path: /home/reekes/public_html/wp/wp-content/themes
[05-Jan-2018 23:07:56 UTC] path: /home/reekes/public_html/wp/wp-content/themesI'm sharing the site not for bragging (well, not all that much really). I'm sharing this as an example of what you can build with Backlight and how to integrate it with WordPress. I also use the Client Response Gallery quite a lot! (more on that at the end).
I'll answer any questions and help if you find something in my site that inspires you. There's a lot of small details (I'm that kind of guy) and most will probably go unnoticed.
My main focus was to get the site optimized for mobile. 2/3rds of my visitors are on phones. That's why I don't have huge full screen images, slide shows, and such.
Also the site is highly optimized for speed. All pages and images should render very quickly.
I'm about 95% done, and the last 5% is always the hardest and takes the longest to complete. I haven't made any big changes now in over a month, so I'm willing to share the site at this point.
The site is mainly a WordPress site. All except the photos, which are controlled by Backlight+Lightroom. The WordPress theme was designed with Backlight. The two should be seamless. There's only a small amount of custom CSS for the final fit and polish.
The site has well over 1,000 images, and I keep adding more each month. I'm so far behind in editing shoots (a few years worth). The main reason I spent all the time to get this site up and designed the way it is is so I can focus on getting more photos published. Now that the site is up and running well, I can very easily publish. Whew!
A major step in getting my new site up involved finding a new hosting service. Long story short, I'm now on Site Ground and have been very impressed with them. I highly recommend them with no hesitation.
Other features under the hood is a lot of security. WordPress sites get hacked all the time. In the past couple months I've fended off dozens of attack bots.
There's a lot of SEO details that are not going to be seen by a visitor, but search engines do notice them. My site gets more than the average traffic. I've built a few sites and most WordPress themes are not well designed for SEO. Even those expensive themes have problems. I've done about as much with SEO at this point. I wish I could fix a few more things but I'm up against limitations in Backlight.
I always let my models choose their favorite images, and Client Response Gallery has been invaluable.
I don't care for all the nerdy stuff about camera data. Actually, I never want to share that! I reduced the UI to get it as minimal as possible. It's much easier for the models to quickly and easily send me their favorites and with the rare comment.
I setup an example just so you can see what I've done with Client Response Gallery. I'm not linking to it here, to prevent search bots from finding and recording this location.
my-domain slash proofs slash test
PS - if you look at a couple of the non-photography pages you might be surprised to learn about me. You've heard of at least one thing I've done and have heard it a few thousand times.
![]()
I’d say something is calling http://reekes.net/wp/wp-content/themes/ … /index.php directly, which throws the error as it’s called outside of the WP environment.
I'm using a child theme, so it's extra strange that something might be calling the parent theme directly outside of WordPress.
Before hacking in something that might stop this, I'd like to find what's actually happening. Sometimes these things are symptoms and I'd like to know the disease before injecting a cure.
Is there something I can add to the logging function to capture the caller. Would this be the HTTP_REFERER?
Or this?
$trace = debug_backtrace();
$caller = $trace[1];
echo "Called by {$caller['function']}";
if (isset($caller['class']))
echo " in {$caller['class']}";And I found this comment (to get caller name with better performance) on stackoverflow...
debug_backtrace(DEBUG_BACKTRACE_IGNORE_ARGS, 2)[1]['function'];The get_header() function is a part of WordPress, so shouldn't error as undefined.
Yup - that's why I'm scratching my head.
What's the URL? Are there errors printing to the page, or just your log file?
Not sure what URL is triggering this.
All I know at this point is the lines I shared from the Backlight php_errorlog.
And it only happens once, every day. The only thing I can think of that runs once a day on my site is the iThemes Security plugin. That, possibly my host's backup service. Still, I've never seen anything trigger such an error before and I'm only seeing it in Backlight's error log.
Is there a way to add more info to the error log?
I get this error message in just once every day. It's been going on for weeks.
What would trigger this only happening once every day?
More to the point, how do I fix this?
Copied from wp/wp-content/themes/backlight-theme/php_errorlog
PHP Fatal error: Uncaught Error: Call to undefined function get_header() in /home/reekes/public_html/wp/wp-content/themes/backlight-theme/index.php:1
Stack trace:
#0 {main}
thrown in /home/reekes/public_html/wp/wp-content/themes/backlight-theme/index.php on line 1Very strange ... ok for me now as well.
This is the type of thing that happens when the browser is caching elements of the page, such as the images and CSS.
After making changes to a site, flush the browser's cache before testing.
One thing you can do -- and this maybe isn't ideal, but it would effectively get you what you're wanting -- would be to eliminate the top-level from your exposed site structure. So, make a child set -- we'll call it "Main" for lack of a better name -- like this:
galleries/main
I had thought about this. The downside is it's kinda odd and I wonder about the structure of the site. I can hide all that from the visitor, as you've suggested, but the structure is visible to search engines. I've been doing a lot of work with SEO in the past few years and have found things like structure matter.
The main downside is how I would have to provide redirects. If I move the structure, I'll need to create redirects. I found that redirects are a problem due to the magic (that I don't completely understand) in the htaccess files created by Backlight. I can redirect a directory, but I can't redirect the image files, permalinks, etc. that are in those directories.
I have over a thousand image files. Backlight doesn't have a way to sort albums within a set, and creating a number prefix in the slug was the only way to control this. In my update to the site I realized my old slug names had to be changed.
I was able to create redirects for slugs, but not for any files within those directories. So at the moment I have Google web master tools sending me warnings that my site has hundreds of 404 errors, and that figure keeps growing as the GoogleBot continues to crawl my site.
Back to the point, SEO and the appearance of the Search Engine Results Page (SERP) for my pages is what started me down this rabbit hole. The snippet that appears on the SERP is the <meta name="description" > tag. I'd like to control that. As it is, search engines take a guess at what to show. If you're familiar with the Yoast WordPress Plugin, it has a wonderful feature to write those tags.
The SERP for my main album set, the main page that contains all of my photos, is the title "Photos" with a description that is a concatenation of its album titles and descriptions, truncated to 100 characters (the latest Google SERP API). I'd like to control what is shown in this 100 char limit. Writing the main copy or a description on page can often be picked up as the SERP description, but it's not a certainty. That's pretty good, but then you have to write descriptions that are contained within 100 chars or at least write the first 100 chars as a "good" description.
To sum up, the <meta name="description" > tag is vital to SEO (even more so than permalinks).
Let me think some more about how this might be done with Backlight. I've come to understand the code pretty well, but only enough to be dangerous! I'll followup with a comment on this thread that might help kickoff some ideas on how to get this solved. Ben's comment was something I wouldn't have thought of, but I have a few other ideas. Let me think about this some more and follow up.
Ben, here's the line from the cache file you asked for.
$tt_card = 'summary_large_image';This happens to be in the middle of the new code I was testing for Matthew. That code is in this other threat.
http://community.theturninggate.net/vie … 301#p50301
What's strange is that I made the change to page.php *and* cleared the template cache, several times as I was debugging. Yet this one album template was crashing.
The line above is within the ENGINE_TYPE_AUTOINDEX block. Yet the album set template I was using never crashed, nor did any other template.
It's a mystery why it was crashing, and then magically disappeared. After I had cleared the template cache a few more times.
Hmm, never mind. It seems the crash was related to a badly cached template or something out of sync after the update.
After I cleared the template cache the crashing album stopped crashing.
Back to my original request, how can I set the <meta name="description" > tag for an album set (that is at the top level, or the main gallery page for most everyone).
Also desirable is to set the og:description tag.
Is there a way to to this for an album set at the top level?
Leaving the description blank for top-level sets; not pulling the main copy. Reason being that the OGP tags are a part of the page template, and render before we start pulling data from the child template. I'm not keen to upset the order of things to the extent that it would take to pull that information so early on.
That's a bummer, because the album set I was talking about is at the top level. It's the main photo page that I'm wanting to add the open graph tags.
As an example, I'd expect to find the OG tags for these locations.
http://theturninggate.net/galleries/
http://www.rodbarbee.com/galleries/
http://danielleu.com/galleries/
I'm especially after the <meta name="description" > tag because that's what search engines are looking for.
I can confirm a child album set is working.
After updating Backlight, all of the albums using one type of template are crashing. These are all within one album set.
Here's the error that's displayed on the browser window when trying to open those albums.
Unexpected error: syntax error, unexpected 'summary_large_image' (T_STRING) in 95-page-1.2.3.2-8-269-menu_47-92-index-1.2.3.2-25-6-admin.view.template on line 105I can change that album to a different template and it works. It's this one template that is now crashing.
I cloned the template, and made no changes to the clone, but the clone does not crash.
The crash still occurs after clearing the template cache.
I exported the crashing template and it's working clone, and they're the same.
Something is corrupt with the one template I had been using.
Here's an example album to look at. I don't want search engines to pick up this URL, so you'll need to reassemble it.
[URL deleted after the crash was resolved]
Sounds promising.
Using the "main copy" from the album set template is good for the description. Drawing on other attributes such as title should also come from there. Not sure about an image, but I"m good with the choices I see "as is" from the included albums thumbs.
You can send me a beta to test for feedback. Not sure how many others even know what we're talking about ![]()
When I change a photo with LR and re-update the Gallery.
The new phots can I see on the gallery but photo change doesn’t show.(The Photo have the first look not the change)
This happens to me all the time because I have server caching and browser caching.
First thing I do is clear my browser's cache. If that doesn't get me the updated image file, then I go to the server cache. I avoid flushing the server cache, which for me is a couple thousand images and over a gigabyte.
Depending on your caching tool, you might be able to flush just that file.
Best option while developing and updating the site is to disable caching temporarily.
I tried a few ideas for adding this, but I've concluded adding the meta data is too deep into the core of Backlight. So I started looking at the code.
I think I see why this is happening, but I'm not that familiar with the code (but I'm getting more familiar each day LOL)
In /backlight/modules/pangolin-page/dynamic/view/page.php the open graph variables are set according to a few if-else blocks including: photo, album, and "content."
The final else block only includes the statement $tt_card = 'summary'.
I didn't see the case for an album set, which I believe would be ENGINE_TYPE_AUTOINDEX.
For albums, the "page copy" within the Lightroom publisher panel is used to set the meta tag for description. That's also being used for the open graph description.
I don't find this to be true for an album set. The meta and og description are empty.
Also the open graph image and title tags are empty.
How do we set these tags for album sets?
I tried using the ttg_head hook function in the PHPlugin, but this doesn't replace the head it concatenates to the end.
If you're up for the coding, you can explore these options:
http://cssdeck.com/labs/pure-css3-page-flip-effect
https://www.sitepoint.com/how-to-create … using-css/
http://www.creativebloq.com/css3/create … ct-6126260