Possible problem with the is_preview() function

[theshaft]

As I am no programmer, I'll provide info that produces the problem:
I use some javascript code to break my site out of foreign frames. This code conflicted with preview feature of the internal WP editor because the post tried to break out from the preview frame.
After, suggestion from people in the IRC channel, got it to work by editing the code in header.php file to the following:

<?php if ( !is_preview() ) { ?>
<script type="text/javascript">
<!--
if (parent.frames.length > 0)
{
parent.location.href = location.href;
}
-->
</script>
<?php } ?>

Expected Results:
Whenever I try to edit a draft or a published post, the javascript code should not be executed.

Actual Results:
When I edit:

• drafts: the js code is not executed
• published posts: the js code is executed
• private posts: the js code is executed

Reproducible: always

Steps to reproduce:

1. Add the above sample code to the header.php file, inside the head HTML tags.
2. Write a sample post and save it as a draft.
3. The draft can be editited
4. Publish the draft either as a private or public post
5. Editing it is not possible, as the js code is executed and breaks the preview out of the frame

Seems that when editing drafts the is_preview() value is true, but when editing published posts the is_preview() value is false.

[error]

is_preview should always return true on post preview, even if the post is already published. As shown here, it has uses other than ad serving. :)

[theshaft]

I have finally found a temporary solution for the issue I described above. Instead of the above code, I now use the following:

<?php if ( !isset($_SERVER['HTTP_REFERER']) || $_SERVER['REQUEST_URI'] == '/' || substr($_SERVER['HTTP_REFERER'], strlen(get_bloginfo('url')), 36) != '/wp-admin/post.php?action=edit&post=' ) { ?>
...CODE...
<?php } ?>

These 3 checks are necessary. It seems to work all right in all cases, but I have not tested it with google advertisements etc, as my site is ad-free.
I provide this is as a temporary solution. I have also made a post about it at: ​http://www.raoul.shacknet.nu/2006/01/01/a-temp-solution-for-the-is_preview-wp-issue/

[davidhouse]

Patch attached.

[error]

davidhouse, have you tested that patch? Just eyeballing it I see a serious problem in that it has a ?preview=true appended to the permalink; this approach won't work in all situations.

And I'd rather fix is_preview itself, rather than have to resort to nasty hacks; we have too many of those already. :)

[ryan]

Right, that patch won't work for all permalinks. We'd have to force get_permalink() to return crufty, query string style links and than add_query_arg() onto that.

function get_permalink($id = 0, $crufty_style = false) { ... }


get_permalink($post->ID, true);

[davidhouse]

You're saying it won't work in situations where pretty permalinks aren't being used? Fair enough, but the simple solution is to add_query_arg() straight onto the permalink, I think. Why wouldn't this work? There's code in add_query_arg() to deal with both situations, whether or not the permalink already has a '?' in it. So we could just change

<iframe src="<?php the_permalink(); ?>?preview=true" width="100%" height="600" ></iframe>

to

<iframe src="<?php echo add_query_arg('preview', 'true', get_permalink()); ?>" width="100%" height="600" ></iframe>

And this isn't an ugly hack. The user never sees the extra query arg as the URL is for an iframe. And there's no good way, apart from passing a parameter in, to tell if any given request for a published post is a preview or not. The admin page and preview are completely different, sandboxed requests.

[ryan]

Well, we need to verify it works. I think we strip query args off the end of permalinks. We could fix that, if so.

[davidhouse]

Seems to work for me.

[ryan]

(In [3473]) is_preview() fixes from David House. fixes #2188

[error]

Wow, that's an ugly hack.

[(none)]

Milestone 2.0.1 deleted