wp设置相对路径

Published

2022-11-28

浏览次数 : 297

我最近想把wp所有的样式文件和js文件改成相对路径，像这样：

变成：

第一个技巧: WP 强迫绝对链接

首先wp_make_link_relative无法在wp_enqueue_style里面使用，

wp_enqueue_style('joshuatzwp-style',wp_make_link_relative(get_stylesheet_uri()),array(),$cacheBustStamp,'all');

你指望 wp_make_link_relative 会生成一个相对的链接，但是仍然是绝对链接：

为什么会这样，下面我们分析下：

WordPress do_item 难题

为了搞清楚发生了什么，我从＜script＞和＜link＞标记实际回显到页面的位置开始向后追踪，看看HTML是如何生成的。大概是这样：

不管是 script class (wp-includes/class.wp-scripts.php) 还是 style class (wp-includes/class.wp-styles.php) 都有一个 do_item()方法负责解析每一个加载的 “附属” 然后打印出来
- 在 class.wp-scripts.php, there is inline code that prefixes any relative URL with $base_url
- 在 class.wp-styles.php, it uses a function called _css_href(), which also prefixes relative URLs with $base_url
The $base_url, which is a member of the shared extended class for both scripts and styles, and used to prefix URLs above, is actually filled with a value in wp-includes/script-loader.php
- This value ends up either being the result of site_url(), or wp_guess_url()
  - site_url() pulls it from get_site_url(), which pulls it from get_option('siteurl'), which comes from your admin settings
  - wp_guess_url() checks the global constant defined ‘WP_SITEURL’, and if that fails, tries to scrape it off the incoming request

None of this knowledge was strictly necessary to force relative paths, but it gives some insight into how the whole process works. I wouldn’t actually want to change any of these files, since they are part of the core of WP, and would be overwitten on a system update anyways.

The solution for relative paths:

The solution here is to hook into a WordPress filter. I’ve written about this before, when trying to add async/defer attributes to scripts and style tags, in this post. In fact, our solution is going to look pretty similar.

Basically, we will hook into the filter for ‘script_loader_tag’, which is the filter for <script> tags, and ‘style_loader_tag’, which is the filter for stylesheet <link> tags. In our hook, we will take the source that WordPress has prefixed and forced into an absolute URL, and remove the domain part that they added.

Here is the code:

function makeInternalLinkRelative($src){
    return str_replace(get_option('siteurl'),'',$src);
}

add_filter('style_loader_src',function($src, $handle){
    return makeInternalLinkRelative($src);
},10,4);
add_filter('script_loader_src',function($src, $handle){
    return makeInternalLinkRelative($src);
},10,4);

Pretty simple, huh! Just add this code to your theme’s (or child theme’s) function.php file, and you should be good to go!

The Solution for Dynamic Domains

If you don’t want to use relative paths, but just want WordPress to know when you are serving it through a different domain (such as when using Ngrok or swapping domains) and automatically adjust all the links, there is another solution we can employ. We can modify the wp-config.php file in the root of our WordPress install to dynamically set the “siteurl”, which as my earlier research pointed out, is used internally by WP to auto-prefix relative links.

Here is what I have added to my wp-config.php file:

↩

📋

–

🔎

$host = $_SERVER['HTTP_HOST'];
$protocol = ((!empty($_SERVER['HTTPS']) && $_SERVER['HTTPS'] !== 'off') || (isset($_SERVER['SERVER_PORT']) && $_SERVER['SERVER_PORT']===443)) ? 'https://' : 'http://';
define('WP_SITEURL', $protocol . $host);
define('WP_HOME', $protocol . $host);

Now, here is the really important thing. Make sure this code comes before this line of code that should already be in the file:

require_once(ABSPATH . 'wp-settings.php');

This matters because wp-settings.php is responsible for the chain of events that fills in the $base_url variable we were looking at earlier, and is ultimately responsible for prefixing URLs. If that runs before you set the “siteurl” global, it will have the domain from your admin settings, not from our dynamic override. I found this out the hard way!

Sign In