-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Show the JS tracking code instead of the dashboard while no visit is tracked #7365
Conversation
$count = Db::fetchOne($sql, array($this->idSite)); | ||
|
||
return $count == 0; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This function shouldn't be in the controller, could someone please tell me what is the best place for it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this maybe all (Controller etc) be in the SitesManager plugin that listens to the Controller.CoreHome.index
event? Not sure if that works. There could be also an event listener in the SitesManager to Request.getRenamedModuleAndAction
and rename module
and action
if needed (if it is CoreHome.index
and has no tracking request). In theory CoreHome does not know anything about tracking code etc.
This SQL could go into a separate class eg in Piwik\Tracker\Model
but could be also a class in the SitesManager plugin etc.
Maybe also apply a Limit 1
to the query as we only want to know whether there was at least one tracking request.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! I've done the changes and moved everything to SitesManager and used the Request.dispatch
event as it seems to be exactly made for that. Controller.CoreHome.index
didn't allow to change the controller.
Maybe also apply a Limit 1 to the query as we only want to know whether there was at least one tracking request.
the limit would apply to the rows returned, given COUNT(*) returns one row it has no effect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it should be possible to do something like SELECT idvisit FROM piwik_log_visit WHERE idsite=? limit 1
then it should have an effect.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, there is an index on idsite, visit_last_action_time
and idsite, idvisitor
. So it would be even better to use for example SELECT idvisitor FROM piwik_log_visit WHERE idsite=? limit 1
since it then can read from the index which would be even faster.
Edit: Just noticed there is a PRIMARY index on idvisit so doesn't matter...
quick note regarding the look and feel: can you make the H2 look like the admin H2: and H3 look like admin H3: Btw maybe somehow it's related to inconsistency in https://github.com/PiwikPRO/plugin-CloudAdmin/issues/44 (not sure if that's correct though) |
Done, screenshot updated in the description. |
Nice improvement... here is feedback
|
Changes implemented. I've added a test too (3 hours for a simple UI test :'( ) For the record master is broken so the pr is failing |
var generalParams = 'idSite=4&period=day&date=2010-01-03'; | ||
|
||
before(function () { | ||
testEnvironment.pluginsToLoad = ['SitesManager']; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@diosmosis is it expected we have to manually load the actual plugin the test is written in? could we improve this to automatically load the plugin being tested (here the UI test is in the SitesManager plugin)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, tests should be run as ./console tests:run-ui --plugin=SitesManager
for plugins. howeve, SitesManager is a core plugin, it should always be loaded.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah OK I will remove that line then, I just used the UI tests generator and that was added automatically.
On the screenshot it seems the H3 looks blue rather than black in the admin? |
Nice, the UI test is very useful. Wow, 3 hours is a long time. Was the painful part to have to manually load the plugin? This seems like it should not be needed, I've asked Benaka in the comment. Otherwise, do you have suggestions to make this better for other devs in the future? |
The painful part was running the tests at all. I've messed up several things on my own machine by setting up piwik so I don't want to try to run the ui test locally. The vagrant setup isn't good because it checks out an entire new copy of Piwik, so I had to resort using the AWS tests runner but had to fix it and improve it first. And then a big problem was understanding how fixtures work and how I can add new fixtures/site. I've given up on that and found the siteId 4 was empty, I hope it will stay that way. The developer documentation on all that is not helpful. Regarding fixing the titles, I don't really want to refactor the CSS in that PR, I'm already working on that separately. I can fix the blue color. |
FYI if you want to ensure the site is always empty, you can do |
actually UI tests are already documented in the readme: https://github.com/piwik/piwik/blob/master/tests/README.screenshots.md and in the developer site: http://developer.piwik.org/guides/tests-ui I was asking what was the pain point to see if we could improve those resources... |
@mattab there is no documentation about fixtures though |
so the missing doc was Fixtures? that's a good point... do you mind create an issue in developer-documentation so we don't forget about this missing doc? it'd be nice to prevent other devs in the future from feeling this frustration 👍 |
Looks good to me, very nice change! this should make a big difference to user onboarding and help minimise a lot of frustrations for new users. |
Show the JS tracking code instead of the dashboard while no visit is tracked
There might be an issue with sites not having visitors every day. I updated a demo site to the latest beta build and instead of showing the dashboard, Piwik showed the tracking script. |
@RMastop are you clearing the |
@mnapoli that's it, I cleared logs and had only archived data on my instance. What are the ods that this happens in real live? Probably none. |
Good point, actually this could happen for many users, eg. if you setup the "Delete old logs" feature which deletes old logs. @mnapoli I think we should follow up before 2.12.0 and put some kind of safety net: maybe we disable this screen if the "delete old logs" feature is enabled? |
@mattab Yes indeed, but that is in the case where the entirety of log_visit is deleted for a site, is that a common scenario? Anyway:
That makes sense, will do on monday first thing. |
Fixes #7087
After creating a website (whether it is after the installation or after adding a new website to an existing install), you will see this page as long as no visits are recorded: