带有损坏图像的 WordPress 奇怪(第 2 部分) [英] WordPress oddity with broken images (part 2)
问题描述
你能告诉我你对此的看法吗，看看你能不能重现它?有两种情况:
Can you tell me your opinion of this, and possibly see if you can recreate it? There are TWO scenarios:
场景 1(按预期工作)...
$post->post_content 变量包含这个(带有一个有效的图片 src):
The $post->post_content variable contains this (with a VALID image src):
(string) "before [hw] <img src="/path/to/valid_image.gif" /> after"
这段代码放在主题header.php的顶部...
This code placed at the top of the theme header.php...
1: echo test_out();
2:
3: function test_out() {
4: global $post;
5: error_log( 'stage_1' );
6: $str = $post->post_content;
7: error_log( 'stage_2' );
8: var_dump( isset( $str ) );
9: error_log( 'stage_3' );
10: $str = test_core_wp( 'test_shortcode', $str );
11: error_log( 'stage_4' );
12:
13: return $str;
14: }
15:
16: function test_shortcode( $content ) {
17: return str_replace( '[hw]', 'Hello World!', $content );
18: }
19:
20: function test_core_wp( $function, $a = NULL ) {
21: $wrap = array ( 'test_shortcode' => 'test_shortcode' );
22:
23: if ( isset( $a ) ) $args[] = $a;
24:
25: return call_user_func_array( $wrap[ $function ], $args );
26: }
输出这个(正确)...
bool(true)
before Hello World! <img src="/path/to/valid_image.gif" /> after
在 PHP 日志中(正确)...
[22-Jul-2009 11:49:36] stage_1
[22-Jul-2009 11:49:36] stage_2
[22-Jul-2009 11:49:36] stage_3
[22-Jul-2009 11:49:36] stage_4
场景 2(出现问题的地方)...
$post->post_content 变量现在包含:(带有无效图像 src):
The $post->post_content variable now contains: (with an INVALID image src):
(string) "before [hw] <img src="/path/to/broken_image.gif" /> after"
输出这个(仍然正确)...
bool(true)
before Hello World! <img src="/path/to/broken_image.gif" /> after
在 PHP 日志中使用此内容(这是问题)...
With this in the PHP log (THIS IS THE PROBLEM)...
[22-Jul-2009 11:56:11] stage_1
[22-Jul-2009 11:56:11] stage_2
[22-Jul-2009 11:56:11] stage_3
[22-Jul-2009 11:56:11] stage_4
[22-Jul-2009 11:56:11] stage_1
[22-Jul-2009 11:56:11] stage_2
[22-Jul-2009 11:56:11] stage_3
[22-Jul-2009 11:56:11] PHP Warning: Missing argument 1 for test_shortcode() in
/path/to/header.php on line 16
[22-Jul-2009 11:56:11] stage_4
test-out() 函数似乎自己运行了两次，但仅当 $post->post_content 包含损坏的图像时才运行.
The test-out() function seems to be running itself TWICE, but only when $post->post_content contains a broken image.
仅供参考，使用 Firefox，您可以通过点击 CTRL-R 重新加载网页源代码.重新加载源时，没有问题.但是，在浏览器选项卡(或任何浏览器)中重新加载网页时，我收到如上所示的警告.
FYI, with Firefox you can reload the web page source by hitting CTRL-R. When reloading the source, no problems. However, when reloading the web page in the browser tab (or ANY browser), I get the warning shown above.
我已经确认，只有在变量 $post->post_content(或任何 $post 变量，对于您的 WordPress 大师)中有损坏的 img src 时才会发生这种奇怪的情况.
I have confirmed the oddity only occurs when there is a broken img src in the variable $post->post_content (or any of the $post variables, for you WordPress gurus).
你有没有机会重现这个并告诉我你的想法?我是 PHP 新手，但我很确定正在发生的事情超出了我的知识范围.:)
Any chance you can reproduce this and tell me what you think? I'm new to PHP, but I'm pretty sure something is going on that is way beyond my knowledge. :)
我正要开始检查我的本地开发环境，但一位朋友给我写信:
I was about to start checking my local dev environment, but a friend wrote me:
看了你的帖子，我觉得我可能知道发生了什么.
After looking at your post, I think I may have an idea what's going on.
我认为警告信息你说的是被当您在浏览器中显示加载了有问题的页面，但您的帖子表示您正在看到PHP 日志中的警告消息反而.是否只出现在PHP日志?是
I had assumed that the warning message you were talking about was being displayed in the browser when you loaded the page in question, but your post indicates that you're seeing the warning message in the PHP log instead. Is it only appearing in the PHP log? YES
如果是这样，那么考虑这个解释....
If that's so, then consider this explanation....
如果您将帖子正文包含一个有效的标签图像，然后您的代码正在运行一次按预期生成页面.浏览器看到呈现的页面并然后尝试加载图像.这服务器找到图像并对其进行处理直接向上 - 这里没有惊喜.
In the case where you the post body contains an tag to a valid image, then your code is being run once to generate the page as expected. The browser sees the rendered page and then attempts to load the image. The server finds the image and dishes it up directly - no surprises here.
在帖子正文的情况下包含一个无效的标签图像，然后您的代码正在运行一次生成页面，就像前.然后浏览器做一个单独的 HTTP 连接尝试加载图像.通常，它会只需触发 404 错误，然后浏览器会显示损坏的图像，故事结局.但是，如果破碎图像 URL 指向您下面的内容Wordpress 安装，然后 Wordpress覆盖默认的 Web 服务器 404行为和盘点一个花哨的404未找到"页面而不是网络服务器的默认 404 页面.这是踢球者——Wordpress 花哨的 404 页面包括与相同的页眉和页脚它显示的所有其他页面.所以如果您在顶部有此代码你的标题，它会被再次调用Web 服务器发送的 404 页面响应丢失的图像，您的浏览器请求它.
In the case where the post body contains an tag to an invalid image, then your code is being run once to generate the page, just as before. Then the browser makes a separate HTTP connection to attempt to load the image. Normally, it would just trigger a 404 error and the browser would display a broken image, end of story. However, if the broken image URL is to something under your Wordpress installation, then Wordpress overrides the default web server 404 behavior and dishes up a fancy "404 Not Found" page instead of the web server's default 404 page. Here's the kicker -- Wordpress's fancy 404 page includes the same header and footer as all the other pages it displays. So if you have this code at the top of your header, it'll get called again by the 404 page that the web server sends in response to the missing image your browser requested from it.
你从来没有真正看到过 404 页面这种情况，因为它正在响应生成请求，而不是页面请求，所以浏览器只是将响应视为坏图像并显示损坏的图像图标，但它实际上是生成并发送.
You never actually see the 404 page in this case, because it's being generated in response to an request, not a page request, so the browser just treats the response as a bad image and shows the broken image icon, but it is actually being generated and sent.
比较这个(一个有效的图片网址在Wordpress 安装):
Compare this (a valid image URL under a Wordpress installation):
http://www.example.com/foo.jpg
到这个(一个无效的图片网址下Wordpress 安装):
to this (an invalid image URL under a Wordpress installation):
http://www.example.com/foo.jpg
注意自定义 404 页面，包括返回的标头...?
Note the custom 404 page including header that gets returned...?
而且...在 404 的上下文中页面，$post 对象不存在，所以 $post->post_content 显然不是一个字符串.
And... in the context of the 404 page, the $post object doesn't exist, so $post->post_content obviously isn't a string.
我认为警告信息正在浏览器中显示原始页面加载，这就是为什么我没有真正考虑过这种情况，但如果它只是输出到你的PHP 日志，那么它是完全有道理的.
I had assumed that the warning message was being displayed in the browser on the original page load, which is why I didn't really consider this situation, but if it's just being output to your PHP log, then it makes perfect sense.
如果是这样的话，那么你可以要么忽略警告，因为它真的没有区别，或者你可以测试对于您的代码中的这种情况(例如你提到的 isset 解决方法之前).
And if that is the case, then you can either ignore the warning as it really makes no difference, or you can test for that situation in your code (like the isset workaround you mentioned before).
任何其他想法，让我知道，但是这似乎符合我所知道的到目前为止.
Any other thoughts, let me know, but that seems to fit with what I know about it so far.
推荐答案
它是否只出现在 PHP 日志中?
Is it only appearing in the PHP log?
是的.
好的.然后，针对丢失图像的请求运行的自定义 404 处理程序几乎肯定是导致警告的原因.由于警告没有显示在任何地方，忽略它是安全的，或者如果您不希望它弄乱您的日志，您可以使用您的 isset 测试.无论如何，这确实不是问题，但至少现在您知道它是从哪里来的，并且这不是某些真正问题的迹象.
OK. Then the custom 404 handler being run on the request for the missing image is almost certainly what is causing the warning. Since the warning's not being displayed anywhere, it's safe to ignore, or you can use your isset test if you don't want it cluttering your log. In any event, it's really a non-issue, but at least now you know where it was coming from and that it's not a sign of some real problem.
我认为 (DEV) 环境根本不应该与它有任何关系.它在设置了真实 DNS 条目的实时服务器上的行为方式相同.
I don't think that (DEV) environment should have anything to do with it at all. It'd behave the same way on a live server with a real DNS entry set up.
这篇关于带有损坏图像的 WordPress 奇怪(第 2 部分)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
