gregscott
Forum Replies Created
-
I may have a tentative solution – at least a direction to try.
I mentioned a couple posts ago that I am now hosting two websites:
http://www.infrasupport.com and
http://www.bullseyebreach.comThe Infrasupport website was first and it had the problem with Universal Tracking. Bullseyebreach worked just fine.
Day before yesterday, I checked the Universal Tracking checkbox with Infrasupport and this time I still see Google Analytics data. What’s different but common to both websites? It has to be firewall rules. I made a couple firewall rule changes, including a rule to support HTTPS. I have a hunch that’s the difference. I’ll bet all these websites with Universal Tracking problems are with hosting providers that don’t support HTTPS, only HTTP. See if you can get your hosting provider to allow HTTPS to your websites and if the Universal Tracking problem goes away after that.
And assuming I stumbled onto a solution, I’m still disappointed I had to find it by trial and error. Environmental requirements like that should be documented.
I’m not going to check the “Mark as resolved” box yet until somebody else is able to verify what I found.
– Greg
As long as we’re on this topic – how do you test Google Analytics? Instead of waiting for hours for a timeout, I want to try configuration changes and then click a button to see the effect. Is there a way to do that?
– Greg
I might be able to help. I haven’t done anything about this with the website I originally posted about, http://www.infrasupport.com. That one is still the same. But I just put another website into production, http://www.bullseyebreach.com, and that one does have Universal Tracking turned on and seems to be working just fine.
Both websites are behind the same firewall, but I’ve made some rule changes since then for HTTPS and FTP. That may be significant. Each is on a different virtual machine, but both came from the same template. wp-config.php is a little different on the bullseyebreach.com website. The bullseyebreach.com website has a newer version of the plugin.
The good news is, I now have a working website in the same environment as the non-working website, but now updated. After I get some sleep, I’lll try to turn on Universal Tracking again on the Infrasupport website and update the GA plugin to the latest and greatest and see how it behaves.
On support in general for this plugin – I’m disappointed. I even wrote up the problem on github but got nowhere. The feedback I read from the plugin developers is, it’s something environmental and they closed the case. That’s not good customer service. Even if the plugin is free, this is presumably the base for paying customers. If it’s something environmental – and it probably is – how about some guidance? Some kind of documentation, a troubleshooting guide, something. Why make your users — who are evaluating whether or not to invest in your premium product — independently guess by trial and error? It’s not a confidence builder.
– Greg
Forum: Fixing WordPress
In reply to: Possible security issue – website defacedHard to say. Getting rid of that widget was easy – just a drag and drop. But the fundamental problem, that the world can still touch wp-login.php is still with us. Here is a sample a few minutes old from my /etc/httpd/logs/access_log:
78.7.192.66 - - [23/Feb/2015:22:32:22 -0600] "POST /wp-login.php HTTP/1.1" 200 2910 "http://www.infrasupport.com/wp-login.php" "Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML like Gecko) Chrome/31.0.1650.57 Safari/537.36"It looks like the only thing protecting me from the bad guys by default is a strong password.
– Greg
Forum: Fixing WordPress
In reply to: Possible security issue – website defacedThat turned out to be an easy fix – it should be gone now.
– Greg
Forum: Fixing WordPress
In reply to: Possible security issue – website defacedOh wow – I never paid any attention to that. Thanks. I’ll figure out how to get rid of it. It’s probably one of those Responsive widgets. Now I get what you’re trying to tell me – thanks!
– Greg
Forum: Fixing WordPress
In reply to: Possible security issue – website defacedRe: Robinmnz – what meta widget? Those admin-ish PHP files are core components of WordPress. The log entry I posted is raw data left by Apache every time somebody accesses my website. The status code of 200 means somebody at that outside IP Address touched the WordPress wp-login.php. That’s because I have to set Apache to grant access to that directory for the whole world, which means I must trust any security mechanisms built into WordPress. I wish WordPress would collect all these scripts the webmaster uses into a separate directory so it can be locked down.
Re: Bernbe01 – possibilities – thanks!
– Greg
Forum: Fixing WordPress
In reply to: Possible security issue – website defacedHmm… This log entry is ugly:
78.6.46.218 - - [19/Feb/2015:08:11:07 -0600] "POST /wp-login.php HTTP/1.1" 200 2910 "http://www.infrasupport.com/wp-login.php" "Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20100101 Firefox/17.0"It just dawned on me, all these admin-ish PHP files are sitting in the top of the directory structure. I should probably block access to this from the outside in my .conf file. I wonder if WordPress has any facility to monitor login failures?
– Greg
Forum: Fixing WordPress
In reply to: Possible security issue – website defacedThanks Robinmnz – the website is self hosted and the Century Link Internet connection coming into here had an outage last night right about the time you checked. Back online now.
I was about to say there is no ftp access to the site. But I just tested it from the outside and to my horror, ftp did give me a login prompt. GETs and PUTs don’t seem to work however. You can bet I’ll be turning that off at my firewall today! Carelessness on my part.
I took a look through the whole WordPress directory structure and I don’t see anything I’m not able to identify.
Even though I was careless, I don’t think this was an ftp attack. Apparently, somebody knows how to penetrate WP 4.1. I’ll do some digging through my access_log files and see if anything interesting turns up.
– Greg
Forum: Plugins
In reply to: [Really Simple CAPTCHA] I think I know why CAPTCHA images are brokenHi Vadanic – My .htaccess won’t do you any good because I did all my protecting using the httpd .conf files. I’ll paste both of them in below. Here’s what I did for my .htaccess file – I just commented everything out.
[root@www wpcf7_captcha]# [root@www wpcf7_captcha]# pwd /usr/share/wordpress/wp-content/uploads/wpcf7_captcha [root@www wpcf7_captcha]# ls -al total 12 drwxrwxr-x. 2 apache apache 47 Jan 20 10:44 . drwxrwxr-x+ 5 apache ftp 48 Dec 22 00:06 .. -rw-r--r--. 1 apache apache 112 Dec 22 20:08 .htaccess -rw-r--r--. 1 root root 102 Dec 22 19:55 .htaccess-disabled [root@www wpcf7_captcha]# more .htaccess ##Order deny,allow ##Deny from all ##<Files ~ "^[0-9A-Za-z]+\.(jpeg|gif|png)$"> ## Allow from all ##</Files> [root@www wpcf7_captcha]#And here is what I did in my infrasupport.conf file. It turns out, there are other plugins and pieces that need special permissions on other files and directories. And near as I can tell, these aren’t documented anywhere and there’s no consistent guidance on how to do them. So every single plugin may have similar issues. My workaround will not be universal.
[root@www conf.d]# pwd /etc/httpd/conf.d [root@www conf.d]# ls autoindex.conf infrasupport.conf perl.conf README ssl.conf webalizer.conf wordpress.conf BackupPC.conf manual.conf php.conf squid.conf userdir.conf welcome.conf [root@www conf.d]# [root@www conf.d]# [root@www conf.d]# more infrasupport.conf ##<VirtualHost www.infrasupport.com:80> <VirtualHost *:80> ServerAdmin gregscott@infrasupport.com DocumentRoot /usr/share/wordpress ServerName www.infrasupport.com ## ErrorLog "/usr/share/wordpress/logs/error_log.log" ## CustomLog "/usr/share/wordpress/logs/access_log.log" combined Alias /wordpress /usr/share/wordpress <Directory /usr/share/wordpress> # # Directives to support Permalink settings by post name instead of the default. # See Settings...Permalinks. # <IfModule mod_rewrite.c> RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> AllowOverride Options <IfModule mod_authz_core.c> # Apache 2.4 ##Require local Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 </IfModule> </Directory> <Directory /usr/share/wordpress/wp-content/plugins/akismet> <FilesMatch "\.(php|txt)$"> Order Deny,Allow Deny from all </FilesMatch> </Directory> # # Need this for the ReallySimple CAPTCHA plugin # <Directory /usr/share/wordpress/wp-content/uploads/wpcf7_captcha> Order deny,allow Deny from all <Files ~ "^[0-9A-Za-z]+\.(jpeg|gif|png)$"> Allow from all </Files> </Directory> <Directory /usr/share/wordpress/wp-admin> ## AllowOverride Options AllowOverride All <IfModule mod_authz_core.c> # Apache 2.4 ##Require local Require ip 10.10.10 ##Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Deny from All Allow from 127.0.0.1 Allow from ::1 Allow from 10.10.10 </IfModule> <Files "admin-ajax.php"> <IfModule mod_authz_core.c> # Apache 2.4 Require all granted </IfModule> <IfModule !mod_authz_core.c> # Apache 2.2 Order Deny,Allow Allow from All </IfModule> </Files> </Directory> </VirtualHost> [root@www conf.d]#I wish I knew the first thing about writing WordPress plugins and then maybe I could offer something useful on github. But looking there, I see:
This is a developer’s portal for Google Analytics for WordPress by Yoast and should not be used for support. Please visit the support forums.
This behavior of forcing SSL onto non-SSL websites with no ability to change it seems like a bug to me. I suppose I could write it up as a bug report over there. Do the Yoast folks ever look here, in this support forum, for support issues?
I just wrote it up in Github.
https://github.com/Yoast/google-analytics-for-wordpress/issues/280In case this forum butchers the link above, you can paste this into notepad and tinker with it a little bit to turn it into a URL:
https github.com slash yoast slash google-analytics-for-wordpress slash issues slash 280
– Greg
I’m hosting my own. But maybe there are similarities in the httpd setups in both our environments. I didn’t put anything in to support HTTPS in my hosting setup. Maybe that’s what we have in common. Do you have a way to check what Dreamhost supports?
And maybe the Yoast fix is to put in a setting to enable/disable force SSL.
– Greg
Which brings up a question – how does this stuff work? Does Google “pretend” to be a web browser and pull info from the site? Or does Google listen and the site pushes info to Google? Probably the first choice – Google probably goes to a special URL to find the plugin and pull what it wants. But apparently the plugin is expecting SSL and Google sends a straight HTML request?
So maybe there’s a setting in the plugin for that? But I don’t see any settings in the plugin to change SSL vs. HTTP. I see one setting in Google Analytics – Admin…Property Settings … Default URL. This is set to http:// and not https://.
Since I don’t see any plugin buttons to regulate HTTP vs. SSL, should I set the default URL in Google Analytics to https? But to make that work, I’ll probably need a bunch of apache .conf changes to support an SSL website.
So I don’t get it – does the website need to be an https website for Universal Tracking to work? And if so, is this written down somewhere and I missed it? How do I fix it?
But wait – if the code says force SSL, and the plugin truly only wants to deal with SSL, how come it works at all right now when I uncheck “Enable Universal Tracking”?
– Greg
Thanks. But before we give up and go to an older version, maybe we can figure out what’s wrong. I’m not doing any sophisticated tracking so I can experiment.
If this were happening to everyone using 5.2.7, this forum would be filled with threads about the problem. But, near as I can tell, this is the only one. So what’s different about hrbergfors’ website and my website reporting the problem versus everyone else?
Well – I rebuilt mine from scratch a couple weeks ago after a massive server hardware failure here. But I set up the Google Analytics page almost 2 years ago when I built the website for the first time. A couple days after my server ate itself, Google Analytics emailed me with a message it was no longer receiving data from my website. I was back online a day or so later. Could that be relevant?
I was thinking, one experiment might be to delete the property in Google Analytics and add it back in again. Would that give Yoast anything usable?
– Greg
Well…
Looking at the Google Analytics page for my website – I think the way to get there is Admin Settings…Property Info…Tracking info…Tracking Code in the left pane.
Here’s what it says in the main window section on the right. I’m pasting this in so I’ll mark it in quotes:
Website tracking
This is the Universal Analytics tracking code for this property. To get all the benefits of Universal Analytics for this property, copy and paste this code into every webpage you want to track.
So Google Analytics says the website **does** have Universal Tracking. But Google says it’s not receiving data unless I uncheck Universal Tracking with the plugin. I’m using version 5.2.7. I pasted in the code the plugin generates earlier.
So the plugin only works for me if the plugin does **not** match the Analytics property settings.
With Universal Tracking checked in the plugin, I’ve tried both manually putting in the UA number from the Google Analytica page and automatically doing it. No difference in behavior. The only way I can make the plugin work is uncheck “Universal Tracking” in the plugin.
– Greg