WordPress.org

Make WordPress Core

Opened 11 months ago

Closed 7 months ago

#25023 closed defect (bug) (fixed)

WordPress 3.6 deleting data on custom post meta

Reported by: cdwharton Owned by:
Milestone: 3.7 Priority: normal
Severity: critical Version: 3.6
Component: Administration Keywords: has-patch
Focuses: Cc:

Description (last modified by helen)

Everything worked fine in WordPress 3.5 but after upgrading to WordPress 3.6 and then simply editing (not saving) a post with custom post meta caused all custom post meta to be cleared and deleted from the database.

Here is the code I am using to generate and save the custom meta. Admittedly it is a bit old now. I haven't been able to narrow down the issue other than I think it is something in the save function causing the issue, maybe the autosave?

The main concern is that the data is there until you edit, when you edit (and do not save) it deletes.

/* #######################################################################

	Custom Meta for Page Summary

####################################################################### */

function page_summary_init(){
	add_meta_box("page_summary-meta", __("Enter the page summary" , "textdomain"), "page_summary_meta_options", "page", "normal", "high");
	add_meta_box("page_summary-meta", __("Enter the page summary" , "textdomain"), "page_summary_meta_options", "case_study", "normal", "high");
}

function page_summary_meta_options(){
	global $post;
	$custom = get_post_custom($post->ID);

	$page_summary = "";
		
	if( isset( $custom["page_summary"] ) ) {
		$page_summary = $custom["page_summary"][0];
	}

?>
	<div>
		<div style="padding: 10px 0;"><i><b><?php _e("If this page is a sub page, you can enter the page summary here and it will be fed up to the landing page." , "textdomain"); ?></b></i></div>
		<textarea class="large-text" rows="10" name="page_summary" id="page_summary"><?php echo $custom["page_summary"][0]; ?></textarea> <br />
	</div>
<?php
}

function save_page_summary_meta(){
	global $post;
	if (isset( $post->post_type) && $post->post_type == 'page' || $post->post_type == 'case_study' ){
		if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) {
		return $post->ID;
		} else {
			if( isset( $post->ID ) ) {
				update_post_meta($post->ID, "page_summary", $_POST["page_summary"]);
			}
		}
	}	
}

add_action("admin_init", "page_summary_init");
add_action('save_post', 'save_page_summary_meta');

Attachments (6)

25023.sql.update.diff (3.9 KB) - added by jeremyfelt 11 months ago.
debug-backtrace.txt (16.2 KB) - added by c3mdigital 11 months ago.
Debug Backtrace on entering edit.php the first time
25023.patch (1.5 KB) - added by SergeyBiryukov 11 months ago.
25023.2.patch (927 bytes) - added by SergeyBiryukov 11 months ago.
25023.diff (868 bytes) - added by nacin 11 months ago.
Slight cleanup; adds comment; avoids GLOBALS so we are restoring to the same scope from whence it came
25023.2.diff (1.5 KB) - added by nacin 9 months ago.

Download all attachments as: .zip

Change History (56)

comment:1 helen11 months ago

  • Description modified (diff)

comment:2 cdwharton11 months ago

After some more testing I think the issue is related to...

add_action('save_post', 'save_page_summary_meta');

This seems to be firing as the edit screen loads, I'm guessing the data hasn't loaded at this stage so it is clearing it?

Any help would be great (thanks Helen for tidying my original code too :) )

comment:3 follow-up: nacin11 months ago

save_post has been firing when the edit screen loads since, I think, 3.0. I'm sure it has to do with the save_post callback, but I'm not sure what changed from 3.5 to 3.6 to cause any further problems for you.

comment:4 follow-up: wonderboymusic11 months ago

the reporter isn't checking for DOING_AJAX - it's probably happening during Quick Edit

comment:5 in reply to: ↑ 3 ; follow-up: cdwharton11 months ago

Replying to nacin:

save_post has been firing when the edit screen loads since, I think, 3.0. I'm sure it has to do with the save_post callback, but I'm not sure what changed from 3.5 to 3.6 to cause any further problems for you.

Well its definitely clearing meta data saved in 3.5 since upgrading to 3.6. Save_post doesnt seem to load when custom meta has been added via 3.6 though. Is there a simple check I can make on the function to check if its blank on initial load to just ignore until "Publish" is hit?

comment:6 in reply to: ↑ 4 cdwharton11 months ago

Replying to wonderboymusic:

the reporter isn't checking for DOING_AJAX - it's probably happening during Quick Edit

