Implement fix to issue requesting wp-load.php#158
Implement fix to issue requesting wp-load.php#158mariusveltan wants to merge 1 commit intopresslabs:masterfrom hipmill:master
Conversation
vtemian
left a comment
vtemian
left a comment
There was a problem hiding this comment.
Thanks!
Maybe we can move it into a helper function and add a test for it.
| //$wordpress_loader = $_SERVER['DOCUMENT_ROOT'] . '/wp-load.php'; | ||
| $wordpress_loader = filter_input(INPUT_SERVER, 'DOCUMENT_ROOT', FILTER_SANITIZE_STRING) . '/wp-load.php'; | ||
|
|
||
| $current_dir = __DIR__; |
There was a problem hiding this comment.
We should not drop the previous approach so that we don't break backward compatibility. Also checking for wp-content/plugins is to narrow scoped, since the plugin can be installed in mu-plugins as well, and also wp-content can be set in wp-config.php.
I think we should check like this:
$wordpress_loader = "$current_dir/../../../wp-load.php";
if ( file_exists($wordpress_loader) ) ...
|
Maybe we can use https://developer.wordpress.org/reference/hooks/query_vars/ or this https://codex.wordpress.org/Plugin_API/Action_Reference/template_redirect to ultimately get rid of this wp-load.php ? we can use something like: http://example.com/?gitium_webhook=1 so that WP is loaded but no content is generated. This way we get rid of the search for wp-load. |
|
I will close this for now. I opened #205 which should fix this. |
6 participants
Fixes #148 by doing an explode on the webhook script path, with "wp-content/plugins" as delimiter. This way, the WP core root is obtained, regardless whether WP is running in the site webroot, or under a sub-directory in the webroot.