Just ahead of WordPress 3.1, we released WordPress.com Stats 1.8. The new Stats plugin includes some small fixes that will make it easier for us keep the plugin’s reports in sync with the reports seen on WordPress.com. The plugin’s reports are a few versions behind so look for rapid improvement in the coming weeks. But what’s most exciting about Stats 1.8 is how it works with a new feature in WordPress 3.1: the admin bar.
Stats 1.8 adds a tiny bar chart (called a “sparkline”) to the admin bar. To make this chart more interesting, and not just a copy of what you can already see in your stats report page, we zoomed in on the time axis. Rather than show one data point per day we show each of the last 48 hours. Following your blog’s time zone setting, lighter and darker bars represent daylight and nighttime hours.
Design credit goes to Joen and MT. The sparkline design seems simple and obvious now, but it took a lot of tries to get it that way. It wouldn’t have happened without their contributions.
Of course, we intend to bring the new sparkline to the WordPress.com admin bar as soon as possible. Remember how we said the plugin’s stats reports are a few versions behind the WordPress.com reports? With the admin bar it’s the reverse. Self-hosted bloggers are the first to get this upgrade. Everyone on WordPress.com will have it soon.
Anyone hosting their own blog and running the WordPress.com Stats plugin should update the plugin to version 1.1.1 immediately or apply the patch below. A critical SQL injection vulnerability was found and fixed. The bug could allow an attacker to steal administrative credentials. (WordPress.com bloggers are not affected.)
Most users will want to download the latest version and simply copy the new files directly over the old ones. Subversion users may do `svn up`. Advanced users may apply the patch manually.
Thanks to Alex Concha who found and reported the bug to me. He also provided the fix.
I heard it from a number of users that they couldn’t see their stats due to a “403” message. I’ve replaced that message with something more helpful. Victims of the 403 should try again now.
While reading the many blog posts about Automattic Stats, I found the most common complaints to be about the way we serve the stats reports on your WordPress.com dashboard rather than your self-hosted dashboard. I’m still pretty sure we made the right decision for the following reasons:
It’s central. You can check the stats for all of your blogs in one place.
It’s easy on your host. Your server doesn’t have to ask our server for raw data each time you browse the reports.
It’s faster for you. Our servers can talk directly to the stats database and display the results unaffected by the loads and limits of your server. Sometimes handling all that data requires more system resources than shared hosting setups allow.
It’s future-proof. Whenever we update the reporting interface, add features, improve graphs, fix bugs, etc., you don’t have to upgrade your plugin.
It’s ready now. We already spent a lot of time developing one reporting interface. It wouldn’t make sense to make you wait while we develop another one.
It’s not always going to be this way. We’re planning to expose API’s to let plugin developers query the stats database. This will open the field for anyone to create and share new reporting tools, even ones that live in your own dashboard.
I think that’s enough justification. A few users have suggested ways to make the reporting more convenient. The most common suggestion, and the easiest to implement, was to add a link back to the blog’s own dashboard. You’ll find this new link near the top of every report page.
Some folks have asked whether Automattic Stats can be used with WordPress versions prior to 2.1 or WordPress MU. Broad compatibility would be nice but it is not my goal.
Use of the Automattic Stats plugin with WordPress 2.0.x is untested and strongly discouraged. I have not tested the plugin against any versions in the 2.0 branch because the plugin relies on some things that were not implemented in 2.0. Off the top of my head, $wp_the_query is required and admin_notices is recommended.
Use of the Automattic Stats plugin with WordPress MU is untested and strongly discouraged. Of course, nothing prevents hard-core hackers from testing and updating the plugin for use with MU. I just don’t support it.
Either of these causes could see a champion appear, in which case I may be interested in seeing the results of your research. I will not answer questions about the source code. If you can’t read it, you are not the champion.
Now let’s give this stats thing a few more days and then we’ll see where it stands.