It's using the "Edit Page" full content editor where the data is being cleared.

Is there a better way to add custom meta boxes than the example I have provided?

comment:7 in reply to: ↑ 5 ; follow-up: helen11 months ago

Replying to cdwharton:

Is there a simple check I can make on the function to check if its blank on initial load to just ignore until "Publish" is hit?

You need a nonce field and to check the nonce before continuing on in your save_post callback.

Is there a better way to add custom meta boxes than the example I have provided?

In this particular example, I am wondering why you don't use the excerpt. There are also a few things that should be changed, but Trac is not really the place for a non-core code review.

comment:8 in reply to: ↑ 7 ; follow-up: cdwharton11 months ago

Replying to helen:

Replying to cdwharton:

Is there a simple check I can make on the function to check if its blank on initial load to just ignore until "Publish" is hit?

You need a nonce field and to check the nonce before continuing on in your save_post callback.

Is there a better way to add custom meta boxes than the example I have provided?

In this particular example, I am wondering why you don't use the excerpt. There are also a few things that should be changed, but Trac is not really the place for a non-core code review.

Thanks Helen, I'm not using excerpt as its a page not a post and that it would confuse the end user (trust me it would). I'm not after a code review necessarily, what I am looking for is for someone to tell me why the data is being deleted since upgrading to WP 3.6. If its because I'm not using a nonce field then that's fine - I will implement that.

The code I have used is readily available as you search the internet and its been working for me for a couple of years now. My concern is not only for myself and my clients that upgrade to 3.6 but other theme authors out there who use the same technique which up to this point seemed solid.

Is there going to be an investigation into the cause of the data deletion, because it is happening and I can reproduce the bug?

comment:9 in reply to: ↑ 8 ; follow-up: nacin11 months ago

Replying to cdwharton:

Is there going to be an investigation into the cause of the data deletion, because it is happening and I can reproduce the bug?

To be clear, are these your steps to reproduce?

  • Create a page.
  • Add a page_summary data point.
  • Save.
  • Edit that page again.
  • Let autosave run.
  • Lose data.

There's nothing your code is doing that suggests to me there would be a change in behavior from 3.5 to 3.6. That's the thing we need to figure out right now.

comment:10 in reply to: ↑ 9 cdwharton11 months ago

Replying to nacin:

Replying to cdwharton:

Is there going to be an investigation into the cause of the data deletion, because it is happening and I can reproduce the bug?

To be clear, are these your steps to reproduce?

  • Create a page.
  • Add a page_summary data point.
  • Save.
  • Edit that page again.
  • Let autosave run.
  • Lose data.

There's nothing your code is doing that suggests to me there would be a change in behavior from 3.5 to 3.6. That's the thing we need to figure out right now.

Ok, steps to reproduce...

  1. Run WordPress 3.5
  2. Create a page
  3. Fill out custom meta on said page
  4. Save
  5. Upgrade to WP 3.6
  6. View Page on front end and verify data is still there
  7. Edit page
  8. Observe custom meta field is now blank without any intervention, saving, preview - nothing
  9. View page and verify data has now been deleted
  10. Start to cry ;)

comment:11 cdwharton11 months ago

Adding a nonce field check does seem to remedy the issue - Helen thank you so much for this.

If the issue is due to out of date code on my part then that's on me to remedy.

However, as this involves data deletion I am concerned for other end users who upgrade to WP 3.6 on a theme that has the same technique implemented.

As we all know, no one ever seems to back their data up before they excitedly update to the latest WordPress and I want to try and save some sad bunnies if I can.

Please let me know what else you need from me to isolate and resolve this.

Thanks to everyone who has helped me today, it is greatly appreciated and one of the reasons I love WordPress and the WordPress community so much.

comment:12 follow-up: johnbillion11 months ago

  • Component changed from General to Administration
  • Keywords reporter-feedback added; needs-patch needs-testing removed

I'm unable to reproduce the issue using cdwharton's code above. Can anyone reproduce the issue?

cdwharton: Can you reproduce the issue with all your other plugins deactivated (and your example code in an isolated plugin) and the default theme active?

comment:13 in reply to: ↑ 12 cdwharton11 months ago

Replying to johnbillion:

I'm unable to reproduce the issue using cdwharton's code above. Can anyone reproduce the issue?

cdwharton: Can you reproduce the issue with all your other plugins deactivated (and your example code in an isolated plugin) and the default theme active?

