WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 5 months ago

#37060 new defect (bug)

wp-load.php wrong paths

Reported by: DuckDagobert Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.5.2
Component: General Keywords:
Focuses: performance Cc:
PR Number:

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 (2)

#1 follow-up: @dd32
3 years ago

Based on the filenames here, this looks like it could quite possibly be caused by plugins using relative paths in their includes and requires.
ie. require './my-other-file.php'; and require 'my-other-file.php'; rather than require __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.

#2 in reply to: ↑ 1 @DuckDagobert
3 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 includes and requires.
ie. require './my-other-file.php'; and require 'my-other-file.php'; rather than require __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.

Note: See TracTickets for help on using tickets.