Transitions and page overlays are not working on one of my pages, but they are working on others. I get the message "Either the action had no pageviews during the period or it is invalid."
There is no real difference between the pages, they are all articles in a Tumblr blog.
The broken page has over 700 views, while the working pages only have around 50 views.
The only noticeable difference I can see between them is the title: the broken page contains parentheses and the working ones do not. Besides that, the broken page is newer, while the ones that work have been in the system for much longer.
Sorry I can't provide more information. Let me know if there's a way I can run some tests or queries against the DB to help narrow this down.
Attachment: Screenshot of message
Screen Shot 2014-01-30 at 10.03.21 AM.png
Thanks for the report. What was the exact page names of the not working page?
Consolidating milestones FTW
The broken page is titled:
OverZealous Creations: The Blog - Why you shouldn't create a gulp plugin (or, how to stop worrying and learn to love existing node packages)
I now am wondering if it's the apostrophe. However, it doesn't matter how I try to open the transitions I can come at the link from Pages or from Page titles and I get the no pageviews message either way.
I've tried looking for a log or something, but I'm not seeing anything in the Apache logs or via Firebug. The Piwik system check is all checkmarks from top-to-bottom. Is there some sort of debug SQL function that can be enabled to see the queries being run?
I've also (just for the heck of it) restarted both MySQL and Apache.
I'm experiencing this issue too -- many pages on my site have transition data, but lots of them don't, including the home page -- http://www.freelock.com. The home page does have an exclamation point in the title, but other pages that are broken have no unusual punctuation -- http://www.freelock.com/freelock-blog
... meanwhile, a lot of other pages show transitions just fine.
I think this used to work before Piwik 2.0 -- this is the first time I've actually looked since then.
Also, the same pages that do not load transitions, do not show link info in the overlay.
@matt I see this bug (or a similar bug) here: http://demo.piwik.org/index.php?module=CoreHome&action=index&idSite=1&period=day&date=yesterday#module=Actions&action=indexPageUrls&idSite=1&period=day&date=2014-03-07&popover=RowAction$3ATransitions$3Aurl$3Ahttp$3A$2F$2Fdemo.piwik.org$2Findex.php$3Fmodule$3DCoreHome$26action$3Dindex$26idSite$3D7$26period$3Dday$26date$3D2014-03-06$23module$3DDashboard$26action$3DembeddedIndex$26idSite$3D7$26period$3Dday$26date$3D2014-03-06$26idDashboard$3D1
It is caused by sanitization in TableLogAction::getIdActionFromSegment. Action names are stored unsanitized, but getIdActionFromSegment will search for the sanitized version. So any action w/ an '&' or similar will result in No Data.
Not sure what the appropriate fix is, but I've reproduced in UI tests (and it can be reproduced in integration tests).
@capedfuzz Thanks for doing research into this! Hopefully this can lead to a fix.
Nice find! Increasing priority
I figured out the actual cause of this bug for me!
Short answer: there are (were) duplicate rows in the
log_action table with the same URL, hash, etc.
I have no idea how these duplications occurred, but due to using
\Piwik\Db::fetchOne, which actually returns an error if there are duplicate rows, the Transitions and Page Overlay plugins were unable to find the ID of the action.
The only solution is to determine which id is "correct" (mine was the second ID, as the first only had one visit associated with it) and delete the other.
I don't know if this should be something that is addressed by Piwik or what. Again, not sure how it happened in the first place, although it might be an issue with simultaneous visits causing database corruption. A proper UNIQUE constraint across the
hash field would prevent this from happening in the future, but the broken tables will need to be cleaned up first.
I also have no idea what sort of problems are going to occur by simply deleting the duplicate actions.
Haven't had any time to look at the code, but I can confirm that my database has lots of duplicate rows in log_action, aside from the idaction column.
My log_action table has 146621 rows, with 141743 unique hashes, and 1111 individual hashes with multiple rows.
If I understand correctly there are two separate issues that may cause the "Transitions no data" bug
log_actiontable. This bug is covered in this other issue: #6436
you can't just delete the 'duplicate' entries, you have to merge them:
select idaction,name,count(*) from piwik_log_action as action, piwik_log_link_visit_action as linker where linker.idaction_url_ref=action.idaction group by action.idaction order by name;
for each of the names which have multiple idactions:
(in my case i had upwards of 10 ids for the same url)
say i have multiple idactions: 63,90,134,213,180
update piwik_log_link_visit_action set idaction_url_ref=63 where idaction_url_ref in (90,134,213,180);
update piwik_log_link_visit_action set idaction_url=63 where idaction_url in (90,134,213,180);
delete from piwik_log_action where idaction in (90,134,213,180);
I had a look re this issue but don't know how to fix it. As it was mentioned earlier this seems to be the problem for actions containing eg a
$valueToMatch is eg
?r=4&545=45 afterwards it is
?r=4&545=45. Not sure what the best way is to fix it as there seems something to be wrong in general.
@tsteur I took a loook at it and pushed a fix, which looks like it works on demo2 - maybe you can confirm?
Ok I mark this as closed for now, but please re-open the issue or comment in case any issue re-occurs. Upgrade to 2.9.0-b9 which contains the hopefully complete fix! http://piwik.org/faq/how-to-update/faq_159/
Would this fix affect existing data, or only new data going forward?
I installed 2.9.0-b9, but I'm still getting "There's no data..." on the same set of pages that previously had the issue. Is there a data cleanup step? Some of the busiest pages on my site are affected...