Make WordPress Core

Opened 16 years ago

Closed 16 years ago

Last modified 15 years ago

#2188 closed defect (bug) (fixed)

Possible problem with the is_preview() function

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


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;
<?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 (1)

2188.diff (2.1 KB) - added by davidhouse 16 years ago.

Download all attachments as: .zip

Change History (12)

#1 @error
16 years ago

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

#2 @theshaft
16 years ago

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=' ) { ?>
<?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/

#3 @davidhouse
16 years ago

  • Keywords bg|has-patch added

Patch attached.

16 years ago

#4 @error
16 years ago

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

#5 @ryan
16 years ago

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);

#6 @davidhouse
16 years ago

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>


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

#7 @ryan
16 years ago

  • 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.

#8 @davidhouse
16 years ago

  • Keywords bg|commit added

Seems to work for me.

#9 @ryan
16 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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

#10 @error
16 years ago

Wow, that's an ugly hack.

#11 @(none)
15 years ago

  • Milestone 2.0.1 deleted

Milestone 2.0.1 deleted

Note: See TracTickets for help on using tickets.