Thanks, I'll put together a basic theme with the issue in it. I'm not sure why this would need to be a plugin on the default theme? I don't do plugins - is it just as simple as adding JUST the custom meta function?

comment:14 johnbillion11 months ago

The aim is to use the default theme that ships with WordPress or a theme that doesn't contain any custom functionality. This helps eliminate other factors, such as code in the theme that's interfering. Your code can either be in a plugin or in a theme, just as long as it's separated. If you can reproduce the problem with this separated code then it'll need to be investigated further.

comment:15 follow-up: johnbillion11 months ago

Can anyone else reproduce this issue? It's potentially a major bug, but I'm unable to reproduce it with cdwharton's isolated code. I'm tempted to say there must be another factor involved such as another plugin, but that doesn't necessarily negate the issue.

cdwharton, were you able to test and reproduce this issue with your other plugins deactivated?

comment:16 c3mdigital11 months ago

  • Keywords close added

I can not reproduce this following the reporters exact steps and upgrading from 3.5.2 to 3.6. The provided code is slightly flawed but it does and should always work.

Instead of calling global $post he should be getting the $post object from the function in both the save and add_meta_box callbacks. Maybe another plugin is somehow polluting global $post? and when the edit page loads the meta boxes are empty because the post ID is wrong? Just a thought but that is the only thing I can think of.

He should also be doing a comparison on the saved meta vs the $_POST 'd meta and only call update_post_meta if something has changed.

Reporter,
Please test again with no plugins activated and using one of the default themes. Additionally to test my theory test your current configuration that is causing this issue and add the following code somewhere.

add_action( 'save_post', function( $post_id, $post_object ) {
      var_dump( $post_object->ID );
      global $post;
      var_dump( $post->ID );
      wp_die();
}. 10, 2 );

Open a page with the metabox contents and hit publish and compare the 2 post ids to see if they match.

comment:17 in reply to: ↑ 15 ; follow-up: cdwharton11 months ago

  • Keywords close removed

Replying to johnbillion:

Can anyone else reproduce this issue? It's potentially a major bug, but I'm unable to reproduce it with cdwharton's isolated code. I'm tempted to say there must be another factor involved such as another plugin, but that doesn't necessarily negate the issue.

cdwharton, were you able to test and reproduce this issue with your other plugins deactivated?

Hi John,

You can replicate the issue with the steps below.

I've cloned Twenty Twelve theme and literally just updated style.css to show different title and added a simple custom meta function to the bottom of functions.php

https://www.dropbox.com/s/2ogfzg54h8rojh7/twentytwelve-bug.zip

If you get a version of WP 3.5.2 up and running, install theme - go to a page, fill out the custom meta. Then upgrade to WP 3.6 - edit that page and the custom meta is gone.

Here is a video of the way to reproduce...

http://youtu.be/-LufS4eTxqg

Incidentally, I've tried it with a plugin and the issue does not replicate - I don't know whether plugin meta is saved to a different table than theme meta?

Anyway, I hope this helps and sorry its taken a while to get round to providing an example.

Last edited 11 months ago by cdwharton (previous) (diff)

comment:18 in reply to: ↑ 17 ; follow-up: c3mdigital11 months ago

Replying to cdwharton:

Here is a video of the way to reproduce...

http://youtu.be/-LufS4eTxqg

Incidentally, I've tried it with a plugin and the issue does not replicate - I don't know whether plugin meta is saved to a different table than theme meta?

Anyway, I hope this helps and sorry its taken a while to get round to providing an example.

cdwharton,
Thanks for taking the time to respond and capture the video. I could still not reproduce using your exact steps with the zip of theme you provided on a fresh install of 3.5.2. then upgrading to 3.6. We will keep investigating.

If you still have the install up from your video there is one test you can do that would be helpful. Add the code below to your functions.php then browse to any page on the front and copy and paste the output here.

	add_action( 'get_header', 'trac_bug_test' );
	function trac_bug_test() {
		global $wpdb;
		$var = $wpdb->get_results( "SELECT * FROM $wpdb->postmeta WHERE meta_key = 'bug'" );
		print '<pre>';
		print_r( $var );
		print '</pre>';
		die();
	}

comment:19 in reply to: ↑ 18 cdwharton11 months ago

Replying to c3mdigital:

Replying to cdwharton:

Here is a video of the way to reproduce...

http://youtu.be/-LufS4eTxqg

Incidentally, I've tried it with a plugin and the issue does not replicate - I don't know whether plugin meta is saved to a different table than theme meta?

