Make WordPress Core

Opened 18 years ago

Closed 18 years ago

Last modified 22 months ago

#5257 closed defect (bug) (duplicate)

Pages Must Be Saved Before Adding Custom Fields

Reported by: hughbiquitous's profile hughbiquitous Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.3
Component: Administration Keywords: has-patch has-unit-tests
Focuses: Cc:

Description

If you add a custom field to an unsaved page, publishing the page turns it into a draft post and data is lost.

Environment:

Repro Steps:

  1. Create a new page.
  2. Title it "Custom Field Bug".
  3. Enter some text into the Page Content area.
  4. Create a custom field (I used key="file", value="foo bar baz"). Click "Add Custom Field".
  5. Click Publish.

Expected Result: Page should publish.

Observed Result:

  • After you click publish, it navigates to "Manage->Pages" menu but the page is not there.
  • Click on "Manage->Posts" and you will see a new, unpublished post (not page) that
    • (A) does have the custom field, and
    • (B) does not have the Post Content entered in step 3, and
    • (C) does not have the title "Custom Field Bug" from step 2 -- instead, the title is "Draft created on (date & time)".

Note: I could not reproduce this for a post. It only happens for pages.

Workaround:

  1. Create a new page.
  2. Title it "Custom Field Bug Workaround".
  3. Click "Save and continue editing".
  4. Create a custom field (I used key="file", value="foo bar baz"). Click "Add Custom Field".
  5. Click Publish.

This gives the expected result.

Change History (9)

#1 @markjaquith
18 years ago

  • Milestone 2.3.1 deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #3700

This ticket was mentioned in PR #5261 on WordPress/wordpress-develop by @Bernhard Reiter.


22 months ago
#2

  • Keywords has-patch has-unit-tests added

Supplementary material for #5257 :)

Trac ticket: N/A

@Bernhard Reiter commented on PR #5261:


22 months ago
#3

@gziolo I'm hoping that this PR will become the final piece to implement Block Hooks. It should be pretty much feature-complete if I didn't miss anything 🙂

@Bernhard Reiter commented on PR #5261:


22 months ago
#4

Weird, unit tests are currently failing:

Invalid argument supplied for foreach()

/var/www/src/wp-includes/blocks.php:754

That's this line: https://github.com/WordPress/wordpress-develop/blob/aa033cba5cd3424a0445c6cd95e34307986880a1/src/wp-includes/blocks.php#L754

I wonder if/why the block_hooks field isn't available at all (rather than defaulting to the empty array)?

@Bernhard Reiter commented on PR #5261:


22 months ago
#5

Workaround in bd1c57bb20. Let's see if that works.

@Bernhard Reiter commented on PR #5261:


22 months ago
#6

Seeing the same test failure I had earlier:

Invalid argument supplied for foreach()

/var/www/src/wp-includes/blocks.php:757

Maybe I need to add an is_array check alongside property_exists.

@Bernhard Reiter commented on PR #5261:


22 months ago
#7

Seeing the same test failure I had earlier:

Invalid argument supplied for foreach()

/var/www/src/wp-includes/blocks.php:757

Maybe I need to add an is_array check alongside property_exists.

https://github.com/WordPress/wordpress-develop/pull/5261/commits/22c75d9e338b5ab021e5f481c0e389136b05eb70

@Bernhard Reiter commented on PR #5261:


22 months ago
#8

Thanks a lot for the test coverage @gziolo, I quite like your approach! 😄

Note: See TracTickets for help on using tickets.