hey Matt, turn wordpress.com credits into donation system?

I was looking at the new tipjoy.com startup for twitter and I kind of like their idea. Turn the massive twitter userbase into a massive micro-payment system. They recently got $1 million in funding.

Micro-payment systems often fail but that’s because they never get critical mass. Twitter won’t have that problem. You don’t even need a Twitter account to have a TipJoy account, ie. http://tipjoy.com/u/ck

So I remembered that WordPress.com has had a credit system in place for a long time now to buy premium upgrades. You can even give the credits to someone else I believe as a gift. So why not take that a step further as allow it to be used to donate to anyone for any reason?

One you have enough credits, you could cash out via amazon gift card by email (instant, any amount over $5) or PayPal. PayPal stopped TipJoy from using them to fund accounts (basically it’s fear of competition) but you can still cash out via PayPal, they won’t stop that.

This way WordPress.com can help theme and plugin developers get a few dollars. You could even allow fractions of credits so if someone wants to donate 10 cents, it’s possible. I think wp.com has enough members to also get past that critical mass problem. If a thousand people gave 10 cents to a plugin developer, that starts to add up. It’s certainly more than I get now!

WordPress still uses the nasty SQL_CALC_FOUND_ROWS

We’ve known for over two whole years now that SQL_CALC_FOUND_ROWS did nasty things in bbPress 0.8

It was fixed by mdawaffe (Michael) after discovering how SQL_CALC_FOUND_ROWS caused an overload on the Automattic wordpress.org forum servers due to a MySQL bug.

But to this very day, it’s still used in all WordPress versions, up to and including 2.8.2

(Even more ironic, now that bbPress 1.0 has switched to the backPress core which is based on WordPress, SQL_CALC_FOUND_ROWS is back inside bbPress, though it works around the bug)

SQL_CALC_FOUND_ROWS is typically three times slower than using COUNT() on the same query without LIMIT and ORDER restrictions.

I’ve seen at least one slow-log for MySQL that is FULL of SQL_CALC_FOUND_ROWS queries from a large WordPress installation on a dedicated server that took 11-15 seconds per query (and crashed MySQL, repeatedly).

Here is my quick & dirty patch to the WordPress (and BackPress) core that attempts to change SQL_CALC_FOUND_ROWS to the COUNT() workaround – it’s inside wp-includes/query.php – it’s tested working but not heavily tested so use with caution and let me know if you have improvements?

My changes are against the file from WP 2.5.1 but the file has barely changed since 2.5, even 2.8 is virtually the same so it should be easy to modify other versions.

There is one other use of SQL_CALC_FOUND_ROWS left in WordPress but it’s in the admin section so I am not going to worry about it for now.

More about the MySQL bug due to it’s poor optimization:
http://bugs.mysql.com/bug.php?id=18454 (cache)
http://bugs.mysql.com/bug.php?id=19553 (cache)
http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

Matt in a hat

I can’t decide if I like it or not, it definitely gives him a different style. (I like this one better)
Full article over here (they need to stop using “geek” and “nerd”, it’s so 1990).

Firefox 3.5 tampers with image colors by default

Tonight I was bothered that an image I was looking at in my browser looked washed out and when I loaded it into Irfanview to correct it and study it more closely, somehow it was already darker in Irfanview.

At first I started wondering if I accidentally turned on some kind of automatic option in Irfanview but then I remembered that Firefox 3.0 had image color correction added, but was off by default.

Sure enough Firefox 3.5 has color correction turned ON by default. Even for existing installs that simply upgraded, it apparently turns it back on all by itself.

So go to about:config and find
gfx.color_management.mode
and set it to 0 (zero)
problem solved.

every WordPress install vulnerable to new security hack

Remember the mysterious babloo/blyat attack that hit many blogs including xkcd and is continuing in the wild? Here’s how they did it:

coresecurity.com : WordPress Privileges Unchecked

It’s just mind boggling that the WordPress people:

1. knew about it since June 4th
2. took OVER A FULL MONTH to release a fix (June 4th – July 8th)
3. left ALL previous versions of WordPress flapping in the wind
4. there is no advisory as to how to manually patch existing installs

bbPress 1.0 is possibly affected by this vulnerability now that it uses the WP core
bbPress 0.9 might be immune

added 7/13

I don’t know if this is a reasonable security patch for existing WP installs but the logic seems to make sense to me so far. It might break plugins like subscribe-to-comments or anything else that interacts with regular users through the admin interface.

The problem seems to be this line in admin.php

include(ABSPATH . PLUGINDIR . "/$plugin_page");


Since there is not a natural, singular action before it to hook (it adds the plugin name) the file will have to be edited, and maybe add something like this BEFORE the above line:

if ( ! current_user_can('level_2') ) {
wp_die(__('You are not allowed here.'));
}


This only allows Authors and above to use plugins via the admin menu.

The WP legacy where regular members are allowed into the admin area, but with reduced privileges, has always been very messy. And this is (yet another time) where it’s coming to haunt WP adopters. The good news is at least bbPress learned from the mistake and does it differently.