| Project: | Piwik Web analytics |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
Issue Summary
I like the way that piwik_footer is going. As a result of a current need, I had to implement some internal search statistics tracking. This required not only a piwik module (and a mod to piwik itself to support a new hook) but I modified the piwik_footer to be more extensible. I wasn't able to finish the work, but I wanted to discuss the changes I made.
The following bit of cod is what inspired the changes that I made.
// Site search tracking support.
if (module_exists('search') && variable_get('piwik_site_search', FALSE) && arg(0) == 'search') {
$keys = search_get_keys();
$piwik_vars['search_type'] = arg(1);
$piwik_vars['search_keys'] = trim($keys);
}It is clear that the search support is conditional and in fact there are two other conditional areas in this block. It would seem to make sense that a hook should replace this code and have it externalized from the main module. ie. piwik_search.module that implements the hook. Now, I have not gone as far as making the hook yet, but I did change the way the script was built so that it could be modified prior to compiling the final script value.
Ignoring what I did inside the search code block, you can see that I now use an array to compile a list of values that will eventually be used to create the script. By using this array, I envision passing the array to the hook method so that implementors will be able to modify/create values for the script.
Now, the changes I made to the search block, could be seen as more controversial (which is why I ultimately wanted a hook). In my case, I created a piwik plugin that implements a new hook when an action is recorded (Tracker.recordAction). This allows my InternalSearch plugin to grab the data from the piwik_custom_vars array and store it in a separate table. In my case, I am storing the keywords that were used to get to the target page. So, I needed to modify what happens in the script when the current page is a search page.
I feel like I'm only a heartbeat away from creating the hook implementation, but I don't think I'll be able to get to it soon. I've written this issue so that we can discuss what I've done and see where it can take the module.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| piwik_footer.patch | 5.85 KB | Ignored: Check issue status. | None | None |
Comments
#1
I should also note that I added a new file piwik_search.php and modifed the .install to place it in the proper location. This was done to facilitate the use of a session var for my specific plugin's needs.
#2
Are you aware about a link to the API documentation of piwik for this feature?
#3
No, I am not familiar with any other pugin that does this. The closest that I came was this issue that talks about the features it should have. Do you have better info that I can use?
#4
Sorry, but I'm very reluctant to add hacks. Postpone this feature until Piwik have this functionality added.
#5
I'm ok if you don't want the search stuff that I put together. However, the other code that surrounds it is designed to make the footer more extensible. What I have not finished yet, is the hook call implementation. Once that is complete, ANY module could be written to hook into the footer processing. This is actually a good example of why that would be desired. Each of those if blocks that are currently commented out would be better served as modules that add that functionality into the process. The way the script gets built now allows that to happen outside of this method.
Also, you previously mentioned that piwik might have support for internal search, can you point me in the right direction so that I might take a look at what is available?
#6
You can already use theme functions to "hook" into the footer in D6. See http://drupal.org/node/284599 for an example.
#7
Ok, I can see how that works. But in the meantime of getting your post, I implemented the hook to show where I was going with the change I suggested. It seems that in either case, using a theme function or using a custom hook, a module developer that wanted to integrate with the plugin would be obligated to implement an additional method. In my suggestion, the overridden method would not only "feel" like it relates to the but also be slightly less complex.
The template style
<?php
function mymodule_preprocess_page(&$variables) {
// Example code. Make sure your module runs all values through drupal_to_js() to be protected against XSS.
$before = 'pageTracker._setDomainName(".example.com");';
$after = 'pageTracker._addTrans("1234", "My Partner Store", "84.99", "7.66", "15.99", "Boston", "MA", "USA");';
$after .= 'pageTracker._addItem("343212", "DD4444", "Lava Lamp", "Decor", "34.99", "1");';
$after .= 'pageTracker._trackTrans();';
$variables['closure'] = preg_replace('/(.*)(<script type="text\/javascript">var pageTracker = _gat._getTracker\("(UA-\d{4,}-\d+)"\);)(.*)(pageTracker._trackPageview\((.*)?\);)(.*)(<\/?script>)(.*)/i', "$2$before$4$5$7$after$8", $variables['closure']);
}
?>
My suggested custom hook version
<?php
function mymodule_piwik_footer(&$settings) {
// Example code. Make sure your module runs all values through drupal_to_js() to be protected against XSS.
$before = 'pageTracker._setDomainName(".example.com");';
$after = 'pageTracker._addTrans("1234", "My Partner Store", "84.99", "7.66", "15.99", "Boston", "MA", "USA");';
$after .= 'pageTracker._addItem("343212", "DD4444", "Lava Lamp", "Decor", "34.99", "1");';
$after .= 'pageTracker._trackTrans();';
$settings['_piwik_codesnippet'] .= $before . $after;
}
?>
Now, right off the bat, I can see my implementation has the shortcoming that it doesn't support the before/after situation from your example. However, that could easily be remedied by replacing _piwik_codesnippet with _piwk_pre_php and _piwk_post_php. On the other hand it removes the potential fragility of the regex that is depending on a certain string to be present in the original closure.
I attached the new implementation along with my piwik search module to show what I was aiming for. The patch constitues the full changes I made to the original module (all other changes were extracted into my module). In the same way that I pulled out my search impl the other bits of commented code could be pulled out to make a more modular plugin.
#8
I have implemented the site search today. This case seems to be a duplicate.