Omniture Context intergation

I would say as a sub module that would be handy

Either way seems good to me. The code is less than 100 lines including white space and comments.

sub

same patch as #10 w/o white space issues

This patch includes the code from the patch found here: #1791670: Allow sites to include variables (with token replacement) from the Omniture settings form ...

I included that code because it already handles token integration and the variable forms from that patch can be reused here.

the patch in #13 does not apply correctly. Please use this patch instead

...and now without the whitespace. Its weird ... every once in a while I get these hard tabs when I apply a patch and it makes me sad. Anyway...

This is a re-roll of #15 with a bug fix that prevented the "add another variable" button from working in the context reaction form. It includes the latest patch from #1791670: Allow sites to include variables (with token replacement) from the Omniture settings form as much of the code is shared. I would not commit this patch with first committing that one and then re-rolling

re-rolling now that #1791670: Allow sites to include variables (with token replacement) from the Omniture settings form has been committed

This is great!
It applied without problems to the 7.x-1.x. Did not interfere with the token variables I had set.

I've tried adding a global (always active) context with variables and it worked fine.
I've also tried adding custom variables for nodes of type article and checked that they were showing on articles an not on other content types.

The rendering of tokens in variables seemed to be working.

@bleen18 this is indeed a great feature and does add even more awesomer flexibility :)

+++ b/omniture.module
@@ -60,11 +60,49 @@ function omniture_theme($existing, $type, $theme, $path) {
+      $variables = $plugin->execute($variables);

+++ b/plugins/context/omniture_reaction_variables.inc
@@ -0,0 +1,67 @@
+  function execute(&$variables) {

I'm not sure why this is passed by ref and returned as a value here. Maybe this is the "context way". I think it would be clearer if this used either option instead of both at the same time (removing the & from the function signature would be the easiest option since the phpdoc won't need to be updated).

Other than that, I think this is totally RTBC

You are correct ... no reason to have both a return value AND pass-by-ref...

This patch should do it then.

Attaching a patch as a suggestion. (removes the return and an unnecessary variable and updates the comments, see interdiff).

Marking as RTBC since this is just a minor detail :)

Awesome!! Looks great...

Committed: http://drupalcode.org/project/omniture.git/commit/1f8320311c045c0b7460cf...