[wp-trac] [WordPress Trac] #38276: "Is thing public" API
WordPress Trac
noreply at wordpress.org
Tue Oct 11 13:33:45 UTC 2016
#38276: "Is thing public" API
-----------------------------+------------------------------
Reporter: jdgrimes | Owner:
Type: feature request | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Role/Capability | Version: trunk
Severity: normal | Resolution:
Keywords: | Focuses:
-----------------------------+------------------------------
Comment (by jdgrimes):
Replying to [comment:3 PieWP]:
> In regards of combining the {{{WP_Query}}} and the
{{{is_thing_accessable()}}}:
>
> Keeping the Query filter aligned with a custom callback as suggested is
quite hard. You often have to modify the query in strange ways typing
actual custom SQL; which in its turn might cause SQL errors for many
reasons. In addition to that your callback gets modified by the entire
codebase due to filters. So the callback you initially set up might easily
dealign when installing other plugins who (unintentionally) dealign your
{{{is_thing_accessable()}}} check.
Yes, I had considered the possibility that this would require abstracting
out SQL strings, though I'm not sure exactly what that would look like
since I haven't investigated exactly what `WP_Query` is doing here (though
I'm about to do that now).
> //these are the issues I encountered with our client for whom we build a
similar extension//
>
> //p.s. I actually also don't trust other people with extending the Query
/ writing SQL, think of the SQL injections ;P//
True, but filters already exist that pass in the raw query before it is
sent to the database. Probably most devs who would break them horribly
don't know that they exist though. So yeah, that may be ea valid concern.
> == Alternative approach ==
I don't think that approach would be feasible for WordPress core, because
of the issues with making the binary tree stable, especially when plugins
want to add their own rules.
It is also a bit beyond what I was envisioning for this ticket. I wasn't
really planning to completely change what WordPress looks at in order to
determine whether a post is public, just to abstract that logic out so
that it is more accessible. I hope such a fundamental change wouldn't be
necessary, though perhaps it is. But if so, I have a feeling that the core
devs would see it as too much work for too little benefit. As I
investigate this further, I'll get a better idea of whether something like
that would be necessary or not.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/38276#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list