Ticket #2188 (closed defect: fixed)

Opened 3 years ago

Last modified 2 years ago

Possible problem with the is_preview() function

Reported by: theshaft Assigned to: anonymous
Priority: normal Milestone:
Component: Administration Version: 2.0
Severity: normal Keywords: bg|has-patch bg|commit
Cc:

Description

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.

Attachments

2188.diff (2.1 kB) - added by davidhouse on 01/01/06 13:52:14.

Change History

01/01/06 03:00:10 changed by error

  • milestone set to 2.1.

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. :)

01/01/06 11:30:39 changed by 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/

01/01/06 13:51:15 changed by davidhouse

  • keywords set to bg|has-patch.

Patch attached.

01/01/06 13:52:14 changed by davidhouse

  • attachment 2188.diff added.

01/02/06 03:54:19 changed by 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. :)

01/02/06 09:33:17 changed by 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);

01/05/06 21:18:51 changed by 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.

01/06/06 01:28:25 changed by ryan

  • milestone changed from 2.1 to 2.0.1.

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

01/23/06 18:49:34 changed by davidhouse

  • keywords changed from bg|has-patch to bg|has-patch bg|commit.

Seems to work for me.

01/23/06 23:39:59 changed by ryan

  • status changed from new to closed.
  • resolution set to fixed.

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

01/24/06 17:29:11 changed by error

Wow, that's an ugly hack.

11/30/06 19:41:49 changed by

  • milestone deleted.

Milestone 2.0.1 deleted