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.
Pages: 1
Firstly congratulations on getting this first release out. It's a much much better way of doing things. Quite by coincidence I looked to see if Backlight was available and bought it - 3 hours before I got the email saying it was available. By then it was up and running - very smooth.
The main gremlin I have so far relates to fonts. My installation is in a subdirectory (i.e.my.domain.com/chris) - I don't know if that is relevant. In the apache logs I have the following which occur in mobile (e.g. when I shrink the width of a browser). The menu icons are not rendering, and on an iphone6 sometimes disappear entirely. It is trying to retrieve the font with the first part of the path missing:
"GET /chris/index.php?template=6&extension=css&name=style HTTP/1.1" 200 20333
"GET /fonts/fontawesome-webfont.woff2?v=4.5.0 HTTP/1.1" 404 229
"GET /fonts/fontawesome-webfont.woff?v=4.5.0 HTTP/1.1" 404 228
"GET /fonts/fontawesome-webfont.ttf?v=4.5.0 HTTP/1.1" 404 227
"GET /chris/index.php?template=6&extension=js&name=scripts HTTP/1.1" 200 144495
I can see the font files in ./backlight/modules/okapi-core/static/fonts/fontawesome-webfont.woff.
Nothing is logged in the apache error log.
When looking at the site on an iphone6 the icons are missing (black) for the "Pages" pages but are there on the "Gallery" pages.
Everything is largely at default settings at the moment.
Regards
Chris
Offline
Hi Chris,
That's odd. We didn't encounter any such error in testing. Can you link us to your install? I'd like to get a look at the pages, see whether the errors are happening in the browser's console log as well, and get a look into your style.css file.
Cheers,
Matt
Offline
Hi Matt
Thanks for the fast reply. Have emailed you the info.
Thanks
Chris
Offline
It seems to be a bit more convoluted, but is trivial to replicate. I re-installed Backlight+Pages from scratch, entering the bare minimum information in the initial setup. As before the install was into /chris/. I then cleared the browser cache and tried the following:
Go to the home page. The font retrieval is correct:
192.168.80.22 - - [05/May/2016:14:09:08 +0100] "GET /chris/ HTTP/1.1" 200 2117
192.168.80.22 - - [05/May/2016:14:09:09 +0100] "GET /chris/index.php?template=6&extension=css&name=style HTTP/1.1" 200 20329
192.168.80.22 - - [05/May/2016:14:09:09 +0100] "GET /chris/backlight/modules/okapi-core/static/fonts/fontawesome-webfont.woff2?v=4.5.0 HTTP/1.1" 200 66624
192.168.80.22 - - [05/May/2016:14:09:09 +0100] "GET /chris/index.php?template=6&extension=js&name=scripts HTTP/1.1" 200 144495
Click on the About page. The font retreievals are wrong in two different ways. The first set would not have been noticeable if I wasn't installing into a subdirectory. The second set is just wrong. The same happens for the Contact and Search pages:
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /chris/about/ HTTP/1.1" 200 2125
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /chris/about/index.php?template=5&extension=css&name=style&ppf=on HTTP/1.1" 200 20325
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /backlight/modules/okapi-core/static/fonts/fontawesome-webfont.woff2?v=4.5.0 HTTP/1.1" 404 265
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /backlight/modules/okapi-core/static/fonts/fontawesome-webfont.woff?v=4.5.0 HTTP/1.1" 404 264
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /backlight/modules/okapi-core/static/fonts/fontawesome-webfont.ttf?v=4.5.0 HTTP/1.1" 404 263
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /chris/about/index.php?template=5&extension=js&name=scripts&ppf=on HTTP/1.1" 200 144495
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /chris/fonts/fontawesome-webfont.woff2?v=4.5.0 HTTP/1.1" 404 5694
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /chris/fonts/fontawesome-webfont.woff?v=4.5.0 HTTP/1.1" 404 5693
192.168.80.22 - - [05/May/2016:14:10:34 +0100] "GET /chris/fonts/fontawesome-webfont.ttf?v=4.5.0 HTTP/1.1" 404 5435
I then published one gallery. Clicking on Galleries is ok (I cleared the browser cache before doing this so the font GET showed up - it was cached in the browser):
192.168.80.22 - - [05/May/2016:14:15:53 +0100] "GET /chris/galleries/ HTTP/1.1" 200 2435
192.168.80.22 - - [05/May/2016:14:15:53 +0100] "GET /chris/galleries/index.php?template=2&extension=css&name=style HTTP/1.1" 200 20771
192.168.80.22 - - [05/May/2016:14:15:53 +0100] "GET /chris/galleries/test/thumbnails/cp-20160503-Bushey-Park-0048.jpg HTTP/1.1" 200 22697
192.168.80.22 - - [05/May/2016:14:15:53 +0100] "GET /chris/backlight/modules/okapi-core/static/fonts/fontawesome-webfont.woff2?v=4.5.0 HTTP/1.1" 200 66624
192.168.80.22 - - [05/May/2016:14:15:53 +0100] "GET /chris/galleries/index.php?template=2&extension=js&name=scripts HTTP/1.1" 200 144496
Hope that helps narrow it down.
Chris
Offline
Thanks, Chris. We're looking into this. Please leave things online in the meantime.
Offline
Hi Chris, we've found that the links to the fonts in your stylesheet are including the port number. For example:
https://yoursite.com:443/chris/backligh … ot?v=4.5.0
[edited to remove your actual domain from the above URL]
While these links are valid, font paths seem to be very, very fussy about the font URL matching that in the address bar. So I think what's happening is that the browser is refusing to load fonts from those locations, and instead trying to load the fonts from the default Fontawesome location, at /fonts/.
Assuming this is the cause, this should be a straightforward fix. Can you try applying the change to one file? If you're not keen on editing the file, let me know and I can email you the entire file to be uploaded.
The file in question is:
/backlight/framework/helpers/URLHelper.phpLine 236 needs changing from:
if ($_SERVER["SERVER_PORT"] != "80" && strpos($host, ':') === false) {to
if ($_SERVER["SERVER_PORT"] != "80" && $_SERVER["SERVER_PORT"] != "443" && strpos($host, ':') === false) {This block of code works out whether a port number needs to be added to a URL. This isn't needed for sites running over http on port 80, or over https on port 443, however the condition for the latter exclusion wasn't there, resulting in a URL of https://yoursite.com:443/ rather than https://yoursite.com/
After making the change, clear the Designer Template Cache files (via the Designer -> Templates -> Clear Template Cache menu item), and optionally, clear your browser cache.
I've tested that the above code change does remove :443 when browsing over https. Hopefully it will in turn also clear up the 404 errors on fonts.
Offline
Hi Ben
I've made that change including clearing the template and browser caches, but no difference I'm afraid. The site is available over normal http:80 as well, and the same problems happen there.
I was getting many different and unpredictable/unrepeatable effects. For example removing Search from the menu list randomly changed which pages fetched the icons correctly (sometimes home would, sometimes about would but contact wouldn't, etc). And again different effects using http and https.
So back to basics. I installed a virgin copy (with the patch you supplied) into /test/. I took care to access the backlight admin screen only using http. It populated the Site URL as expected with http://...... I only set the mandatory fields (email, api key, etc) and didn't change anything else.
Clearing the browser cache, and accessing the site using http - home & search retrieve the font correctly; about & contacts try to retrieve from /test/fonts/....
This is the simplest case and is repeatable. I feel we should try to nail this first and then see if there are any residual problems. Happy to help however I can, and to give you access to the site. I have tar archives of the site immediately after install, after backlight config, and after accessing as above if they would help.
Many thanks
Chris
Offline
Hi Chris,
I think what's happening here is due to the URL to the fonts being fixed to the protocol at the time the templates were cached. The way Designer works is that templates are pieced together based on the template settings and stored as PHP files ready to be used for each page view. The pages themselves, Javascript files and Stylesheets each have their own cached files.
So if you were to clear the template cache then view over https:// then your cached stylesheet would use https:// for the fonts. Subsequent viewing over http:// would still try to load the fonts over these https:// links.
The next step is to work out whether this is actually the cause of the problem. A quick way of verifying this is to disable template caching. We have some developer settings in a file /backlight/designer/env.php. To disable caching, remove the comments from the SKIP_CACHE setting so that the contents of the file looks like:
<?php
define('SHOW_XML_ERRORS', true);
//define('RELOAD_MODEL', true);
define('SKIP_CACHE', true);
?>Can you try making that change to see whether the issue goes away between http:// and https://?
This setting comes at a performance penalty. You may not even notice the time taken, but it really depends on the speed of your host. I've only seen the penalty by looking at the time taken for page loads in Chrome's developer tools. Caching reduces page and resource load times by 30-50%.
Assuming that disabling the cache makes the issue go away, there are some options to keep this working in the mean time:
1. Force all http:// page loads to be redirected to https:// via changes to your .htaccess file. This probably isn't a bad idea in general.
2. Keep the cache disabled. That may be fine in the interim, but it's obviously better to have pages load as quickly as possible.
3. Attempt to make a code fix that should prevent the protocols from mattering.
It would be really helpful if you could try out step 3, in conjunction with making sure the cache is enabled (by undoing the change to env.php). If you're keen to try it out, the file to edit is /backlight/modules/standard-page/dynamic/css/style.php, by adding a preg_replace line in after line 14, so that this block:
<?php
$baseURL = $engine->getCoreURL().'static/fonts/';
$faVersion = '4.5.0';
?>becomes:
<?php
$baseURL = $engine->getCoreURL().'static/fonts/';
$baseURL = preg_replace('/https?:/', '', $baseURL);
$faVersion = '4.5.0';
?>That change removes the protocol from the equation entirely, resulting in links in the form //yoursite.com/...
Now, all this long message assumes that the problem is based on the protocol used to load the fonts. I hope that is the case.
Offline
Hi Ben
Disabling the cache made no difference. I suspected it wouldn't as I had been clearing the template cache between each change anyway. Adding the line in style.php to zap the method wasn't good - it meant that even if you start as https the navigation always takes you to http.
I don't think this is the core of the problem. As in my previous post, it goes wrong simply using http only. I'm sure that whatever is happening there needs fixing first as it will be masking any other problems to do with the method (if there are actually any).
Try my /test/ instance just with http..... (I've left it as it was with caching enabled and without the style.php change).
Thanks
Chris
Offline
Hi Chris, I had been looking at you /chris/ instance. I can't actually see any issues at all with /test/. Everything loads, and there are no failures in loading fonts. Can you help take a screenshot of a page showing the URL and network inspector, describing what you're seeing that isn't right? It's probably better to send it via the Email link under my name.
Offline
On their way by email in a few minutes...
Offline
Resolved in 1.0.1.
Many thanks
Offline
Pages: 1