Opened 16 years ago
Closed 14 years ago
#15036 closed enhancement (fixed)
Add 2nd boolean parameter of wp_error to wp_update_post() to allow passthru to wp_insert_post()
| Reported by: | mikeschinkel | Owned by: | nacin |
|---|---|---|---|
| Priority: | normal | Milestone: | 3.5 |
| Component: | Posts, Post Types | Version: | |
| Severity: | normal | Keywords: | has-patch commit |
| Cc: | Focuses: |
Description (last modified by )
Currently wp_insert_post() accepts wp_error as a second parameter; if true is passed then wp_insert_post() is allowed to return a WP_Error object, if false it can only return a zero (0) on failure.
wp_update_post() currently sets values and then delegates the work of updating to wp_insert_post(). Unfortunately wp_update_post() does not accept a second boolean parameter of wp_error meaning it cannot receive back the same failure information that wp_insert_post() can.
So this request is very simple: accept wp_error as an optional second parameter for wp_update_post() with a default of false and then to pass wp_error on through to wp_insert_post().
Attachments (2)
Change History (12)
#1
@
16 years ago
- Cc added
- Summary Add 2nd boolean of wp_error to wp_update_post() to allow passthru to wp_insert_post() → Add 2nd boolean parameter of wp_error to wp_update_post() to allow passthru to wp_insert_post()
#3
in reply to: ↑ 2
@
16 years ago
Replying to scribu:
The correct way to handle this would be for wp_insert_post() to throw an exception, which of course requires PHP 5.
But since wp_insert_post() doesn't throw an exception, let's address this issue now for v3.1 and then add the exception logic for v3.2 or beyond. One of the principles I've seen westi quote is "Solve the problems that exist today using what we have today and then we'll worry about "the correct" way to solve it later when it's possible to do so." (at least that's how I remember it.)
Why do I need this? I'm currently writing a data import routine that reads a file that a sophisticated user creates by hand and imports the data as per that file. Unfortunately there are things that can cause the data import to fail yet on an update I can't easily report back to the user why it failed like I can on an insert, so I need to be able to get the same error result from wp_update_post() that I can get from wp_insert_post().
#5
follow-up:
↓ 6
@
16 years ago
Yeah, I'll get one soon.
I'm still struggling with how to keep from having to set up a new version of WordPress every time I want to start coding a new patch. I've not gotten a good answer yet:
#6
in reply to: ↑ 5
@
16 years ago
Replying to mikeschinkel:
I'm still struggling with how to keep from having to set up a new version of WordPress every time I want to start coding a new patch.
You don't need to. Just just make one install that is working out of the local SVN copy. Just don't put wp-config.php under version control. Then you can create your patch and revert afterwards. Next time you need to create a patch, you only need to update to HEAD. That's how I'm doing it for years. For outdated patches I even have another install I can switch the revision so to apply old patches, then update to head and then to refresh the patch. But that's more or less for special cases.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
The correct way to handle this would be for wp_insert_post() to throw an exception, which of course requires PHP 5.