Do you know me your opinion of the, and perhaps try to recreate it? You will find TWO situations:

SCENARIO 1 (works as intended)...

The $publish->post_content variable consists of this (having a VALID image src):

(string) "before [hw] <img src="/path/to/valid_image.gif" /> after"

This code placed towards the top of the theme header.php...

1: echo test_out();
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' );
13:    return $str;
14: }
16: function test_shortcode( $content ) {
17:    return str_replace( '[hw]', 'Hello World!', $content );
18: }
20: function test_core_wp( $function, $a = NULL ) {
21:    $wrap = array ( 'test_shortcode' => 'test_shortcode' );
23:    if ( isset( $a ) ) $args[] = $a;
25:    return call_user_func_array( $wrap[ $function ], $args );
26: }

Results this (properly)...

before Hello World! <img src="/path/to/valid_image.gif" /> after

With this particular within the PHP log (properly)...

[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

SCENARIO 2 (in which the problem happens)...

The $publish->post_content variable now consists of: (by having an INVALID image src):

(string) "before [hw] <img src="/path/to/broken_image.gif" /> after"

Results this (STILL properly)...

before Hello World! <img src="/path/to/broken_image.gif" /> after

With this particular within the PHP log (This Is Actually 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

The test-out() function appears to become running itself Two times, only when $post->post_content consists of a damaged image.

FYI, with Opera you are able to reload the site source by striking CTRL-R. When reloading the origin, no problems. However, when reloading the site within the browser tab (or ANY browser), I recieve the warning proven above.

I've confirmed the oddity only happens when there's a damaged img src within the variable $publish->post_content (or the $publish variables, for you personally WordPress gurus).

Any chance you are able to reproduce this and let me know what you believe? I am a new comer to PHP, but I am confident something is happening that's way beyond my understanding. :)


I had been going to start checking my local dev atmosphere, but a buddy authored me:

After searching at the publish, I believe I may know what's happening.

I'd assumed the warning message you had been speaking about had been displayed within the browser whenever you loaded the page under consideration, however your publish signifies that you are seeing the warning message within the PHP log rather. Could it be only showing up in the PHP log? YES

If you do, then think about this explanation....

Within the situation in which you the publish body consists of an tag to some valid image, your code has been run once to create the page not surprisingly. The browser sees the made page and then tries to load the look. The server finds the look and dishes it up directly - keep surprises away here.

Within the situation in which the publish body consists of an tag for an invalid image, your code has been run once to create the page, just like before. Then your browser constitutes a separate HTTP connection to try to load the look. Normally, it might just trigger a 404 error and also the browser would display a damaged image, finish of story. However, when the damaged image URL would be to something beneath your Wordpress installation, then Wordpress overrides the default web server 404 behavior and dishes up an expensive "404 Not Found" page rather than the net server's default 404 page. Here's the kicker -- Wordpress's fancy 404 page includes exactly the same header and footer as the rest of the pages it shows. So for those who have this code towards the top of your header, it'll get known as again by the 404 page the web server transmits in reaction towards the missing image your browser asked for from this.

You won't ever really begin to see the 404 page in this situation, since it is being produced in reaction for an request, not really a page request, therefore the browser just goodies the response like a bad image and shows the damaged image icon, but it's really being produced and sent.

Match it up (a legitimate image URL under a Wordpress installation):

for this (an invalid image URL within Wordpress installation):

Note the custom 404 page including header that will get came back...?

And... poor the 404 page, the $publish object does not exist, so $publish->post_content clearly is not a string.

I'd assumed the warning message had been displayed within the browser on the initial page load, and that's why I did not really think about this situation, but when it is simply being output for your PHP log, it makes sense.

And when that's the situation, you'll be able to either disregard the warning because it really does not matter, or test for your situation inside your code (like the isset workaround you pointed out before).

Every other ideas, tell me, but that appears to suit using what I understand about this to date.