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

Florian Thiel flo.thiel+wphackers at googlemail.com
Tue Jan 27 09:57:43 GMT 2009

On Mon, Jan 26, 2009 at 10:41 PM, Jacob Santos <wordpress at santosj.name> wrote:
> This is *exactly* what I don't want to see WordPress use. The
> implementations that I've seen haven't been optimized that well. It is the
> same sort of setup that CodeIgniter uses (whom coincidently calls their
> model Active Record, are they wrong with the pattern name? Most likely) and
> I despise it with a passion. The problem is that it will never be as fast
> as:
> $db->query(SQL_HERE);
> Most of the code in CodeIgniter makes use of arrays, checks and iteration
> that inherently adds to the implementation and slows the process down.

Since this comes up again and again: Does anyone have benchmarking
results for WordPress and can tell me where most of the time is spent
when generating a page? Performance is not that straightforward, and
it is really hard to predict how some change impacts the execution
speed unless you really measure it. Also, most DB API have their own
prepare() method that precompiles the SQL statement. When you reuse a
statement (with different parameters like WHERE conditions and such)
it actually becomes FASTER.


> Furthermore, I know SQL and I know how to protect against being raped. Why
> do I need something that holds my hand? In the off-chance that there is
> something I didn't forsee occurring that leads me to being taken advantage
> of against my will? Doubtful, who is to say there wouldn't be a bug in this
> sort of implementation? Most new APIs have bugs and we'll be throwing
> ourselves on an API that would have be seriously tested both for
> functionality and security.
> Jacob Santos
> Otto wrote:
>> I used the Zend Table stuff for a while, and I liked it to a certain
>> extent. It looks like this:
>> $selectstmt = $table->select()->where('whatever = ?',
>> $whatever)->order('something ASC');
>> $row = $table->fetchRow($selectstmt);
>> This would get a row as an object (one predefined by a class for that
>> row type), or as a generic row if you didn't define it as something
>> special. You could also get multiple rows like so:
>> $rows = $table->fetchAll($selectstmt);
>> This gives you a "RowSet", which was just a fancied up array of Rows.
>> It's really quite clever, and the classes allow for specifying the
>> dependent tables as well, which could then be automatically retrieved
>> based on the parent tables (internally it uses joins to do this).
>> Clever.
>> -Otto
>> _______________________________________________
>> wp-hackers mailing list
>> wp-hackers at lists.automattic.com
>> http://lists.automattic.com/mailman/listinfo/wp-hackers
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers

More information about the wp-hackers mailing list