121 points
Community rank #462
rillc
El PresidenteJust Getting Started
MemberLikes (0)
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.
8212 pointsCommunity rank #6Supreme DeityDEVian The MagnificentLifetime member
WPMU DEV Fanatic
(joined October 2009)
Likes (0)
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?
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
David,
I am running the latest version 3.0.5. Yes, I do have the plugin network activated. And no, I do not have a prior version running in my mu-plugins folder.
8212 pointsCommunity rank #6Supreme DeityDEVian The MagnificentLifetime member
WPMU DEV Fanatic
(joined October 2009)
Likes (0)
Alright rillc, I was thinking it might have been a previous instance of the plugin in mu-plugins but I really can't see any other reason for it not saving at this point.
I'll alert Ivan and see what he might have to say.
8212 pointsCommunity rank #6Supreme DeityDEVian The MagnificentLifetime member
WPMU DEV Fanatic
(joined October 2009)
Likes (0)
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.
386 pointsCommunity rank #127ExpertJust Getting Started
Developer
(joined August 2010)
Likes (0)
Hi rillc,
Am, which version of the plugin you are using? The latests version doesn't offer you to enter tracking code under Super Admin, you can enter it under Settings->Google Analytics
8212 pointsCommunity rank #6Supreme DeityDEVian The MagnificentLifetime member
WPMU DEV Fanatic
(joined October 2009)
Likes (0)
Hi rillc, are you still having trouble with the code not saving? I'd like to be sure this one is sorted out before marking this thread as resolved. Could you let us know if everything's working for you now?
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
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.
386 pointsCommunity rank #127ExpertJust Getting Started
Developer
(joined August 2010)
Likes (0)
Can you delete the "ga_optiosn" DB entry in wp_options / wp_sitemeta depending on whether you have problems with the network-wide or site specific code and save it again.
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
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.
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
Ivan,
I have just upgraded to the latest version (1.1.7). Here is a link to the front of the site. While you are checking, please take a moment to check one of the sub-domain sites located here. This sub-domain site is currently using the the domain mapping plugin and has a separate GA tracking code attached to it. GA is not receiving data from it either.
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
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.
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
I am glad your problem is fixed Shawn, but another day has passed and my GA profiles are still show 0. But there is a check by all them indicating that data is being received. Anything you can ad Ivan?
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
@rillc, did you upgrade to 1.1.7, then make the changes I posted above, then ensure that the values were assigned at "/wp-admin/network/settings.php?page=google-analytics" ?
127 pointsCommunity rank #435El PresidenteJust Getting Started
Member
(joined October 2010)
Likes (0)
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!).
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
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.
10 pointsCommunity rank #5414SophomoreJust Getting Started
Member
(joined March 2010)
Likes (0)
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.
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
"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).
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
@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.
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.
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
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.
386 pointsCommunity rank #127ExpertJust Getting Started
Developer
(joined August 2010)
Likes (0)
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.
127 pointsCommunity rank #435El PresidenteJust Getting Started
Member
(joined October 2010)
Likes (0)
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:
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) );
121 pointsCommunity rank #462El PresidenteJust Getting Started
Member
(joined January 2009)
Likes (0)
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?
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
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. :(
@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.
386 pointsCommunity rank #127ExpertJust Getting Started
Developer
(joined August 2010)
Likes (0)
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.
11696 pointsCommunity rank #2Supreme DeityTrue DEVianLifetime member
Member
(joined April 2009)
Likes (0)
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.
1167 pointsCommunity rank #44Supreme DeityIn TrainingLifetime member
Member
(joined May 2010)
Likes (0)
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.
Responses (46)
WPMU DEV Fanatic (joined October 2009) Likes (0)
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
Member (joined January 2009) Likes (0)
David,
I am running the latest version 3.0.5. Yes, I do have the plugin network activated. And no, I do not have a prior version running in my mu-plugins folder.
WPMU DEV Fanatic (joined October 2009) Likes (0)
Alright rillc, I was thinking it might have been a previous instance of the plugin in mu-plugins but I really can't see any other reason for it not saving at this point.
I'll alert Ivan and see what he might have to say.
Cheers,
David
Member (joined January 2009) Likes (0)
Is there anymore that can be done about this? My issue has not be resolved.
WPMU DEV Fanatic (joined October 2009) Likes (0)
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
Developer (joined August 2010) Likes (0)
Hi rillc,
Am, which version of the plugin you are using? The latests version doesn't offer you to enter tracking code under Super Admin, you can enter it under Settings->Google Analytics
WPMU DEV Fanatic (joined October 2009) Likes (0)
Hi rillc, are you still having trouble with the code not saving? I'd like to be sure this one is sorted out before marking this thread as resolved. Could you let us know if everything's working for you now?
Cheers,
David
WPMU DEV Fanatic (joined October 2009) Likes (0)
Also, Ivan has just posed an update of the plugin which perhaps might further help out here,
http://premium.wpmudev.org/project/google-analytics-for-wordpress-mu-sitewide-and-single-blog-solution
Cheers,
David
Member (joined January 2009) Likes (0)
I will give it a try. I had removed the plugin because I was getting no where with it.
Member (joined January 2009) Likes (0)
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.
Developer (joined August 2010) Likes (0)
Can you delete the "ga_optiosn" DB entry in wp_options / wp_sitemeta depending on whether you have problems with the network-wide or site specific code and save it again.
Member (joined January 2009) Likes (0)
Whoa!!!! Come again Ivan? What want me to delete what? (LOL)
Dumb it down for me. :)
Member (joined January 2009) Likes (0)
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.
Member (joined January 2009) Likes (0)
OK, I have tried everything. I thought I had it fixed, but for the past two days GA stats are showing 0. I don't know what more I can do. Please help.
Developer (joined August 2010) Likes (0)
Can you post a link to the front of your site so I can check what exactly is the output of the plugin in the head.
Developer (joined August 2010) Likes (0)
Also please update to the latest v1.1.7
Member (joined January 2009) Likes (0)
Ivan,
I have just upgraded to the latest version (1.1.7). Here is a link to the front of the site. While you are checking, please take a moment to check one of the sub-domain sites located here. This sub-domain site is currently using the the domain mapping plugin and has a separate GA tracking code attached to it. GA is not receiving data from it either.
Let me know if you need anything else.
Member (joined May 2010) Likes (0)
Users can't edit their GA settings on my site with 1.1.7 either. HomeschoolBlogger.com
Member (joined May 2010) Likes (0)
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.
Member (joined May 2010) Likes (0)
Deleting all values and recreating the network settings doesn't fix the user ability to create their own GA tracking key. :(
Member (joined May 2010) Likes (0)
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.
Member (joined January 2009) Likes (0)
I am glad your problem is fixed Shawn, but another day has passed and my GA profiles are still show 0. But there is a check by all them indicating that data is being received. Anything you can ad Ivan?
Member (joined May 2010) Likes (0)
@rillc, did you upgrade to 1.1.7, then make the changes I posted above, then ensure that the values were assigned at "/wp-admin/network/settings.php?page=google-analytics" ?
Member (joined October 2010) Likes (0)
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
Member (joined January 2009) Likes (0)
@Shawn, I gave up on this plugin. It has since been de-installed and replace by the plugin I used previously.
Member (joined March 2010) Likes (0)
I have the exact same problem as the other users. I keep finding that several of your plugins never quite work out of the box.
Member (joined May 2010) Likes (0)
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.
Member (joined March 2010) Likes (0)
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.
Member (joined May 2010) Likes (0)
"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).
WPMU DEV Fanatic (joined October 2009) Likes (0)
Hi guys, I've gone ahead and pinged our developers so we should be hearing from one of them shortly. Thanks for your patients!
Cheers,
David
Member (joined January 2009) Likes (0)
@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.
Member (joined February 2009) Likes (0)
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.
Member (joined May 2010) Likes (0)
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.
Developer (joined August 2010) Likes (0)
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.
Member (joined October 2010) Likes (0)
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
Developer (joined August 2010) Likes (0)
Hi Scott,
Nice catch. I've updated the code to:
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
Member (joined October 2010) Likes (0)
Hi Ivan,
This is now working correctly for me. I get the domain without the "www".
Yes - I did see that the wp_site table had my root domain name.
I think I'm all set.
Thanks,
Scott
Member (joined January 2009) Likes (0)
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.
Member (joined May 2010) Likes (0)
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. :(
@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.
Member (joined January 2009) Likes (0)
@Shawn, did you set the filter settings for your subdomains in GA? I am thinking that this could be the problem.
Developer (joined August 2010) Likes (0)
Hi guys,
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 ?
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.
The filters in your GA account are usually used for excluding traffic from an IP/domain.
Member (joined May 2010) Likes (0)
Yes, using 1.1.9
Member (joined April 2009) Likes (0)
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!
Member (joined May 2010) Likes (0)
Once I had it working, I haven't needed to change the settings again.
I just tested it again, and (with 1.1.9) it's still not changing the UA code when I edit it in network admin.
Developer (joined August 2010) Likes (0)
Hi Shawn,
Very strange. Can you zip me the exact copy of the plugin you are running so I can check it against the released version and my local dev version ?
Member (joined May 2010) Likes (0)
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.
WordPress Questions?
We've got answers!
Find out more »