Sub-module to allow PHP so you can create dynamic Omniture JavaScript variables from the UI

I'm actually not sure :/

This was something that I just copied direct from the Google analytics module. I think it's for adding something that you want to be the same on every page. I can't imagine someone really using it for fancy javascript that sets variables - personally I'd rather do that via php where you have more access to data about the page.

I was thinking the same thing about using a PHP method instead of JavaScript which would be called before the Omniture code...

There are good security reasons not to put a php filter into the module (like if someone breaks into the omniture settings you don't want them to be able to take over the whole box...).

But, you can use php with a module. Perhaps a simple example module would be a good idea and we could even put the defaults in there?

Your security concern is really poignant. So the recommendation is to create a sub-module that uses the omni_hook function to populate custom variables?

Did this ever happen? Using this module on a site needing to add the Drupal page title in to the JavaScript so s.pageName= 'Drupal Page Title'; which will clearly need to be done with PHP.

Making the title more meaningful too. I hope! =)

Hmmm, changing again... sorry for the title ping-pong.

Thinking about this, obviously the preferred way forwards is for people to write their Omniture variables in to code. That's why hook_omniture_variables() exists, right? However, not everyone will always necessarily have access to the code or want it storing there.

I'll give you an example - we have a big client at the moment who wants to have their Omniture specialists in house be able to fiddle with variables, but these people won't have Subversion access or access to any of the servers. So it would be better for them if there were a box allowing PHP snippets and some examples. Obviously it's dangerous as hell - they can obviously WSOD the entire site with it, very easily, but they have a sandbox to play in and that's more an issue of proper channels and practices, rather than a concern of this module. That's what I'm thinking, anyway.

Sooo, following on from #4, I'm happy to make that a sub-module that provides an optional text area (and permission) to allow the execution of PHP code stored in the database if you like? Something that really does allow code snippets. Then I can provide the first snippets as the variables I need to add. It's a little more complicated than what I was planning to do, but it still won't take long. Happy to provide a patch.

Let me know if it's something you'd like, anyway. =)

A sub module seems great to me.

Cool, will work on it tomorrow and try to get a patch in ASAP.

Patch as promised. Made it so the module is in contrib/omniture_php, to be consistent with other modules containing contrib sub-modules. Hope this is ok.

Would be good if someone could review this. It's working well here, for the record:
http://newteachers.tes.co.uk

Nitpicks:

The standard in Drupal is to not include people's names:

+ * Created by Greg Harvey on 14 Jun 2010
+ *
+ * http://www.drupaler.co.uk
+ */

We should either provide a permission for this or re-use one of the core permissions related to PHP (and document that).

I'm surprised we need an extra submit function and can't just rely on system_settings_form - perhaps that's because this is form_altered in after the call to system_settings_form?

Of course, I should remove that from Eclipse - it's been kicking around for years, literally! =/

There was a permission for it:

/**
 * Implementation of hook_perm().
 */
function omniture_php_perm() {
  return array('use PHP to set Omniture variables');
}

But I forgot to implement it! Doh!

I'm not sure I tried to use system_settings_form()... to be honest, since execution order of modules can be pretty arbitrary, it's probably safer to do it with a separate submit function.

Re-rolled patch attached.