Opened 8 years ago
Last modified 5 years ago
#39321 new defect (bug)
Issue with get_permalink when using wp_update_post() and %author% is part of your permalink
Reported by: | mauteri | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | 4.7 |
Component: | Permalinks | Keywords: | dev-feedback has-patch |
Focuses: | Cc: |
Description
This was an odd and very specific issue I found with get_permalink()
. When using wp_update_post()
, I was getting the following: PHP Notice: Trying to get property of non-object etc... I traced it to wp-includes/link-template.php
on line 205:
if ( strpos($permalink, '%author%') !== false) {
$authordata = get_userdata($post->post_author);
$author = $authordata->user_nicename;
}
When the post is a revision
, post_author is equal to 0, so there's no user_nicename
property because get_userdata(0) does not return an object. So here's a possible fix for those situations:
if ( strpos($permalink, '%author%') !== false) {
$authordata = get_userdata($post->post_author);
if ( is_a( $authordata, 'WP_User' ) ) {
$author = $authordata->user_nicename;
}
}
Attachments (1)
Change History (6)
#2
@
8 years ago
Thanks @boonebgorges!
I was programmatically importing and updating data when I noticed this. With this part:
Your change would make this worse, since the structure of the URL would be different for authorless revisions: example.com/authorname/postname vs example.com/postname. Perhaps revisions should always have permalinks of the form ?p=123, as is the case with draft, pending, auto-draft, and future.
Not sure that's actually true, because in this situation $author = $authordata->user_nicename;
never actually worked when post_author=0
, $authordata
is not an object and $authordata->user_nicename;
is just NULL
, so my change just leave it the same but with the added bonus of not throwing a PHP Notice :-)
I like the idea of reverting to non-pretty permalinks for revisions as I think this is the safest course of action and follows suit with draft, pending, auto-draft statuses.
#3
@
8 years ago
Not sure that's actually true, because in this situation $author = $authordata->user_nicename; never actually worked when post_author=0, $authordata is not an object and $authordata->user_nicename; is just NULL, so my change just leave it the same but with the added bonus of not throwing a PHP Notice :-)
Right, I didn't mean "worse than it currently is". I meant that we'd be setting a precedent that, in some cases, the permalinks are different by design :)
Let me think about non-pretty permalinks for revisions. If anyone else has thoughts about potential compatibility issues, please chime in here.
Good catch, @mauteri.
It seems that this specific set of circumstances - a
revision
havingpost_author=0
- only happens when programatically updating posts. When a post is updated through the interface, there's a logged-in user, and that user is assigned to the revision. This dates back to [8480]; see #7317.Aside from programatically-created revisions, it's possible to have posts with
post_author=0
in other ways. So I think there are a couple separate questions here:revision
to look like? More specifically, are there places in core or in plugins where we expect it to be the same as the parent post? At the moment, this is not the case, at least when%author%
is part of the permastruct: Different revisions of the same post could have different authors. Your change would make this worse, since the structure of the URL would be different for authorless revisions:example.com/authorname/postname
vsexample.com/postname
. Perhaps revisions should always have permalinks of the form?p=123
, as is the case withdraft
,pending
,auto-draft
, andfuture
.%author%
is part of the permalink structure?post_author
can be set to 0 in cases other than when the post is arevision
. Simply excluding the%author%
chunk seems like it could introduce weird bugs. Should we have a dummy slug of some sort? Or maybe we should revert to non-pretty permalinks?p=123
when no author is available?As a workaround, try providing a
post_author
when callingwp_update_post()
.