Take the 2-minute tour ×
WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

I'm trying to find the best approach to customising the edit post screen for a custom post type.

I want to add a button which, when clicked will trigger code which looks up an external (not WP) database, gets some data, and then updates various fields - both core WP fields and custom meta fields. Ideally, the updates should update fields in the editor, but not commit anything to the WP database until the user then saves the edits (with the normal 'update' button).

So far, I have tried adding a submit button in the metabox, and then hooking into 'wp_insert_post_data'. That works, but I get a browser "The changes you made will be lost if you navigate away from this page" message if any fields have been edited which I don't want.

As for updating the data, I am updating $post by hooking into 'dbx_post_advanced', and adding my own filters to hook into my custom meta fields, which updates what goes into the fields without updating the DB. Again, that works, but 'dbx_post_advanced' feels a bit hackish as it is buried deep in edit-form-advanced.php and there's no documentation I could find as to what it is meant to be used for.

Is there a better way to achieve this, or at least some way to avoid the browser complaining that I'm moving away from a page where I have made edits?

share|improve this question
1  
I'm not sure I follow. So, basically, you want the user to hit a button, which will populate certain form fields automatically (after querying an external DB). Is that right? –  vancoder Mar 21 '13 at 19:23
    
For the error message Are you trying to stop the warning message, have it save when the button is clicked or discard the changes when the button is clicked? –  Joe Izzard Mar 21 '13 at 19:31
    
@vancoder yes - hit button, get data, update fields in edit post screen. –  rowatt Mar 21 '13 at 19:50
    
@JoeIzzard I want to avoid the warning message. I can save/discard changes as required by filtering 'wp_insert_post_data'. –  rowatt Mar 21 '13 at 19:54
    
Sounds to me like you should be doing this with AJAX and aren't. –  s_ha_dum Mar 28 '13 at 0:17
add comment

2 Answers

up vote 0 down vote accepted

Add the Javascript code below to your submit button. This should remove the event that provides the warning. Please note that this code is untested.

window.onbeforeunload = null;

This should disable the property however as stated above this code is untested.

Cheers,
Joe

share|improve this answer
    
Thanks. That works, and answer accepted. In the meantime, though I've come to the conclusion that my whole approach was flawed (see my answer below), and have tackled the problem in a different way which avoids this whole issue. –  rowatt Mar 26 '13 at 14:33
add comment

For posterity's sake and in case anyone else finds this, I've come to the conclusion that my original approach is flawed. While I can stop the browser complaining that a field has been changed using the solution suggested by @JoeIzzard, having a submit button on the post edit screen is so tied into WordPress's updating of a post, I found I was having to go to great lengths to hack my way around WordPress trying to save everything.

Instead, I've settled on the following approach which so far is working as required.

  1. create a button using an anchor tag and button class (i.e. <a href="#" class="button">Clickme</a> )
  2. bind a jquery click handler to that button (i.e. jQuery('#buttonid').click( function(e){...});) )
  3. in that click handler, do an ajax call to a PHP function which is triggered with WordPress's wp_ajax_ handler.
  4. from that PHP function I can do whatever needs to be done, and return a json object with any field values which should be changed
  5. the jQuery ajax done handler updates fields as required

That approach allows me to perform any actions I want from the post edit screen, without having to hack around WordPress's normal post saving routines.

If I did want to update post fields at the same time, then my original approach would probably be better, and Joe's suggestion would prevent any browser complaints if fields had been edited.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.