Opened 7 years ago
Closed 3 years ago
#37060 closed defect (bug) (invalid)
wp-load.php wrong paths
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.5.2 |
Component: | General | Keywords: | |
Focuses: | performance | Cc: |
Description
Hey,
while debugging some other issue, I found a issue with WP core (I think).
I created a simple test file:
<?php $parse_uri = explode( 'assets', $_SERVER['SCRIPT_FILENAME'] ); require_once( $parse_uri[0] . 'wp-load.php' ); ?>
And straced it.
My wp install is in /var/www/vhosts/staging/
However in strace I would get a lot of:
lstat("/root/./abstracts/abstract-wc-widget.php", 0x7fffd1551960) = -1 ENOENT (No such file or directory)
lstat("/root/./admin/index.php", 0x7fffd1551e40) = -1 ENOENT (No such file or directory)
lstat("/root/./class-wc-dependencies.php", 0x7fffd1551ce0) = -1 ENOENT (No such file or directory)
lstat("/root/./includes/class-wc-embed.php", 0x7fffd15519e0) = -1 ENOENT (No such file or directory)
Or:
lstat("/root/acceptance.php", 0x7fffd1552c90) = -1 ENOENT (No such file or directory)
lstat("/root/akismet.php", 0x7fffd1552c90) = -1 ENOENT (No such file or directory)
lstat("/root/checkbox.php", 0x7fffd1552c90) = -1 ENOENT (No such file or directory)
lstat("/root/count.php", 0x7fffd1552c90) = -1 ENOENT (No such file or directory)
Or:
lstat("/usr/share/php/admin/admin_functions.php", 0x7fffd1551b10) = -1 ENOENT (No such file or directory)
lstat("/usr/share/php/admin/index.php", 0x7fffd1551e40) = -1 ENOENT (No such file or directory)
This is in no way a major thing, however I think it should be checked where this comes from (especially since a couple plugins seem to hook in some of the things and then use a is_file (whcih returns false & is therefore uncached) which makes websites unnecessarily slow.
Change History (3)
#2
in reply to:
↑ 1
@
7 years ago
So this is caused by plugins?
If yes, I will check the plugins
Thanks!
Replying to dd32:
Based on the filenames here, this looks like it could quite possibly be caused by plugins using relative paths in their
include
s andrequire
s.
ie.require './my-other-file.php';
andrequire 'my-other-file.php';
rather thanrequire __DIR__ . '/my-other-file.php';
WordPress uses the latter in most places
PHP will see a relative path like that and resolve it according to it's
include_path
configuration, in most scenario's it should check the script directory first, but in your case, due to some configuration, it appears to be checking the current working directory first, rather than relative to the file which is executing the include statement.
There's not really anything WordPress can do here, it's mostly down to PHP's internal behaviours.
Based on the filenames here, this looks like it could quite possibly be caused by plugins using relative paths in their
include
s andrequire
s.ie.
require './my-other-file.php';
andrequire 'my-other-file.php';
rather thanrequire __DIR__ . '/my-other-file.php';
WordPress uses the latter in most placesPHP will see a relative path like that and resolve it according to it's
include_path
configuration, in most scenario's it should check the script directory first, but in your case, due to some configuration, it appears to be checking the current working directory first, rather than relative to the file which is executing the include statement.There's not really anything WordPress can do here, it's mostly down to PHP's internal behaviours.