
I don't know about you but a security certificate error is not something I want to see on PayPal.
P.S. I'm testing Disqus on this post and on future comments.
Friday, November 02, 2007
DoubleClick PayPal cockup?
Posted by
Andrew Girdwood
at
1:17 PM
2
comments
Links to this post
Labels: code
Thursday, February 01, 2007
ARHG! Google News
I'm not loving Google News' problems right now. Simply put; Google News is broken. I work with a number of newspapers and magazines who are in Google News. Bigmouthmedia's own newsfeed is in Google News. I can tell you that Google News drives a lot of traffic and without it - you certainly notice!
Outer Court has a screen grab of what Google News looks like when it fails. Right now, though, you could probably just hit the home page and find it down.
Here's a screen grab relating to Google News that you probably haven't seen before, though.
You're looking at a crawl rate chart from Google's Webmaster Console for a significant publisher. The charts show that the kilobytes downloaded per day go up and down. Look at the numeric values though. It's the same value across the board. The Maximum, Minimum and Average download in kilobytes is exactly the same. For the last 90 days, according to Google, exactly 2097151 kb has been downloaded.
This particular quirk has persisted for many weeks now. What's going on? First of all 2097151 is a significant number. Do the binary maths. The most likely explanation is that the graphical chart is correct. For some reason, Google's integer counter for the kb download was capped and this particular newspaper has simply reached that cap.
Nevertheless, it's rare for Google to make this sort of coding mistake. It's unheard of for a google.com site to have this sort of technical problem.
Posted by
Andrew Girdwood
at
8:48 PM
0
comments
Links to this post
Labels: code, google news
Sunday, January 21, 2007
Horrendous code errors on Halifax Online
I logged into my main bank account for the weekly chore of bill paying. It broke. It broke through no code reason - they simply got the URLs to the account pages wrong. Badly wrong. Embarrassingly wrong.
See that? It's a rookie HTML error. It's just lazy coding. It's not just the credit card effected but all my accounts with them.
I just don't understand how a bank could make a howler like this. What about testing? They should have tested any changes for days. They would have paid big bucks for the change and for the test. Different departments would have been involved.
I phoned in to report the error. I had to let the woman go through her list of questions even though I could see what the error is. No one else had mentioned it to them - although, as she pointed out, the tip offs could have gone to different operators.
File this one under; What not to do in an online banking operation.
Posted by
Andrew Girdwood
at
11:38 AM
1 comments
Links to this post
Labels: code
Saturday, January 06, 2007
Blogger Custom Domain and my experiences
Google released a new "custom domain" option for Blogger. It's just a DNS setting which allows you to use your domain with Blog*Spot. You pay for the domain. Google pays for the hosting. I don't need to save the money but as this a kewl new toy from Google - I made the move and then thought about it later. Heh.
This blog used to use the URL www.arhg.net/blog/. It seems Google (the people at Blogger) didn't think about people who published to a folder. I'm sure not everyone FTP publishes to the root of their domain. In fact, I suspect more people publish to a folder or directory than root. The Custom Domain option doesn't cope with this very well.
After the DNS change filtered through my blog moved to www.arhg.net. The links and images in the blog, however, still pointed to www.arhg.net/blog/ and there was no /blog/ folder at Blog*Spot.
Simply put - the change broke the blog.
Here's the fix. I took back control of www.arhg.net and told Google to publish the blog to blog.arhg.net. That happened quickly. The links and requests for images at www.arhg.net/blog/ remained in place.
I used .htaccess to redirect anything in the /blog/ folder which ended in .html or .xml to the new blog.arhg.net. Since the images hadn't moved they weren't included in the redirect rule.
A quick way of applying redirects to just the /blog/ folder is to put the .htaccess in the /blog folder.
Here's my .htaccess rules.
RewriteEngine On
RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} !^arhg.net$ [NC]
RewriteRule ^([0-9]*_[0-9]*_[0-9]*)_arhg_archive\.html$ http://blog.arhg.net/$1_archive.html [L,R=301]
RewriteRule ^(.*)\.html$ http://blog.arhg.net/$1.html [R=301]
RewriteRule ^atom\.xml$ http://blog.arhg.net/feeds/posts/default [R=301]In time I'll move the images over to Google. Just to keep things neat.
In summary - did the custom domain option break your images? Publish to a sub-domain and redirect the .html and .xml files to the new address.
Posted by
Andrew Girdwood
at
7:13 PM
1 comments
Links to this post
Friday, November 25, 2005
Custom error pages, 404 header response and Google sitemap XML
A custom 404 page is important. You don't want to loose visitors off your site and an user friendly error page, one which quickly re-enpowers the user, is key here.
It's also key to ensure that your "page not found" message actually returns the 404 header response. At the end of 2004 in Vegas, Yahoo banged on and on about this in a presentation to SEOs and webmasters.
The 404 response is also key if you wish to make use of the reporting capabilities of Google's sitemap XML project.
The issue is that if you use Apache and an ErrorDocument command that you'll wind up with a 302 response - that might actually be correct as the server is redirecting the user agent to the custom 404 page.
An .htaccess file might look like:
ErrorDocument 404 http://www.example.com/404e.php The killer catch is that it's not possible to tweak Apache or use PHP to actually get requests to non-pages (www.example.com/no-page/ for example) to actually return the 404 header.The good news is that there is a compromise which Google accepts - and this compromise is good enough to get your sitemap XML verification file accepted.
With PHP you can have your custom error page issue a 404 header before showing you any HTML. That's fairly easy:
header("HTTP/1.0 404 Page not found");at the start of the page in a chunk of PHP.If you examine the header of the custom error page (404e.php in my example) then that does correctly return the 404 header.
Google is following the 302 to the custom error page and then checking the header off that error page. This is really what you'd expect Google to do as it's the only way to deal with two or more redirects in a chain.
The good news is that wikis and sites optimised to have SEO friendly URL structures can take part in the rather handy sitemap XML.
Now if Google would just set up the vanity URL http://sitemap.google.com for the lazybones among us - I'd be happy.
Posted by
Andrew Girdwood
at
4:45 PM
0
comments
Links to this post
