Community @ The Turning Gate

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.

  • New user registrations are disabled.
  • Users cannot create new topics.
  • Users cannot reply to existing topics.

You are not logged in.

#1 Re: Backlight 3 Support » BL3's Search timing out » 2020-06-10 09:44:52

Thanks, Ben -- I changed php.ini max_execution_time and that worked. I'm seeing some searches take over 40 seconds so it sure seems like something changed in BL3, since I never had a search take over 30 secs. before (i.e., never saw the 30 sec. timeout).

I'll email you link to my master.sq3 file (34MB).

#2 Re: Backlight 3 Support » BL3's Search timing out » 2020-06-10 04:47:39

Just over 8700 (=17 years of travelog galleries)

Although I'd love a faster search, what I really need is a way to relax the 30 sec. hard search cutoff time.

#3 Backlight 3 Support » BL3's Search timing out » 2020-06-09 05:08:32

rsamco
Replies: 4

After updating to BL3, many searches on my website are now timing out with:
    Something went wrong
    Unexpected error: Maximum execution time of 30 seconds exceeded in PdoExtended.php on line 540
    Please report error at http://community.theturninggate.net

For example, this search "http://rick.samcos.com/backlight/search/?q=steens" sometimes succeeds but has been failing >50% of the time today.

Previously, searches on my website often took >20 seconds, so they appear to always have been on the cusp of a 30 sec timeout. Appears that BL3 now has pushed many of them over that limit!

#5 Re: Backlight 2 Support » Removing end-of-gallery marker image behavior from pre-BL galleries » 2020-04-14 02:34:15

OK, more discovery ... setting an album's "# items per page" to "all in one page" results in a <blank> value thereafter shown AND that album then displays the "pagination" behavior after last image displayed (i.e., ">|" icon page shown when you scroll past album's last image)! Seems like a bug to me.

So, currently you have to set an album's "# items per page" > then its # of images in order to avoid pagination last page.

#6 Re: Backlight 2 Support » Removing end-of-gallery marker image behavior from pre-BL galleries » 2020-04-14 00:28:30

Rod, all my pre-2018 albums (I.e., the ones exhibiting the "pagination" behavior) have been marked-for-republish & republished numerous times, browser caches cleared numerous times (& your browser apparently exhibited the behavior), and server's ttg files/modules are always kept up to date & currently show that no updates are needed, and I've run the ttg server-side "update album files" yet again right now. "Pagination" behavior still there. Your pagination observation got me thinking... looked at "# items per page" setting in those albums -- it is set to <blank>. If I set to "100"(my default value), the "pagination" behavior is fixed! Now I just need to manually set that value for a hundred or more albums sad And each is not trivial since you can't just type in "100" but instead must slowly scroll down the drop-down-list to "100".  uggggggggggggggh!!!!!!!

Apparently, a <blank> value results in an unlimited "# items per page" with pagination behavior at the end. I'm guessing that a TTG release at the end-of-2017/beginning-of-2018 cleared any value in existing albums (all my albums have always been set to "100").

#7 Re: Backlight 2 Support » Removing end-of-gallery marker image behavior from pre-BL galleries » 2020-04-13 01:03:20

Thanks, Rod ... but I wasn't clear in my original post -- Some of my galleries were CE2, CE3, ... originally, but as new TTG versions were released they were migrated forwarded to the newest version. So, now all my galleries are BL2 versions. However, my oldest galleries now exhibit different behavior in BL2 than newer published ones. That is, what happens when you attempt to travel past the gallery's last image! Older galleries (originally published pre-2018) show a right-arrow on the last image and it takes you to a ">|" icon-page; newer gallery (originally published post-2017) images have no right-arrow and you can't go past the last image.

Old gallery example: http://rick.samcos.com/galleries/t-2003/a-Dog-Mountain/
New gallery example: http://rick.samcos.com/galleries/e-2018 … Favorites/

Again, my whole tree of galleries is totally BL2.

I can't find anything in the gallery metadata or file configurations that explains/causes this behavioral difference. I have inspected the metadata through Lightroom and directly thru BL2's publisher on the server. And, like I said in my original post, republishing the older galleries does not fix. Nor does replacing an older galleries' .htaccess, index.php, lib.php, & single.php files with ones from a newer BL2 gallery. And the gallery.xml files are identical except for the gallery's embedded ID.

So, for the life of me, I can't figure out where this difference in behavior is coming from, and therefore how to fix!

#8 Backlight 2 Support » Removing end-of-gallery marker image behavior from pre-BL galleries » 2020-04-11 12:01:43

rsamco
Replies: 10

