wp_insert_post() should not contain current_user_can() checks
|Reported by:||alexkingorg||Owned by:|
|Cc:||nacin, rboren, johnbillion@…, steph@…, mikeschinkel@…, ashishsainiashfame@…, nashwan.doaqan@…, pippin@…, sunnyratilal5@…|
wp_insert_post() is a utility function, it should not have a reliance on user capabilities. There are only two places in this function where there is a current_user_can() check - for updating custom taxonomies and for setting post slugs. All other checks (can user publish posts, etc.) are properly handled outside of the utility function.
wp_insert_post() should be safe to use in code that is run without a user context, for example via CRON. With the current code, this is the case *except* for the custom taxonomy feature. This inconsistency can cause a BrilliantDeveloperTM to lose a good deal of time debugging why the same data being passed in is coming back with different results.
For 3.4 (please!), perhaps we can figure out a way to move the checks for user capabilities on taxonomies out of the utility function and into the controller/procedural code. I'm happy to author and submit a patch once an approach has been determined.
For other developers who run into this and need to work around it, either of these 2 options work:
- call wp_set_post_terms() to add your taxonomies after calling wp_insert_post()
- set up a "current user" in your script before calling wp_insert_post()
Change History (43)
- Keywords 3.4-early needs-patch added
- Milestone changed from Awaiting Review to Future Release
- Type changed from defect (bug) to enhancement
- Version changed from 3.3 to 3.0
comment:27 duck_ — 5 months ago
- Keywords 3.7-early added; 3.4-early removed
- Milestone changed from Future Release to 3.7
comment:36 nacin — 3 months ago
- Keywords 3.8-early added; 3.7-early removed
- Milestone changed from 3.7 to Future Release