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
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 1Last edited by JimR (2018-01-02 07:39:24)
--Jim
Offline
Off the top of my head, not sure. The get_header() function is a part of WordPress, so shouldn't error as undefined.
What's the URL? Are there errors printing to the page, or just your log file?
Offline
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?
--Jim
Offline
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.
We should look at ways of preventing direct access such as via an .htaccess file
Offline
Hi Jim, copying the .htaccess file from backlight/data/ into your backlight theme folder should work:
The contents of that file:
Deny from all
Options All -IndexesThis should be safe, but can you make sure that the theme still operates within WP after adding this? I'll then look to add this into the theme packaging process.
One idea behind those .htaccess files is that even if the syntax is not supported by your web server, then the .htaccess causing a 500 error is an improvement on the index.php attempting to run and throwing a 500 (or worse, being abused somehow to do something else, though I can't see how that could happen with our theme).
Offline
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'];https://stackoverflow.com/questions/211 … hod-in-php
Last edited by JimR (2018-01-03 06:47:53)
--Jim
Offline
My approach would be to dump the defined constants in the index file, view it under WordPress and then directly to find a variance in the set constants. Then add an if statement checking for the absence of a constant that would have been set under WordPress, and add log within the if block.
Offline
Here's some example code to add at top of the index.php file:
<?php
//Uncomment below to list constants defined in WP
//die('constants: <pre>'.print_r(get_defined_constants(true)['user'], true).'</pre>');
// Checking for WP_USE_THEMES. There's no obvious 'this is running under Wordpress' constant.
if (!defined('WP_USE_THEMES')) { // WP_USE_THEMES not set - this has been accessed directly
$referer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : 'none';
error_log('wordpress theme direct access referer: '.$referer);
die('No direct script access allowed');
}
?>Offline
I don't think debug_backtrace will be useful. I bet you five somethings that this is nothing more than an external call of some variety to your theme directory. It's not likely to be anything interesting.
Offline
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/themesLast edited by JimR (2018-01-08 09:36:40)
--Jim
Offline
I'm not sure where the path: entry is coming from. Perhaps an errant debug statement from our Backlight development.
The 'none' suggests a direct access to that URL. Since it's there and available on the web, it could be anything. Logging the IP address of the caller may shed light on it.
Offline
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?).
--Jim
Offline
The path: logging comes from our WP engine, and wasn't something you added as part of this discussion.
I'm so tempted to leave your other question as an exercise for the reader... Anyway... add an extra line so that it reads like this:
<?php
//Uncomment below to list constants defined in WP
//die('constants: <pre>'.print_r(get_defined_constants(true)['user'], true).'</pre>');
// Checking for WP_USE_THEMES. There's no obvious 'this is running under Wordpress' constant.
if (!defined('WP_USE_THEMES')) { // WP_USE_THEMES not set - this has been accessed directly
$referer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : 'none';
error_log('wordpress theme direct access referer: '.$referer);
error_log('wordpress theme direct access IP Address: '.$_SERVER['REMOTE_ADDR']);
die('No direct script access allowed');
}
?>Offline
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
--Jim
Offline
404.php is a page template used by Wordpress, and displays for 404 (page not found) errors. Once again, get_header() should not return undefined within the context of Wordpress.
Offline
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.
--Jim
Offline
Pages: 1