Make WordPress Core

Opened 14 years ago

Closed 13 years ago

Last modified 7 years ago

#6457 closed defect (bug) (fixed)

New Post Using Multiple Custom Field creates unpublished posts and drafts

Reported by: elusivelight Owned by: ryan
Milestone: 2.6 Priority: highest omg bbq
Severity: critical Version: 2.5.1
Component: Administration Keywords: custom fields has-patch needs-testing
Focuses: Cc:


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.

Attachments (1)

6457.diff (1.4 KB) - added by guillep2k 13 years ago.

Download all attachments as: .zip

Change History (27)

#2 @devilsoulblack
14 years ago

  • Milestone changed from 2.7 to 2.5.1
  • Priority changed from normal to highest omg bbq
  • Severity changed from normal to critical
  • Version set to 2.5

i have the same problem on 2.5 stable version

#3 @devilsoulblack
14 years ago

hi this ist the video off that bug

any idea how to solved ?

#4 @Denis-de-Bernardy
14 years ago

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.


#5 @zogar
14 years ago

I have this problem all the DAYS!!!!

For weeks I m waiting a solution.

Please! Fix it!

#6 @pnaw10
14 years ago

  • Cc pnaw10@… added
  • Keywords custom fields added
  • Version changed from 2.5 to 2.5.1

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.

#7 @guillep2k
13 years ago

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.

13 years ago

#8 @guillep2k
13 years ago

  • Cc guillep2k added
  • Keywords has-patch needs-testing added

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.

#9 @microtd
13 years ago

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.

#10 @jayabb
13 years ago

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.

#11 @guillep2k
13 years ago

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.

#12 @voxpelli
13 years ago

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

#13 follow-up: @ericr23
13 years ago

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

#14 @ryan
13 years ago

  • Owner changed from anonymous to ryan

#15 @ryan
13 years ago

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

#16 @ryan
13 years ago

That fixes part of the problem.

#17 @ryan
13 years ago

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

#18 in reply to: ↑ 13 @ericr23
13 years ago

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.

#19 follow-up: @arminbw
13 years ago

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.

#20 in reply to: ↑ 19 @arminbw
13 years ago

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.

#21 @ryan
13 years ago

  • Milestone changed from 2.5.2 to 2.9

Milestone 2.5.2 deleted

#22 @nfong
13 years ago

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.

#23 @ryan
13 years ago

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

#24 @nfong
13 years ago

Verified fixed in 2.6.


#25 @AaronCampbell
13 years ago

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

#26 @ryan
13 years ago

  • Milestone changed from 2.9 to 2.6
  • Resolution set to fixed
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.