Anyway, I hope this helps and sorry its taken a while to get round to providing an example.

cdwharton,
Thanks for taking the time to respond and capture the video. I could still not reproduce using your exact steps with the zip of theme you provided on a fresh install of 3.5.2. then upgrading to 3.6. We will keep investigating.

If you still have the install up from your video there is one test you can do that would be helpful. Add the code below to your functions.php then browse to any page on the front and copy and paste the output here.

	add_action( 'get_header', 'trac_bug_test' );
	function trac_bug_test() {
		global $wpdb;
		$var = $wpdb->get_results( "SELECT * FROM $wpdb->postmeta WHERE meta_key = 'bug'" );
		print '<pre>';
		print_r( $var );
		print '</pre>';
		die();
	}

I really don't understand how you couldn't get the same issue? Maybe its MySQL or OS related?

Here is the output from your script...

Array
(
    [0] => stdClass Object
        (
            [meta_id] => 4
            [post_id] => 2
            [meta_key] => bug
            [meta_value] => 
        )

)

Also, database info...

Database server

Server: Localhost via UNIX socket
Software: MySQL
Software version: 5.5.29 - Source distribution
Protocol version: 10
User: root@localhost
Server charset: UTF-8 Unicode (utf8)
Last edited 11 months ago by SergeyBiryukov (previous) (diff)

comment:20 jeremyfelt11 months ago

Could not reproduce with MySQL 5.5.32 / PHP 5.4.17

  1. Installed WordPress 3.5.2 clean
  2. Activated Twenty Twelve Bug theme
  3. Add New Page
  4. Publish page with Title, Content, Meta
  5. Click "Please Update Now" in to update WordPress
  6. Update Now, Update WordPress Database, Continue -> Welcome Screen
  7. Edit Page -> Title, Content, Meta all remain.

comment:21 WraithKenny11 months ago

I was able to reproduce.

SVN'd a local WP 3.5.2 and configured vanilla, running on xampp
logged in, edited default theme with the theme editor.

/* #######################################################################

	Custom Meta for bugs

####################################################################### */

	function bug_init(){
			add_meta_box("bug-meta", __("Enter Something in here"), "bug_meta_options", "page", "normal", "high");
	}

	function bug_meta_options(){
		global $post;
		$custom = get_post_custom($post->ID);

		$bug = "";
		
		if( isset( $custom["bug"] ) ) {
			$bug = $custom["bug"][0];
		}

?>
	<div>
		<div style="padding: 10px 0;"><i><b><?php _e("Enter whatever you want in here."); ?></b></i></div>
		<input class="large-text" type="text" name="bug" id="bug" value="<?php echo $custom["bug"][0]; ?>" /> <br />
	</div>
<?php
	}

function save_bug_meta(){
	global $post;
	if (isset( $post->post_type) && $post->post_type == 'page' ){
		if (defined('DOING_AUTOSAVE') && DOING_AUTOSAVE) {
		return $post->ID;
		} else {
			if( isset( $post->ID ) ) {
				update_post_meta($post->ID, "bug", $_POST["bug"]);
			}
		}
	}	
}

add_action("admin_init", "bug_init");
add_action('save_post', 'save_bug_meta');

Added to bottom of functions.php
Edited Sample Page to add meta
Upgraded
Visited page, clicked Edit on menu bar
Meta was blank.

(Subsequent meta edits stuck tho.)

comment:22 WraithKenny11 months ago

Watching mysql via phpmyadmin, the meta didn't disappear until the loading of the edit page after the upgrade.

It did get deleted.

comment:23 jeremyfelt11 months ago

Tried again following @WraithKenny's steps and was able to reproduce.

Starting with clean 3.5.2 and code snippet from above:

  • If I edit 'Sample Page' with meta and then update, the meta disappears.
  • If I create a new page and add meta before updating, the meta stays.

comment:24 helen11 months ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to 3.6.1

It's investigation time.

comment:25 jeremyfelt11 months ago

25023.sql.update.diff​ is the diff of my database before and after clicking 'Edit Page' when viewing Sample page. Beyond timestamps, a revision of the page is added and the post_meta is deleted.

c3mdigital11 months ago

Debug Backtrace on entering edit.php the first time

comment:26 c3mdigital11 months ago

After I added the meta before upgrading I added this to functions.php

add_action( 'save_post', 'debug_the_meta', 9, 2 );
function debug_the_meta( $post ) {
    var_dump( debug_backtrace() );
    var_dump( $_REQUEST );
    var_dump( $post );
    wp_die();
 }

See: results

Last edited 11 months ago by c3mdigital (previous) (diff)

comment:27 follow-ups: dd3211 months ago

Haven't tested, but this will be caused by our fix-the-revision-authors upgrade script, and the results above back that up.

Basically, checking DOING_AUTOSAVE is not enough, as save_post is triggered during the upgrade for posts with revisions (a new post has no revisions and thus, doesn't trigger this).
Plugins which include a nonce, and verify that as well when saving/updating the meta, won't trigger it since the nonce won't exist on the upgrade routine call.

comment:28 jeremyfelt11 months ago

From reporter's code:

if( isset( $post->ID ) ) {
	update_post_meta($post->ID, "page_summary", $_POST["page_summary"]);
}

The meta value is destroyed here because $_POST["page_summary"] is empty when save_post fires in this scenario.

comment:29 in reply to: ↑ 27 johnbillion11 months ago

Replying to dd32:

Haven't tested, but this will be caused by our fix-the-revision-authors upgrade script, and the results above back that up.

Confirmed. My stack trace on the editing screen for when this occurs:

update_metadata() <-- this sets the meta value in question to a blank string
update_post_meta()
save_bug_meta()
do_action( 'save_post' )
wp_insert_post()
_wp_put_post_revision()
wp_save_post_revision()
_wp_upgrade_revisions_of_post()

comment:30 follow-up: c3mdigital11 months ago

Sounds like we need a refresher post on the dev blog to remind on how to save postmeta.

comment:31 in reply to: ↑ 27 SergeyBiryukov11 months ago

Introduced in [24790].

The save_post call on initial page load after the update is caused by _wp_upgrade_revisions_of_post():
tags/3.6/wp-admin/edit-form-advanced.php#L117

It wouldn't have a difference in most cases, but the example script here does not check if $_POST['bug'] is set, and resets it to an empty value.

Last edited 11 months ago by SergeyBiryukov (previous) (diff)

comment:32 in reply to: ↑ 30 ; follow-up: WraithKenny11 months ago

Replying to c3mdigital:

Sounds like we need a refresher post on the dev blog to remind on how to save postmeta.

I think what we need is a better hook then 'save_post' for saving custom post meta (that checks automatically for things like autosave/revisions, and has distinct hooks for post types, and doesn't run more then once, maybe checks a default nonce or for an empty $_post), and replacing the codex examples. (maybe 'save_edit_screen_meta_boxes' and "save_{$post_type)_meta_boxes" or something, but that's for another ticket, I suppose.)

It would make new plugin code less fragile.

Back to the bug, the example code fails to check for Nonce, doesn't check for revision, doesn't sanitize or validate data... seems like a very rare edge-case. Plenty example code out there leaves out some checks, but all of that? I don't think it's worth fixing.

comment:33 in reply to: ↑ 32 johnbillion11 months ago

Replying to WraithKenny:

Back to the bug, the example code fails to check for Nonce, doesn't check for revision, doesn't sanitize or validate data... seems like a very rare edge-case. Plenty example code out there leaves out some checks, but all of that? I don't think it's worth fixing.

Just to clarify for OP's benefit, the root cause of the problem with the example code is that it's not checking for isset($_POST['bug']). This causes the meta data to be updated with an empty value when the save_post hook fires and there's nothing in $_POST.

The example code is broken, no doubt about it. It will break when Quick Edit is used, for example, along with any other time that wp_update_post() gets called, which could be any number of places in other plugins.

What's currently being discussed in IRC is whether core needs to handle this situation due to prevalence of code like this.

comment:34 SergeyBiryukov11 months ago

So, I was trying to find out why this only affects the sample page and not any other page that existed before the upgrade.

My initial thought was that wp_save_post_revision() (tags/3.6/wp-includes/revision.php#L598) is called because the sample page doesn't have a revision in the database. However, that's not the case, it does have one after we edit the custom field in the meta box and update the page. This behaviour is the same for manually created pages, there's no difference here.

The difference is that the sample page text contains 'pi&#241;a coladas' string (tags/3.6/wp-admin/includes/upgrade.php#L185). TinyMCE turns that into 'piña coladas', so the post content becomes different, which triggers the $post_has_changed flag in wp_save_post_revision() (tags/3.6/wp-includes/revision.php#L105), and ultimately leads to the wp_insert_post() call in _wp_put_post_revision().

Last edited 11 months ago by SergeyBiryukov (previous) (diff)

SergeyBiryukov11 months ago

comment:35 SergeyBiryukov11 months ago

25023.patch is an attempt to only call _wp_upgrade_revisions_of_post() on $_POST, by moving it from edit-form-advanced.php to edit_post(), before the post is updated.

comment:36 SergeyBiryukov11 months ago

To summarize, you need four prerequisites to reproduce the issue:

  1. WordPress 3.5.x or earlier.
  2. A post or page where the content is different from the latest revision.
  3. A custom meta value for that post.
  4. A custom code that fires on save_post and updates the meta value without checking if it actually was a $_POST request containing the custom field in question.

Then the steps to reproduce would be:

  1. Upgrade to 3.6.
  2. Visit the Edit screen for that post. The meta value will be gone.
Last edited 11 months ago by SergeyBiryukov (previous) (diff)

comment:37 c3mdigital11 months ago

  • Keywords has-patch added

SergeyBiryukov11 months ago

comment:38 SergeyBiryukov11 months ago

  • Keywords needs-testing added

25023.2.patch is an alternative approach, per IRC discussion.

comment:39 nacin11 months ago

25023.2.patch could very well break a save_post hook (or any other hook in the stack — there are probably more than a dozen) that is using global $post but is also doing the right checks. I think the actual feasibility of this is very, very limited; but so was this mess in the first place.

nacin11 months ago

Slight cleanup; adds comment; avoids GLOBALS so we are restoring to the same scope from whence it came

comment:40 nacin11 months ago

25023.diff is a cleanup of 25023.2.patch. I could go for it, but boy, I don't know. I would rather punt on this to 3.6.2.

comment:41 markjaquith10 months ago

No objection to punting.

comment:42 nacin10 months ago

  • Milestone changed from 3.6.1 to 3.6.2

comment:43 jlambe9 months ago

I have tested the patch and everything is working fine.
As said earlier, the custom code for building the Metabox and the custom field doesn't check if the

$_POST['bug']

is set and non empty when 'save_post' hook is fired. That's probably why he's loosing its value of the custom field.

comment:44 cdwharton9 months ago

Hi Everyone,

Thanks for looking into this and releasing the patch. What would be really handy was a definitive way of handling custom meta. Admittedly, the code was old however I can't find something that fully explains how to handle it.

Perhaps if someone could rework my code into the correct code then at least I would learn from it and help me, resources on the internet are focused on this technique http://wp.smashingmagazine.com/2011/10/04/create-custom-post-meta-boxes-wordpress/ which is also out of date (although has a nonce check).

If someone can provide the defacto way of handling custom post meta then that would be super-fantastic. If this is already in the Codex, I couldn't find it so please let me know where to find it.

Cheers

Chris

nacin9 months ago

comment:45 nacin9 months ago

After talking with SergeyBiryukov, jeremyfelt, johnbillion, atimmer, and simonwheatley (WordCamp Europe contributor day), it is time for this to be fixed.

The global $post juggling is actually *not* the only problem. Even if you use $post_id from the save_post hook, update_post_meta() will take the revision ID and then choose to update the post ID again.

Even someone who was checking DOING_AUTOSAVE and DOING_AJAX and using $post_id instead of global $post is affected. In our mind, that approaches and probably crosses the line of ignoring developer error versus a recognition that saving meta boxes is complicated and that this is a really bad bug if you catch it.

25023.2.diff moves the upgrade to POST.

comment:46 nacin9 months ago

In 25719:

Move the revisions upgrade handler to POST, to avoid esoteric metadata stomping.

props SergeyBiryukov.
see #25023.
for trunk.

comment:47 nacin9 months ago

  • Keywords commit fixed-major added; needs-testing removed

comment:48 markoheijnen8 months ago

Can this ticket be closed now?

comment:49 cdwharton8 months ago

Hi Mark,

Before you close, is someone could help me out with http://core.trac.wordpress.org/ticket/25023#comment:44 then that would be great. I understand you are here to solve bugs but it would be great to get a definitive answer.

Cheers

Chris

comment:50 markoheijnen7 months ago

  • Keywords commit fixed-major removed
  • Milestone changed from 3.6.2 to 3.7
  • Resolution set to fixed
  • Status changed from new to closed

Going to close this ticket now. If you have still have issues that need to be fix in core please create a new ticker otherwise try the support forum.

Note: See TracTickets for help on using tickets.