[wp-hackers] Making WP more secure the evolutionary way

[Florian Thiel]

On Tue, Jan 27, 2009 at 8:14 AM, Otto <otto at ottodestruct.com> wrote:
> On Mon, Jan 26, 2009 at 8:45 PM, Mike Schinkel
> <mikeschinkel at newclarity.net> wrote:
>> P.S. If you advocates persist in moving in this direction, please do us a favor and at least write an query client that can understand it's syntax and allow a user to query MySQL interactively directly from your code.
>
> That's the beauty of overloading. Remember that Zend DB stuff I was
> talking about before? Using that, you can just as easily query with
> SQL directly. $db->fetchAll('select whatever') works just as well
> there too. The API functionality is meant to add to the base, not take
> away from it. Sometimes it's better to build a query dynamically, in
> parts. Sometimes, it's not.

I think Zend or CakePHP are a bit out of reach for WordPress right now
because it would need some fundamental changes to the code. Zend and
CakePHP heavily use objects and a data model, which is not explicit in
WordPress.

I think there are two ways to go about it which don't straitjacket the
developers and provide a reasonable set of advantages:

1) just package the raw SQL queries in function calls like this:

$wp_db->select($columns,$conditions)
e.g.
$wp_db->select(array('column1','column2'),array('id' => $someid))

This is already being used for insert and update. Moving all the
INSERTs, UPDATEs and the simple cases of SELECT, DELETE etc. to the
abstraction layer already rids us of 200 uses of raw SQL. And it's
really not much work. (these are the 'method_exists' and
'trivial_implementation' cases). For the rest, we could see where we
would go from there. If it works out well for the simple cases, we
might also consider the ones that actually need some code to be
written...

Matt, Jacob is this something you would approve?

I'll send proof-of-concept patches for this types later today...

2) Create "intentional" abstractions (This is an idea that goes much
further and moves SQL out of the picture completely; I see that there
are people that won't like this approach; it's just an idea).

The basic point of these abstractions is that the caller just says
what he wants and does not really care how the callee gets the job
done.

$wp_db->getPosts()
$wp_db->getCommentsForPost($id)
$wp_db->getPostsByTag($tag)

The problem with this approach is that there could be too many
functions needed because you would need one for every particular type
of query. You could unify some query types using keyword arguments
(like adding 'limit' => 10) but that could hurt readability.

Florian