I have some galleries originally published ages ago by old TTG versions (e.g., CE-2) that still scroll past the gallery's last image and then show a ">|" icon to denote the end of the gallery. On the other hand, scrolling to the end of a BL2-published gallery just displays the last image, without a right arrow. I can't figure out how to convert my old galleries to the new behavior. Marking and totally republishing doesn't work. Replacing the gallery's .htaccess, index.php, lib.php, & single.php files with BL2 versions doesn't do it. Is there a way other than laboriously creating new galleries and hand copying over gallery metadata & images? TIA

#9 Backlight 2 Support » Entering a special character (e.g., a emdash) into album Page Content » 2019-12-31 11:01:47

rsamco
Replies: 0

I thought that entering a double hyphen ("--") was converted by markdown into an emdash within BL2. But it's not for me. So I have tried various other methods without success. For example, entering the html "&#8212;" or "&emdash;"  (on a separate source line per markdown convention) results in the output of "&#8212;" . Is there a way to get a emdash inserted into the output text? I am entering the album/album set source copy through Lightroom. TIA!

#10 Re: Backlight 2 Support » Error (re-)publishing newly created Album Set from Lightroom » 2019-12-29 05:52:01

Thanks ... I searched on "minimizeEmbeddedMetadata" and that thread wasn't (& isn't) found...makes one lose faith in the forum search function...

#11 Backlight 2 Support » Error (re-)publishing newly created Album Set from Lightroom » 2019-12-29 03:02:19

rsamco
Replies: 3

Every Album Set that I create and populate with Albums within Lightroom gets the following warning when I publish it (and therefore all of its contained Albums):

LrPublishWarning
Warning: Can't update this collection.
An internal error has occurred: TTGPublishServiceProvider.lua:792: attempt to concatentate local 'minimizeEmbeddedMetadata' (a boolean value)

Lr's Album Set publishing correctly publishes/re-publishes the first contained Album needing publishing, but the above warning occurs before the publishing of any additional Album(s) and aborts the publishing process.

This happens within my Lr catalog whether it is hosted on either of two Windows 10 systems -- both have fully updated Windows, Lr, and TTG software. And it occurs for any newly created Album Set, but doesn't occurred with pre-existing Album Sets (e.g., an Album Set created last summer has no problem being fully republished)

I can work around this problem by individually publishing each individual album contained in an Album Set, but it's a pain.

#12 Re: Backlight 2 Support » BL Album restoration from Lr backup failed » 2019-07-02 01:11:04

Thanks, Rod. But this is different than what's stated in http://backlight.theturninggate.net/doc … _backlight and is a HUGE change that I haven't seen pointed out anywhere. Of course, this (unintended?) consequence of BL's recent separation from Lr seems obvious to me in hindsight now, but I hadn't thought about it and was therefore unknowingly living with an incomplete backup strategy. Thankfully I stumbled on it before I had a catastrophic, unrecoverable situation! IMO this change needs to be prominently announced/shared with all BL users!!

And server-side backups, at least on ttg-recommended Bluehost, are very poorly supported. I guess that I'll have to investigate automated, client-side, ftp apps :-( BTW, the BL /backlight/data folder can be pretty big (mine is 0.5GB) so a daily ftp download backup should probably be differential for some folks in order to avoid eating up ISP data budget.

#13 Backlight 2 Support » BL Album restoration from Lr backup failed » 2019-07-01 11:15:26

rsamco
Replies: 4

I accidentally overwrote the Page Copy of a published album, so I tried restoring that album from a backup Lr catalog made before my mistake (e.g., per http://backlight.theturninggate.net/doc … _backlight). That is, I temporarily opened the backup catalog in Lr, and intended to either publish that one album or edit that album within Lr & copy the Page Copy field's contents. But when I edit'd that album using a backup Lr catalog, the Page Copy field contained the new, erroneous contents! So looks to me like this data is (effectively) only stored on the server!!! [BTW, I tried to restore from a total of 3 Lr backups and they all failed to display/restore the Page Copy that existed at the time of that backup.]

Fortunately I found a BL publisher data log file on the server from the day that that album was last correctly published. So I was able to copy the album's Page Copy from there and paste/overwrite the recent erroneous version. I was very lucky that the log file still existed since I periodically purge them (I never imagined that I'd need them for backup)!

