The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.
Here’s an excerpt:
The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 46,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 17 sold-out performances for that many people to see it.
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.
At first we thought it was a good idea to use iframes to display reports in the Stats plugin. We’ve seen since then a lot of problems with browsers and cookies. To help resolve these issues, and in anticipation of future features, I am updating the plugin and the WordPress.com stats reporting system to remove the iframes. I just posted 1.5 beta 1. If you host your own WordPress 2.7+ blog and you use the Stats plugin, why not contribute to its development by installing this testing version? Anyone can download the beta but I don’t recommend it unless you are able to cope with potentially unstable software.
What are the risks of using this beta?
You won’t lose any stats. If something goes horribly wrong it’s probably a bad download; just reinstall the latest version of Stats.
How does it work? The plugin connects to WordPress.com to get the stats reports when you request them. It uses the API key to authenticate.
Aside from fixing cookie problems, how is this better?
Now it’s possible for anyone who can publish posts on your blog to see blog stats. They don’t have to be logged into a WordPress.com account. They only need the publish_posts capability (Author role) to view stats reports.
Where did the dropdown blog switcher go? Because the plugin uses a single API key to authenticate, the service doesn’t know whether the visitor is the owner of that key or some other user. So it doesn’t make much sense to show the list of blogs belonging to the API key owner. You can still use the switcher if you view your stats on any WordPress.com dashboard.
Where did the Stats Access panel go? This is also related to single API key authentication. Maybe in future we will bring administrative access back to the plugin. But until then, we have left the Stats Access panel intact on WordPress.com dashboards. You might want to bookmark dashboard.wordpress.com if you need these features on a regular basis.
Will this be a required upgrade?
You mean will older version of stats be broken? Not by 1.5. Later versions may break compatibility but for now you can keep using earlier versions of Stats if you like.
What if I install this and still see iframes? This happens because your server is unable to connect to WordPress.com. I set it up to use SSL (https) in the hopes that most hosts support this. If yours does not work, I’d like to hear from you and do some testing on your host.
WordPress 2.5 with its new uploader results in a lot more post attachments. Until now, the Stats plugin didn’t keep track of which attachments were viewed. Stats 1.2.1 contains a minor change that lets us show you which of your attachments are most popular.
Remember, attachment views are only counted if you link to the attachment’s Post URL when inserting from the uploader.
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.
We updated the WordPress.com Stats plugin just a little bit today. Now, instead of redirecting you to dashboard.wordpress.com, the stats are loaded in an iframe on your own blog’s dashboard. You still have to be logged into wordpress.com to see your stats. If your plugin version is 1.0, you should upgrade to 1.1 to see the changes. Just replace the old stats.php file with the new one.
The good news is that you don’t have to leave your site, we still take care of your data just like before and we can still update the interface with new features, such as the new clickable chart points, without pushing an updated plugin.
The bad news is that the iframe will often have a vertical scroll bar or empty space at the bottom. We would resize the iframe dynamically but browsers won’t allow it because the pages are not served from the same domains. Browser security policies prevent that kind of cross-site scripting.
This change was prompted by countless requests to do away with the redirect. Thanks for that. 🙂
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.