Tag Archives: wordpress stats

WordPress stats oddity

A couple of months ago I removed Google Analytics from this wee little blog, but I still use the less sophisticated WordPress.com stats plugin to follow up on what is being read around here. Loading the stats-page in my Android-browser is far from optimal (it uses Flash to draw the charts and it is a pretty big page), so I was pleased to read that version 1.3 of WordPress for Android features a stats-section. But the reports don’t work, I just get “No stats data found, please try again later”.

Now while playing around with the stats API over the weekend, I noticed some unusual things:

  • “blog_uri=futtta.wordpress.com” works
  • “blog_uri=blog.futtta.be” results in “Error: zero rows returned.”

The API also supports blog_id instead of blog_uri and after some digging for blog_id’s I found that they are listed in (the html source of) the blog dropdown-list on your wordpress.com-dashboard stats page. And there the problem became clear: I had two blog_id ‘s for the same blog_uri (blog.futtta.be) and the first one was defunct:

  • “blog_id=2184847” results in “Error: zero rows returned.”
  • “blog_id=2185033” works just fine

As I can’t remove the entry with the faulty blog_id from the Stats DB and as I can’t change the Android WordPress app to use one of multiple blog_id’s instead of the blog_uri, I can’t fix this little bugger myself, so I contacted WordPress Support. But how did I end up with 2 blog_id’s in the database?

WordPress galore: plugin bugs, android app, json-api & wp 3.0

Some random WordPress-related thingies I’ve been looking into;

  • I bumped into a weird bug in css-js-booster which caused error-messages like
    <!-- Booster had a problems finding wp-content/
    plugins/css-js-booster/../../../../../../
    3f540bbd99f8ebecb73880a685db76ae_plain.css -->
    

    to appear in the html-source, although all CSS seemed to be processed. The problem was caused by PHP’s safe_mode and got fixed in 0.2.2, thanks der Schepp!

  • A few days ago my entire WordPress-blog returned empty pages, the admin-section included. Turns out that this “white screen of death” is a known issue with the WP super-cache plugin when combined with PHP APC (2 of the main components of my “Speed up WordPress“-post). As this only occurs rarely, I’ll stick to restarting Apache for now (I don’t want to switch back to eAccelerator) but I hope the APC and WP Super-Cache teams will look into this further.
  • After ditching Google Analytics, I looked into how WordPress stats are collected. Indeed, the script is sourced at the end of the HTML, thus slowing down the rendering of the page.  Let’s hope someone at Auttomatic reads Steve Soulders’ very interesting blogposts on “Performance of 3rd Party Content” and decides it indeed is time follow Google Analytics’ example and switch to asynchronous loading of the WordPress stats Javascript.
  • I installed the WordPress Android application and played around with it a bit. I don’t think I’ll be posting with it any time soon; writing on a small touch-device is a hassle, there’s no such thing as a rich HTML editor and  updating pages and especially posts or comments is very slow (because of the incredible overhead and complexity of the xml-rpc API?). Still, nice to see the WordPress-icon on my HTC Hero ;-)
  • Thinking about that clumsy WordPress xml-rpc API (which I experimented with approx. 1 year ago), I started looking for a plugin that provides a rest/json api. JSON API does just that and it has great potential, but it might not be suited for public-facing WordPress installations just yet, as it allows unauthenticated users to create new posts. So you might want to wait for authentication to be added to JSON API before installing it?
  • And I just read that the first beta of WordPress 3.0 was released; wordpress and wordpress.MU get merged, menu management and a new theme are but a few of the new features. Wouldn’t is be great if functionality/ ideas from wp-super-cache, css-js-booster and json-api would be added as well?

Loemp zijn doet zeer

Gisteren weer bijzonder loemp geweest. Eerst de wordpress.com-stats voor mijn blog kapot gemaakt; mijn WordPress-api-key is niet meer geldig voor deze blog. ‘t Is nu wachten op hulp van de wordpress.com support om opnieuw domweg naar die onbenullige feitjes te kunnen staren.

Eéntje is geentje en daarom ‘s avonds in het ingeslapen Eksaarde-dorp ook nog eens gevallen met de vouwfiets; te snel willen rijden, recht op de pedalen, voet van trapper geschoten, evenwicht kwijt aan pakweg 30 per uur en op die manier een spoor van geraspt vel (van mijn linkerarm) op het asfalt achtergelaten. Loemp zijn doet zeer, zeker als er (nog steeds vochtige) schaafwonden aan te pas komen.

Uw medelijden wordt bijzonder op prijs gesteld!