Skip to content
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

Closed
anonymous-matomo-user opened this issue Aug 6, 2009 · 8 comments
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.
Milestone

Comments

@anonymous-matomo-user
Copy link

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

@robocoder
Copy link
Contributor

This overlaps #401.

@anonymous-matomo-user
Copy link
Author

Attachment: Patch to sort the default list of idSites based on the closest match to the current HTTP_HOST env variable.
sort_idsites_by_http_host_relevance.diff

@anonymous-matomo-user
Copy link
Author

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.

@anonymous-matomo-user
Copy link
Author

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.

@robocoder
Copy link
Contributor

Thoughts:

    Referer: http://example.com/?module=CoreHome&idSite=2

@mattab
Copy link
Member

mattab commented Aug 17, 2009

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.
For example, we could add a new hook:

Index: core/Controller.php
===================================================================
--- core/Controller.php (revision 1383)
+++ core/Controller.php (working copy)
@@ -285,11 +285,20 @@

    function redirectToIndex($moduleToRedirect, $actionToRedirect)
    {
-       $sitesId = Piwik_SitesManager_API::getSitesIdWithAtLeastViewAccess();
-       if(!empty($sitesId))
+       $defaultWebsiteToLoad = false;
+       Piwik_PostEvent( 'Controller.selectDefaultWebsiteToLoad', $defaultWebsiteToLoad );
+       if(empty($siteIdToLoadByDefault))
        {
-           $firstSiteId = $sitesId[0];
-           $firstSite = new Piwik_Site($firstSiteId);
+           $sitesId = Piwik_SitesManager_API::getSitesIdWithAtLeastViewAccess();
+           if(isset($sitesId[0])) 
+           {
+               $defaultWebsiteToLoad = $sitesId[0];
+           }
+       }
+       
+       if(!empty($defaultWebsiteToLoad))
+       {
+           $firstSite = new Piwik_Site($defaultWebsiteToLoad);
            if ($firstSite->getCreationDate()->isToday()) 
            {
                $defaultDate = 'today';

@anonymous-matomo-user
Copy link
Author

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);

@mattab
Copy link
Member

mattab commented Mar 12, 2010

(In [1899]) Fixes #908
aaabbb2, I didn't pass the full array of websites info as this has performance impact (by default, Piwik doesn't load this data).

@anonymous-matomo-user anonymous-matomo-user added this to the Piwik 0.5.5 milestone Jul 8, 2014
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement For new feature suggestions that enhance Matomo's capabilities or add a new report, new API etc.
Projects
None yet
Development

No branches or pull requests

3 participants