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
Add a hook to allow plugins to define the website ID to load by default when going to stats #908
Comments
This overlaps #401. |
Attachment: Patch to sort the default list of idSites based on the closest match to the current HTTP_HOST env variable. |
I have uploaded a simple brute-force method of identifying the closest match. It takes the current HTTP_HOST (if any) and iterates over the db results of viewable site ids. It splits on dots, and trims the two comparable hosts to the same level, so that biz.exmaple.com would also match example.com. If the matches are more than 1 (so, ignore any matches of just .net or .uk) but also equal to the number of parts less one (so give fudge factor to stats.example.com and biz.example.com) then the match is found. If a match is found, array_unshift it to a new array (so it's at the first position) then push all the other ids back onto this new array. I've tested this with my two sites, one of which has a subdomain. so, example.com and biz.mydomain.com are my two sites. But I access both with "stats.example.com" or "stats.mydomain.com". Logging in to either of the "stats" sites will give me my correct idSite in order. It's very handy. |
I feel that this patch also satisfies bug #401 because, in away, it allows the user to select which siteId is chosen by default by opening the piwik installation via a hostname. They could make a local entry in their "hosts" file to make "stats.anysite.com" point to their piwik installation, thereby allowing them to "choose" which siteId comes up by default in their own installation. |
Thoughts:
|
aaabbb2 , your patch sounds interesting. However such logic should be in a plugin. We can add a hook that would make it easy for plugins to change the list of website IDs.
|
I would suggest a small change to help with naming consistency. The function Piwik_SitesManager_API::getSitesIdWithAtLeastViewAccess() clearly returns site IDs, but "Piwik_PostEvent( 'Controller.selectDefaultWebsiteToLoad', $defaultWebsiteToLoad )" might suggest that $defaultWebsiteToLoad would be an entire record or object. I would propose using consistent "SiteId" instead of "Website" in the hooks. Piwik_PostEvent('Controller.selectDefaultSiteIdForIndex', $defaultSiteIdToLoad); The function Piwik_SitesManager_API::getSitesIdWithAtLeastViewAccess() only returns an array of site IDs, so the original patch had to perform an extra query to retrieve all the information about the sites with view access. It would be nice if the core "redirectToIndex" function loaded all the site records and passed those to the "selectDefaultSiteIdForIndex" or "selectDefaultWebsiteToLoad" so the plugin did not have to decide which sites are in question. The plugin should only concentrate on an algorithm for selecting the best from a list of possible choices ("WithAtLeastViewAccess"). So, perhaps a hook that looks like this: Piwik_PostEvent('Controller.selectDefaultSiteIdForIndex', $siteObjectsWithViewAccess, $defaultSiteIdToLoad); |
(In [1899]) Fixes #908 |
I have 1 piwik installation running 3 sites. I have mapped the server alias of stats.domainname to /usr/share/piwik. But, no matter which site I login on, I'm always given the first site I made as my starting idSite.
It would be a really nice enhancement to look at the domainname for the URL and try to find a match in the list of registered sites and select that idSite by default. This would only be done on login. Having this small feature would make setups like mine seem to function just a tiny bit slicker.
Suggested algorithm:
parse_url()
try to find the part before .com or .co.uk but after www. or stats.
find idSite by soundex() match to list of sites
if not found, choose idSite normally
Keywords: idSite, login, domain, subdomain
The text was updated successfully, but these errors were encountered: