New Post Using Multiple Custom Field creates unpublished posts and drafts

[elusivelight]

Using a new installation (2.5) with no plugins activated (system: Mac OS X 10.4 and Firefox 2), creating a new post with 6 custom fields, and hitting Publish caused 4 drafts and two unpublished posts to be created, each one showing one custom field. The original post only shows the last custom field.

 Discussion and steps to reproduce from the support forums.

i have the same problem on 2.5 stable version

hi this ist the video off that bug  http://www.vimeo.com/842369  http://www.vimeo.com/842723

any idea how to solved ?

likely related bug: I've occasionally had duplicate posts that were created when I made myself a coffee after starting to write a post. the bloody mess got autosaved, and when I clicked publish I ended up with a draft with the same title.

D.

I have this problem all the DAYS!!!!

For weeks I m waiting a solution.

Please! Fix it!

Reporting similar results. My template makes use of Custom Fields as well. Most pages require 2 Custom Field entries.

Anytime I try to enter two or more, it only saves the last one I entered. But if I try to enter one, then save, then enter the next one, the script hangs, and the page doesn't seem to get saved.

In addition to this, I'm also getting the "random drafts" being generated. Very confusing at first -- because pages that were published are also showing up in drafts, and I wasn't sure whether it would be safe to delete them. (Thankfully, the ones in "drafts" really ARE drafts, and deleting them will not affect your published posts.)

This has only happened since 2.5, and it still happens in 2.5.1.

Just saw the "workaround" posted at  http://wordpress.org/support/topic/163769 (SAVE before you begin adding custom fields) but saving seems to be slow. I actually kinda think I like the pre 2.5 wp-admin better than the current one. The new one definitely looks nicer, but seems slower.

This seems to happen when custom fields are added before the first save of the page/post. To temporarily avoid this behavior, you can save your page/post (not publish) before adding the first custom field.

This seems to happen when the user has javascript disabled OR for some reason the scripts for AJAX have not initialized for the page yet. The second HAS happened to me several times with this page. I don't think it's a slow connection problem because when it happened to me it was with a Wordpress installation in my intranet. You can tell because a full POST is performed, instead of an AJAX method.

This is easily reproductible if you disable Javascript and add metadata is your first action.

I had to make a double patch for this:

1) Disable the check at wp_insert_post() for content. Since metadata can be added without title/content/excerpt, this function should allow for it. OTHER CHECKS NEEDED, THOUGH!

2) Consider the fact that we don't have a good referrer in redirect_post().

(See attached patch). This solved the problem for me (at least testing with Firefox and JS disabled), but the effects should be evaluated by another developer more familiar with WP code.

Same issue on WP 2.5.1, Mac OS X 10.5.2, Safari 3.1.1, PHP 5.2.3-1ubuntu6.3, Apache 2.2.4.

My comments in  this post may be relevant to this bug, specifically the bit about renaming the default category to something other than Uncategorized. Then again I could be wrong.

It would help if people test the above patch. I did my 'laboratory' tests and it seems to work just fine, but real world tests would be great. I hope people start posting here their results.

I would just like to point out that one custom field is enough if combined with the addition of images to the blog post.

The patches appear to be working for me -- thanks!

(In [8177]) Respect post_ID update when doing multiple add meta AJAX requests. Props mdawaffe. fixes #7170 see #6457

That fixes part of the problem.

(In [8178]) Respect post_ID update when doing multiple add meta AJAX requests. Props mdawaffe. fixes #7170 see #6457 for 2.5

Replying to ericr23:

The patches appear to be working for me -- thanks!

Only partly, it turns out. One unwanted draft still remains after publishing, which is better than several but not quite there. Note: I've been deliberately adding the custom field first and letting the draft autosave, avoiding the workaround of saving first.

The database gets cluttered up by drafts and custom fields pointing to them - instead to the final, published article.

Cleaning this mess up will be quite a risky task for the non-sql-educated. Maybe a "delete all drafts" script will be needed.

Replying to arminbw:

Maybe a "delete all drafts" script will be needed.

Have to correct myself. Using the admin backend deleting the drafts will also delete the associated custom fields.

Milestone 2.5.2 deleted

A FYI (Wordpress 2.5.1 - Firefox 2)

Create a New post.

Add a custom field (pre-existing) to the post. Draft gets saved. Postmeta entry created with post_id 68

Add a custom field (pre-existing) to the post. Draft gets saved. Postmeta entry created with post_id 69

Add a custom field (pre-existing) to the post. Draft gets saved. Postmeta entry created with post_id 70

Save post.

Post is now id 70, but of course lost custom fields attributed to draft id 68, 69.

As previously mentioned. Workaround is to save then add custom fields.

nfong, try 2.6. That part of the bug should be fixed.

Verified fixed in 2.6.

Thanks!

Seems fixed in 2.6 to me too. I'm guessing this should be closed.