Hopefully this is some error on my part, otherwise this is a very scary & untenable situation for me -- I assume that all Lr data (including BL's) can be restored using only Lr/client-side backups.

#15 Backlight 2 Support » Search custom text » 2019-04-30 05:18:50

rsamco
Replies: 2

I've had a Search menu choice with a custom title since CE4  (http://rick.samcos.com/search) and now wish to modify that text. But for the life of me I can't find where that custom text is specified. Forum posts point me to "Backlight Settings > Publisher > Search" but I can only find "Admin > Backlight Settings" which presents a page with "Publisher" section in which there is "Search Template" setting but nothing for custom text (or title). I know I'm probably overlooking something simple, but sure don't see it.

I'm running the newest versions of BL2 with WP Theme option.

#16 Re: Backlight Support » Search database retains removed body text words » 2018-01-31 02:53:17

Pilot error on my part ... I found that "moring" was still occurring in an image source href in the album body text. After also fixing it there, "moring" was removed from search database. Sorry for the false alarm.

#17 Backlight Support » Search database retains removed body text words » 2018-01-31 02:22:42

rsamco
Replies: 3

I just found and corrected a misspelled word in the body text of 3 albums (typo "moring" instead of "morning"). After the correction, a search on "morning" now correctly lists those albums (among many others). Unfortunately, a search on previous typo "moring" also still lists those albums even though "moring" no longer occurs in them. I then explicitly marked and republished the entire albums to try to force a reindexing, but that also didn't remove the now erroneous word from the search database.

Here's the search: http://rick.samcos.com/backlight/search/?q=moring

PS I'm running latest BL version.

#18 Re: Backlight Support » Template masthead images broken after website move » 2017-12-16 08:45:41

FYI that I just discovered that favicon didn't show for my first newly published album since website migration (favicon worked for all  pre-existing albums & album sets). Fixed problem by deleting, re-uploading, and then re-config'ing the favicon in BL Designer. Conclusion: it appears that a website migration to a new server location requires a refresh of ALL uploaded BL images.

#19 Re: Backlight Support » Secondary masthead not initially drawn » 2017-12-09 02:22:35

No caching plugin ... browser caches were flushed.

#20 Re: Backlight Support » Secondary masthead not initially drawn » 2017-12-08 08:57:08

Very strange ... ok for me now as well. Oh well, let's move on & see if it comes back.

#21 Re: Backlight Support » Secondary masthead not initially drawn » 2017-12-08 07:45:25

Ummm...didn't make any changes, but now only fails very infrequently for me. Padding problem is always there.

#22 Re: Backlight Support » Secondary masthead not initially drawn » 2017-12-08 07:40:07

OK, reduced secondary masthead image size to 25x275 and 50x750 (iPhone pixel width dimensions, reg. & retina). Problem still persists at times -- always occurs if you (while in portrait orientation) go from galleries back to home page. And now left and top padding space both different between BL and WP controlled pages.

#23 Re: Backlight Support » Secondary masthead not initially drawn » 2017-12-08 06:26:35

Boy, I should have noticed the large file sizes ... thanks for pointing that out! BUT they're small now (20K & 40K for reg and retina PNGs) and the problem persists. AND I'm noticing that the secondary masthead (when it does display) is vertically padded differently in BL (i.e., gallery) vs WordPress (i.e., all other) pages.

#24 Backlight Support » Secondary masthead not initially drawn » 2017-12-08 03:00:00

rsamco
Replies: 12

I have a BL v1.2.3R3 website rick.samcos.com whose secondary masthead doesn't initially show on its WordPress pages (i.e., all but gallery pages). The secondary masthead does then get painted if I rotate the device so that the primary masthead shows instead, then rotate back. It usually then continues to show as you navigate between pages, but can once-in-a-while disappear again upon page/site reloads. If I update any page in WordPress I can reliably get it to fail on the next page load. My secondary masthead is only used for small mobile displays in portrait orientation, so that is where this problem is exhibited (tested on Iphone 6 & 8, both Chrome & Safari). So, while holding a phone in portrait mode, go to website and you shouldn't see the masthead until you rotate phone to horizontal and back.

PS This is not a new problem -- it was there in v1.2.3 if not earlier. I was hoping the v1.2.3 release 3 would rectify...alas.
PPS Does anyone else find BL's release numbering confusing? Why is newest release labeled "v1.2.3 release 3" instead of "v1.2.4" (or "v1.2.3.3")?

#25 Re: Backlight Support » Custom BL PHP for WordPress? » 2017-12-06 09:27:31

Here's what I ended up with:

function ttg_head( $style, $path ) { 
	// refresh WordPress page <wp_page> every 5 minutes
	if (substr($_SERVER["REQUEST_URI"], -strlen('/<wp_page>/')) == '/<wp_page>/') {
		echo '<meta http-equiv="refresh" content="300">' ;
	}
	return false;
} 

Board footer

Powered by FluxBB