http://clear.johnkilgo.com , navigation does not work, nor does menu (adjusting to page scroll) work in Google Chrome. The demo on getgrav.org does work, but source says it is 0.9.5 generated, not 0.9.6. Installed from zip download from website; ran bin/gpm update too, but everything all set. Curious if anyone else experiences these issues. Thanks.
Ok, that’s strange. I will definitely look into that. Could be a theme thing as I have made several updates to Antimatter in the last week.
Ok, I definitely see something weird with your site. The CSS is not correct, fonts missing, animations are not displaying, and I even see a Whoops error at the bottom of you page.
It’s really weird because I don’t see any issues with the CSS loading, nor the JS for that matter. Is it possible to try reinstalling the latest one-page skeleton?
A bug report – just noticed on your site: http://grammarist.com/spelling/tenant-tenet/ (from Grav’s default template)
Thanks for looking into this…I just downloaded this… https://github.com/getgrav/grav-skeleton-onepage-site/releases/download/0.9.6/grav-skeleton-onepage-site-v0.9.6.zip And reinstalled, but still the same result… http://clear.johnkilgo.com
OK, this has me stumped at the moment, I’ve asked our JS expert to take a look to see why the JS stuff is at least not working, that might help with the rest.
It’s very strange!
Like Andy I see a Whoops error at the bottom of your page but it looks like it is truncated so I suspect it’s related to the other issues.
Can you try disabling the debugger from the system.yaml in the user/config/ folder? All the assets are loading fine on your site but for some reason the JS events are not fired at all, like the scroll for instance, which is supposed to add a scrolled classname to the navigation bar, is never reached.
Hi, the debugger is marked as disabled already. here is current config file…again this is downloaded exactly as is from grav website…
home:
alias: ‘/home’
pages:
theme: antimatter
markdown_extra: false
process:
markdown: true
twig: false
cache:
enabled: true
check:
method: file
driver: auto
prefix: ‘g’
twig:
cache: true
debug: true
auto_reload: true
autoescape: false
assets:
css_pipeline: false
css_minify: true
css_rewrite: true
js_pipeline: false
js_minify: true
debugger:
enabled: false
twig: true
shutdown:
close_connection: true
It seems like the error at the end of the page is causing this issue. Can you try disabling the close_connection in your user/config/system.yaml:
debugger:
shutdown:
close_connection: false
That seems to have fixed it…but why would that be enabled in the version we can download on getgrav.org? (just for curiosity/learning sake).
What that does is provide a powerful event that lets Grav perform actions after the page has been rendered and sent to the browser. It lets us do advanced things like tracking without impacting performance. It’s not actually used by any of the plugins available, but does provide better performance with the upcoming admin plugin.
I think that your hosting provider is disabling one of the functions. Either set_time_limit or ignore_user_abort. I can look to add some checks on the availability of these functions so it doesn’t error out so badly. Would be nice to know which of these are causing a problem with your hosting. Perhaps you could ask them?
I can see if I can take a look…thanks for your time to to diagnose this issue. I am actually using DigitalOcean with a vps configured by ServerPilot for all hosting.
I’m sure there is a restriction on the set_time_limit call. I’m going to put a couple of checks in place in the shutdown() method in the Grav.php class:
if (function_exists('set_time_limit')) {
@set_time_limit(0);
}
if (function_exists('ignore_user_abort')) {
@ignore_user_abort(true);
}
Would be great if you could try replacing your calls with these safer calls and toggling-back the shutdown connection setting?
Let me know if this resolves it for you?
I tried this, hopefully it is what you mean by the above:
/**
* Set the final content length for the page and flush the buffer
*
*/
public function shutdown()
{
if ($this['config']->get('system.debugger.shutdown.close_connection')) {
if (function_exists('set_time_limit')) {
@set_time_limit(0);
}
if (function_exists('ignore_user_abort')) {
@ignore_user_abort(true);
}
if (isset($this['session'])) {
$this['session']->close();
}
header('Content-length: ' . ob_get_length());
header("Connection: close\r
");
ob_end_flush();
ob_flush();
flush();
}
But it did not resolve the issue.
What happens if you simple remove the whole set_time_limit thing? so the whole function is:
public function shutdown()
{
if ($this['config']->get('system.debugger.shutdown.close_connection')) {
if (function_exists('ignore_user_abort')) {
@ignore_user_abort(true);
}
if (isset($this['session'])) {
$this['session']->close();
}
header('Content-length: ' . ob_get_length());
header("Connection: close\r
");
ob_end_flush();
ob_flush();
flush();
}
$this->fireEvent('onShutdown');
}
It really is not a necessary part of the function, it was just a safe-guard for long running processes, but nothing should be running for more than the default 30 seconds anyway.
The issue still occurs.
and if you remove the ignore_user_abort part???
Continue to occur (flushing cache between all these updates too)
Then I’m kinda stumped. All that is left is the session close and some buffer flushing. Do you have anyway to see the PHP error log?