UA Tracking Code will not save in box

This is very strange. I have installed the plugin. However, when I went to the Super Admin area to input my UA tracking code number there was one already in there (don't know where it came from). When I change it to the UA number from my account I click "save changes", however when I view the source code the number is not the number I put in...it is the number that was originally there. When I go back into the admin area to look at it, I notice that the number I put in is no longer there.

Any suggestions on how I can fix this problem?

  • DavidM
    • DEV MAN’s Mascot

    Hello rillc,

    I'm sorry you're having trouble with the plugin, but let's see if we can get this sorted for you.

    The default number is normal behavior for the plugin, but the fact that it's not storing your change is strange. Would you mind letting us know the following?

    Which version of WordPress are you using?
    Have you Network Activated the plugin?
    Do you have a prior version in a mu-plugins folder?

    Cheers,
    David

  • DavidM
    • DEV MAN’s Mascot

    Very sorry about the delay rillc. I've alerted Ivan once more. Just wanted to check also, have you tried seeing if there's another plugin conflicting with this one? Momentarily disabling various plugins helps to weed out a possible culprit.

    Cheers,
    David

  • rillc
    • Site Builder, Child of Zeus

    OK, I reinstalled the plugin and I am gettting the exact same problem. When I input the UA tracking code and then hit he save button. Th UA code automatically reverts to some other UA number.

    I don't know what more I can do.

  • rillc
    • Site Builder, Child of Zeus

    Nevermind, I think I found what you were talking about. I replace the default UA number that was listed in wp_sitemeta. It appears to be showing in the dashboard now. Now all we have to do is wait and see if GA will report data using the domain mapping plugin.

  • Shawn
    • The Crimson Coder

    Interesting. I've been playing in the db the last hour or two, and just noticed that there are a LOT of value pairs for "ga_settings" in the sitemeta table for the home blog. In fact, there are 107 different rows for this meta_key. No wonder I'm having problems.

  • Shawn
    • The Crimson Coder

    I've got a fix for this. Two issues, actually. Open google-analytics-async.php (v1.0.7) and edit the following lines:

    Line 170:
    if ( is_plugin_active_for_network('google-analytics-async/google-analytics-async.php') && version_compare( $wp_version, '3.0.9', '>' ) )

    Line 254:
    $settings['tracking_code'] = $this->site_settings['tracking_code'] = trim( $_POST['site_tracking_code'] );

    The change on line 170 ensures that even a superadmin that visits a blog is able to assign a site-level UA code to a blog in the Settings/GA menu.

    The change on line 254 enables the "save" functionality for non-super-admin users. Without this change the wrong field name is parsed.

  • BlueSkies
    • Site Builder, Child of Zeus

    I am re-opening this support topic, as it does not appear to be officially resolved.

    I am using WP 3.1 and the latest Google Analytics plugin 1.1.7 (on a local install I am using to check out WP3.1).

    I am seeing the same problem. Any tracking code entered by a regular user for their subdomain site is not being saved.

    Ivan - could you release a new version of the plugin to fix this? I'm hesitant to put Shawn's fix into a production version without your review (though his efforts are very much appreciated!).

    Thanks,

    Scott

  • Shawn
    • The Crimson Coder

    This plugin, as released, attempts to store a form field that isn't the correct name (line 254). The other issue on line 170 is really more cosmetic than anything, but it's frustrating that it operates differently (by removing the normal menu item) if you're logged in as a super-admin on a blog.

    @demonmedi, I appreciate your concern, but you have to take into account that WP 3.1 was just released a week ago and WPMUDev had to re-release almost everything to update compatibility settings for paths, security and the new structure. Please have a little patience and I'm sure they *will* correct every issue that's reported to them.

  • demonmedi
    • WPMU DEV Initiate

    I found a far better plugin that does exactly the same as yours, but better.. not only that, it works and is free! You really got to keep on top of things. The membership to your plugin collection is very expensive, specially if some of the plugins do not work.

  • Shawn
    • The Crimson Coder

    "Yours" isn't accurate: I do not work for WPMU Dev. I'm a customer, same as you.

    Can you share a link to the other plugin? I'd be interested to know if it actually has the same level of features as this one (multiple-profile tracking, first of all, but also admin tracking and sub-domain mapping).

  • rillc
    • Site Builder, Child of Zeus

    @Shawn, I completely understand. My experience with WPMU Dev has been for the most part a very good one and this particular issue has not/will not deterred me from using other plugins developed by WPMU Dev. However, demonmedi has a point. WPMU Dev is very expensive. And for the amount of money we pay to use this service it should not be too much to ask that the plugins work as promise or that support be provided as needed.

    I am looking forward to using this plugin in the future.

  • Tracy
    • The Incredible Code Injector

    Here's a link for a working and free option: http://wordpress.org/extend/plugins/google-analytics-multisite-async/

    This plugin has been a bit of an experiment with us as the guinea pigs since it replaced the non-async version .....It's very hard to depend on WPMUDEV since they are taking weeks and sometimes months to fix plugins. If you have clients depending on your service, like we do, using WPMUDEV is turning into a bit of a gamble in terms of their performance in answering questions, fixing problems and updating documentation.

  • Shawn
    • The Crimson Coder

    Hi, @Tracy, I fully agree about the turnaround for getting updates to plugins and themes that have known and repeatable issues. This one, for example, I posted the code to fix it three days ago and the repository still has the broken code. A guaranteed turnaround of some type sure would be nice.

    As for the other plugin - note that it doesn't have a Nonce, so it would be possible for any of your users that have a means to create a form that would inject their own GA code ino the global database. All it would take is creating an image or other reference that would be seen by any superadmin user. I posted demo code for a similar flaw on the BuddyPress forum a year and a half ago, and it was fixed within 24 hours.

    While I agree that the turnaround for maintenance for WPMU Dev may be less than it could be in some situations, it is comforting to me that this type of security issue hasn't been a problem with their plugins. Stability and security trump immediacy any day of the week. The forum here (this post is a perfect example) also provides a far more effective means of addressing problems like this than the one on WP. It is regularly monitored and plugins *are* supported - both by WPMU Dev and by the rest of the community - which is something you often won't get at all from the free plugins out there, whether they're broken or not.

  • Ivan
    • The Incredible Code Injector

    Hi guys,

    Sorry for the delay. I've been a bit in a limbo lately due to the high volume of projects coming my way.

    Shawn, thanks for spotting the bugs and pointing them out, hugely appreciated. I have re-engineered the plugin a bit based on your feedback.

    Everyone, please update to version 1.1.8

    Update Notes:
    1. Current version is not backward compatible with WP 3.0
    2. In the current version you manage your Network-wide tracking code in Network Settings and all site specific tracking codes in Site Settings.

    Tracy, rillc, BlueSkies, demonmedi sorry for the headaches I've caused you, hopefully the current version will work without any problems.

    Shawn, if you can test the plugin and report back whether everything is working for you that will be great. If you think something should be improved I'll be happy to have a discussion about it with you.

  • BlueSkies
    • Site Builder, Child of Zeus

    Hi Ivan,

    Thanks for the update. I think there is still a bug though.

    I have a multi-site setup where I change the root blog to be http://www.mydomain.com. The relevant code from wp-config.php is as follows. It is assumed that blog id = 1 is for mydomain.com and blog id=3 is for http://www.mydomain.com:

    define ( 'BP_ROOT_BLOG', 3 );
    define('WP_ALLOW_MULTISITE', true);
    define('MULTISITE', true);
    define('SUBDOMAIN_INSTALL',true);
    $base = '/';
    define('DOMAIN_CURRENT_SITE','www.mydomain.com');
    define('PATH_CURRENT_SITE','/');
    define('SITE_ID_CURRENT_SITE',1);
    define('BLOG_ID_CURRENT_SITE',3);

    When I use your latest version of the plugin, I see code generated that includes the line:
    _gaq.push(['_setDomainName', '.www.mydomain.com']);

    I believe that this is not correct.
    See the references:
    http://code.google.com/apis/analytics/docs/gaJS/gaJSApiDomainDirectory.html#_gat.GA_Tracker_._setDomainName

    http://code.google.com/apis/analytics/docs/gaJS/gaJSApi_gaq.html#_gaq.push

    I think that this line should instead be:
    _gaq.push(['_setDomainName', '.mydomain.com']);

    I looked at your plugin code and think the culprit might be on L87-88:
    if ( defined('DOMAIN_CURRENT_SITE') && DOMAIN_CURRENT_SITE ) {
    $this->domain = DOMAIN_CURRENT_SITE;

    Instead of this, you may wish to lookup the domain associated with SITE_ID_CURRENT_SITE
    The following fix worked for me:
    if (defined('SITE_ID_CURRENT_SITE')) {
    $this->domain = str_replace( 'http://', '', get_site_url(SITE_ID_CURRENT_SITE) );

    Scott

  • Ivan
    • The Incredible Code Injector

    Hi Scott,

    Nice catch. I've updated the code to:

    global $wpdb;
    $this->domain = $wpdb->get_var( "SELECT domain FROM {$wpdb->site}" );

    Can you verify that this gets the domain without the "www" ? You can look inside your "wp_site" table to check the domain under the "domain" column.

    Everyone please update to v1.1.9

  • rillc
    • Site Builder, Child of Zeus

    OK, I reinstalled this plugin, I checked my GA stats this morning and I got all "0"s again. Even my root blog recorded all zeros.

    I have just updated to v1.1.9. However, for those of you who are having success, it would be helpful to know what your filter settings are. What should the filter settings be.

    Secondly, I've noticed that some of you are referring to your databases to make modifications. I am not technical and don't really know what I am looking for. Can someone take a moment to "dumb" things down for me so that I too can make changes where necessary?

    Thanks for your help in advance.

  • Shawn
    • The Crimson Coder

    Thanks, Ivan, it's working perfectly for me now. There does still appear to be a couple bugs. Clearing (emptying) or changing the network UA code doesn't work on save. It looks like the other options do change OK, but not the UA code. To replicate, go to the network config page, change the UA code and either admin/subdomain and save. THEN click the Google Analytics link in the network settings menu again to see the actual stored data - which is different than you just "saved".

    I do want to thank you for separating the network and site configuration options. One of our admins (who really shouldn't be), kept changing the network setting because she just "didn't get it", resulting in over a week of lost stats. :slight_frown:

    @rillc, you should not need to edit the database directly at all. Accessing the database directly (through phpMyAdmin, for example) is an excellent way to diagnose problems, but is rarely required for a stable plugin or theme. If you ever do need to access the database, the most important plugin-related settings are usually within the wp_options table. In any case, until the stuff above is fixed, you should probably hold off on relying on the settings pages.

  • Ivan
    • The Incredible Code Injector

    Hi guys,

    There does still appear to be a couple bugs. Clearing (emptying) or changing the network UA code doesn't work on save. It looks like the other options do change OK, but not the UA code. To replicate, go to the network config page, change the UA code and either admin/subdomain and save. THEN click the Google Analytics link in the network settings menu again to see the actual stored data - which is different than you just "saved".

    Shawn, I've tried to recreate this but without any luck everything saves perfectly for my install. I've tried it on 3 different WP 3.1 installs and all of them save the code or the other settings without a problem. Are you sure you are using the 1.1.9 version ?

    OK, I reinstalled this plugin, I checked my GA stats this morning and I got all "0"s again. Even my root blog recorded all zeros.

    rillc, if the tracking code is not working it should display "Tracking Unknown" and a exclamation mark under your Website Profiles "Status" field inside your GA account.

    Did you set the filter settings for your subdomains in GA? I am thinking that this could be the problem.

    The filters in your GA account are usually used for excluding traffic from an IP/domain.

  • Mason
    • DEV MAN’s Sidekick

    Hiya Shawn,

    Did you get this one sorted? I know we had a couple other folks with the same issue and it turned out to be old entries from a different analytics plugins still stored in the database.

    I'm gonna mark this as resolved for now, but feel free to re-open if you need further assistance.

    thanks!

  • Shawn
    • The Crimson Coder

    This is what I'm using. The MD5 of the contained files match the 1.1.9 release version exactly. I looked at the form and form processing code and can see no reason for the problem. And yet, It's still not allowing me to change the network UA code. I'm not using Supporter - but I don't see why that would cause any problems.

    I checked the sitemeta table and found 793 copies of the ga_setttings option. I deleted them all. Went back to the config page and saved the option again. It let me save it the first time, but again would no longer allow updates to the UA value after that. Saving it several times did not allow any changes, but also didn't duplicate the values within sitemeta anymore.

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.