If you init the fiters at each iteration, it should work… although the content type is post, not posts.
Hello Camu, thanks for the response!
In my previous post I put what exactly what I was doing, besides the post part, I’m actually using a custom post type so I have cpt:type instead or post. It’s not working as of now, it only seems to acknowledge 1.
The loop part above is:
if ( $mr_query->have_posts() ) : while ( $mr_query->have_posts() ) : $mr_query->the_post();
You’re not using the Custom DB add-on, are you?
I assume no since I am not sure what you’re referring too 😉
Another thing: when a date range is not specified, SlimStat defaults to the current month. So maybe you don’t have any visits for October?
I just tested the following call on our test site, and I got what I was expecting to get:
wp_slimstat_db::init('content_type equals post|resource contains addon|year equals 2013');
By not specifying a day or a month, you tell SlimStat that you want the count for the entire year. Please note that date filters only accept ‘equals’ as the operator.
Thanks for the continued help camu! I want to get the total number, nothing specific in terms of the date. So total unique views for that particular page. With that said, I don’t think I need to specify a date at that point, right?
Well, if you don’t, SlimStat will default to the current month. You may want to do something like
wp_slimstat_db::init('content_type equals post|strtotime equals today|interval equals -1000');
The negative ‘interval’ allows you to go in the past, by saying: count all the pageviews (or unique views, in your case) from 1000 days ago to today. That should do it.
That isn’t working either. This is what I have:
wp_slimstat_db::init(‘content_type equals cpt:vines|resource contains ‘.$post->post_name.’|strtotime equals today|interval equals -1000’);
I even tried this since I thought maybe the post_name was too long for the API: wp_slimstat_db::init(‘content_type equals cpt:vines|resource contains ‘.substr($post->post_name, 0, 15).’|strtotime equals today|interval equals -1000’);
The count works correctly for the 1st item but still displays 0 for the remainder.
Really strange, can you do a print_r of wp_slimstat_db::$filters to see if the values change at each iteration?
We might be on to something now…
The values are changing, however I think maybe the error resides in the contains portion. The post_name is obviously getting cut off, looks like it’s limited to 15 characters: “avicii-levels-r”
Producing SQL: [sql_where] => AND tci.content_type = ‘cpt:vines’ AND t1.resource LIKE ‘%whenever-my-asi%’ AND tci.content_type = ‘cpt:vines’ AND t1.resource LIKE ‘%avicii-levels-r%’
The full post_name is: avicii–levels-requested-by-many
Do you think this might be the cause?
I think you just found a bug in the API 😉 The SQL doesn’t look right. I’m taking a look at the code. I’ll fix it in version 3.4.1.
Perfect! haha – At least I know I’m not going insane… spent a ton of hours trying to figure it out before I hoped on here to bother you. I wasn’t aware of that command to print out that stuff for debugging, really helped!
A temporary workaround is to manually reset the filters at each iteration by doing
wp_slimstat_db::$filters = array();
right before the init. See if this works.
That worked! Another command you should add to the documentation! I was looking all over for something like that! (I could have missed it too)
Really appreciate the time and help camu!
A vote for SlimStat would be a nice way to say thank you!
