Opened 13 years ago
Last modified 8 weeks ago
#24284 new enhancement
is_multi_author() should query by specific post type and status
| Reported by: | alex-ye | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | General | Version: | |
| Severity: | normal | Keywords: | has-patch needs-refresh needs-unit-tests |
| Cc: | Focuses: |
Description
Current is_multi_author() function only checks by the 'post' post-type and 'publish' post-status..
I think the function should be able to query by custom-post-type and custom-post-status
Attachments (1)
Change History (5)
#1
@
13 years ago
Note that the function is filterable (#18600), so a workaround is currently possible.
#2
@
12 years ago
Good thing I searched first, although this is not what I had in mind ...
... looking through my notes for some feature ideas I happened across the is_multi_author function and thought I might put it to use, at least until I saw it was basically incomplete for a standard WordPress installation. It would be negligent to think WordPress installations could only be filled with posts for multiple authors. I would actually more expect to see multiple authors when the installation is only filled with pages and looking at this function as is, it only queries for posts and ignores the possibility another author may only write pages, or that the site only contains pages and no posts.
Modifying the query should be easy enough to also take into account pages
#4
@
8 weeks ago
Just checked, and this is still happening on trunk. I did a bit of digging, and the query inside is_multi_author() is actually still hardcoded to post_type = 'post' and post_status = 'publish'. So yeah, sites that run mostly on CPTs or pages are just going to incorrectly return false every time.
I also took a look at the original patch, but it's pretty outdated by now. It relies on the old wp_cache_get instead of the current transient caching stuff, plus mapping those arguments directly into raw SQL is a bit too risky anyway.
If we really want to finally get this sorted, I'm thinking we basically have two options here:
- Update the function so it accepts an args array (kind of like the old patch tried to do). That way devs can just pass in whatever specific post types or statuses they need to check.
- Or, just change the default query behavior so it checks against all publicly queryable post types, rather than strictly hardcoding it to just 'post'.
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
First Try :)