Would Be Blog Owners Report Inability To Create A Blog

We are currently seeing an occasional report, in Blogger Help Forum: Something Is Broken, from a frustrated would be new blog owner.

I can't create a blog - the "Create" button is grey (inoperative)!

or

It keeps saying

Verifying availability

when I enter a blog name!!

Both of these problem reports - and others - may come from people who don't read the instructions, for using the wizard. Alternately, some folks may be reporting yet one more case of over done layered security.

The most obvious problems, in the blog creation process, come from people who don't understand how to use the "Create a blog" wizard. Not every would be blog owner understands that 3 things must be done, to make the "Create a blog!" button operative.

1. Enter a Title for the blog.
2. Enter an acceptable and available Name for the blog.
3. Select a Template for the blog.

When you choose a Name (aka "address" or "URL"), enter your choice properly.

• Only enter the "xxxxxxx" part of "xxxxxxx.blogspot.com".
• Only use lower case alphabetic characters ("a" - "z"), numeric characters ("0" - "9"), and dashes ("-").
• Do not use a trailing dash (You cannot publish "xxxxxxx- . blogspot . com").

Besides the syntax issues when entering a blog name (URL), there is the unfortunate issue of competition in the creation process. Blog owners who are anxiously creating a new blog, based upon a current event - maybe a popular movie star, or an important political campaign - will be dismayed to see

Sorry, this blog address is not available.

Many people want to setup a blog, based on that blog name. Some may see the bad news, repeatedly, leading to one frequently seen complaint.

All the good addresses are taken!

And sometimes, to a more imaginative suggestion.

How do I get Blogger to re issue me the dormant address?

The latter question is one of futility.

Finally, the anxious blog owner may see

Checking address availability

for some time - possibly forever - if an overly ambitious cookie / script filter, or an intrusive security add-on is installed in the browser. In this case, the magical advice to

Clear cache and cookies!

or

Try a different browser!!

will be effective - though absent any attempt to diagnose the problem, one may not ever know what actual underlying problem may have caused the plaintive cry

I can't create my blog!

Read More

Remove The "Next Blog" Link From The Navbar

Ever since Blogger added the "Next Blog" link to the Blogger Navbar, blog owner and readers alike have periodically asked one question, in Blogger Help Forum: How Do I?.

How do I remove the "Next Blog" link, from the Navbar?

The "Next Blog" link, long ago added to generate random traffic for new blogs, is occasionally perceived as leading unwary readers to blogs where they should not wish to go. Some "adults" of various intention have asked this question, quite seriously, in fear of their blogs being inadvertently linked to blogs with unsavoury content.

The navbar coded as it is, there is no known ability to customise it, and to remove specific elements such as the "Next Blog" link. Generally, we simply advise people, when they have the need, to remove the Navbar.

Use the Layout wizard, Edit the "Navbar" gadget, and select "Off".

That noted, it is possible to remove the "Next Blog" link (and all buttons and links to its left), with a bit of CSS - for blogs with the owner able and comfortable with using the Template Designer. For a simple way to remove the "Next Blog" link, use the "Add CSS" menu option in the Template Designer, and add one snippet of code.

#navbar-iframe {
margin-left:-510px;
}

When you do this, you will lose 5 other buttons and links.

• The dashboard icon.
• The Blog Search window.
• The "G+ Share" icon.
• The share count display.
• The multi-function share / "Report Abuse" menu.

So hackers / spammers will appreciate the last menu being unavailable, on their blogs.

You may see this tweak demonstrated, in my New Template Laboratory. It's an ugly solution - but for blog owners who truly don't want their blogs linking to "Next Blog", it may be useful.

Read More

Adding The Domain Ownership Verification "CNAME", For A Non Root Virtual Host

Now that the new required custom domain publishing ownership verification feature has been out for several months, we are seeing it used in domains with multiple virtual hosts. A few blog owners are even publishing their blogs to non root virtual hosts - and here we are seeing a new reason for a persistent Error 12 / 32, which just can't be solved.

I have followed all of the instructions, and I am still seeing Error 12. Help!

The "Advanced settings" Error 12 instructions - now provided on screen instead of requiring the blog owner to open an external "Settings instructions" document - require careful examination.

We have to look very closely at this variation on the publishing instructions, when publishing to a non root virtual host.

Advanced settings

http://www.blog.mydomain.com

We have not been able to verify your authority to this domain. Error 12.
On your domain registrar's website, locate your Domain Name System (DNS) settings and enter the following CNAMEs:

  Name, Label, or Host field    Destination, Target, or Points To field

  www                           ghs.google.com

  xxxxxxxxxxxx               gv-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.domainverify.googlehosted.com.

See our detailed instructions on providing CNAMEs for various registrars or see the full settings instructions for more details.

Taking these instructions at face value, and adding a "CNAME" record of relative Name value "xxxxxxxxxxxx" to verify the publishing address of "www", the blog owner is going to continue to see an "Error 12" or "Error 32" for a long time.

We have to look, very carefully, at the "Advanced settings" publishing address - in this case

www.blog.mydomain.com

In the registrar's Zone Editor (aka "Domain Manager" wizard), we see the Name value entered as an address relative to the domain root.

• With "www" entered for the Name, this provides a published address of "www.mydomain.com".
• With "www.blog" entered, this provides a published address of "www.blog.mydomain.com".

The Name value, for both "CNAME"s, as specified in the "Advanced settings" instructions, is relative to the domain root.

• A Name of "www", to provide a published address of "www.blog.mydomain.com", should be entered as "www.blog" in the Zone Editor.
• Similarly, a Name of "xxxxxxxxxxxx", to provide a published address of "www.blog.mydomain.com", should be entered as "xxxxxxxxxxxx.blog" in the Zone Editor.

Entering the domain ownership verification "CNAME" relative to the published URL allows non root virtual hosts to be used, in the domain, without chance of conflict.

• To publish to "blog.mydomain.com", we add a domain ownership verification "CNAME" of "xxxxxxxxxxxx.mydomain.com" (with the proper value of "xxxxxxxxxxxx").
• To publish to "www.mydomain.com", we add a domain ownership verification "CNAME" of "xxxxxxxxxxxx.mydomain.com" (with the proper value of "xxxxxxxxxxxx").
• To publish to "www.blog.mydomain.com", we add a domain ownership verification "CNAME" of "xxxxxxxxxxxx.blog.mydomain.com" (with the proper value of "xxxxxxxxxxxx").

We simply have to read the "Advanced settings" instructions, and enter the Name values in the Zone Editor, considering the context of the instructions.

Read More

Troubleshooting Your Custom Domain Problems

Of the many accessories and features in Blogger, Custom Domain Publishing is possibly the most problematic. Looking at the Labels index in this blog, I see the Custom Domains label on 283 posts (as of 2012/11/29) - which makes it one of the most heavily labeled single topics here. There are several challenges with diagnosing and resolving a custom domain problem.

• It has various different causes.
• It leads to many different symptoms, which can easily be confused for other problems.
• Its symptoms can be chronic or intermittent- and may be immediate, or may take months to exhibit themselves.
• It may require resolution by any blog guest, by the blog owner, by Blogger Support, and / or by a third party such as the domain registrar.

---

As you read this article, click on some of the many links in the text, and read the linked articles. Please think of this article as the first chapter in a very large book - in this case a book with 283 chapters.

---

How To Use This Guide

• Always start properly, with righteous DNS addresses.
• Verify DNS addresses, using Dig. If any doubt about Dig results, compare logs from multiple Dig utilities, including a Dig against the authoritative domain server. Possibly 90% of all custom domain problems are caused, directly or indirectly, by spurious DNS addresses.
• If examination of multiple Dig logs shows righteous DNS addresses, look at HTTP traces against the BlogSpot and domain URLs.
• If neither Dig nor HTTP traces provide a definitive diagnosis, consider that you have internal database corruption.
• As you diagnose your DNS setup, only look at "A" and "CNAME" records.
• As you diagnose and / or fix the problem, do not delete the Google Apps administrative desktop account.

These are the known custom domain publishing diagnoses. Here's a brief, one line summary of the problems, which are discussed, in some detail, farther below. Click on any one, if it looks promising, to jump to the detail discussion.

• Domain Purchase Unsuccessful
• Only Name Registration Purchased, No DNS Hosting
• Domain Addresses Not Defined
• Domain Ownership Not Verified
• Non Google DNS server Part Of Configuration
• Domain Addresses Not Properly Chosen
• Domain Previously Registered, And Used In Blogger
• Domain Registration Expired
• Blog Published To Domain, Using Mixed Case URL
• Domain Redirected To Google Ad Services, Sites, or Start Page URL
• Domain Published, Partially
• Internal Blogger Database Corruption
• The Blog And Domain Are In Transition

Domain Purchase Unsuccessful

• The domain will not be setup. The blog may, or may not, be published to the domain.
• This will follow use of "Buy a domain".
• The primary symptoms will vary. We see both "404 Not Found", and "Another blog is already hosted at this address", fairly common for this problem.
• This will be an issue for newly purchased domains.
• It will be diagnosed by use of the WhoIs log showing "xxxxxxx.xxx appears to be available", and verified by examination of the Google Checkout logs, and bank account ledger entries.
• The blog owner generally has to correct a problem with his bank account, then repeat the purchase of the domain.

Only Name Registration Purchased, No DNS Hosting

• The domain will not be setup, nor the blog published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom will be the query "What are the DNS servers for Google?", "I need 2 IP addresses for my domain!", or "I can only change NameServer1, NameServer2 in my domain setup!".
• This will be an issue for newly purchased domains.
• It will be diagnosed by the stated symptom, with the blogger confirming the diagnosis by checking the registrar's invoice to see what services were paid for.
• The blogger will have to arrange for DNS hosting - free or paid - but choose the right DNS hosting service. A free third party DNS hosting service may be useful, in this case.

Domain Addresses Not Defined

• The blog will not be successfully published to the domain.
• This will follow domain registration using "Buy a domain".
• The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
• This will occur for new custom domains.
• It will be diagnosed using an excerpted Dig log, for both domain URLs.
• Here, the blogger will be advised to contact Google Apps Support, for any domain purchase issues.

Domain Ownership Not Verified

• The blog will not be successfully published to the domain.
• The primary symptom will be an "Error 12" or variant (we have observed "Error 12", "Error 13", "Error 14", and "Error 32", in reported various forum topics), when using the the Settings - Basic - Publishing wizard.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• This will occur for new custom domains - as well as for mature domain being re published.
• This will be diagnosed using an excerpted Dig log, for both domain URLs. Base DNS addresses should also be verified, to ensure a righteous setup.
• The blog owner will be advised to add or verify presence of the proper domain ownership verification "CNAME". This may involve adding an updated "CNAME", and / or carefully examining the format of the "CNAME", as entered in the "Zone Edit" registrar display. Some blog owners may need to use a free third party DNS hosting service, to allow for registrars who cannot support the necessary "CNAME".

Non Google DNS server Part Of Configuration

• The blog may, or may not, be successfully published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom may be "Another blog is already hosted at this address" (for new custom domains, in the Settings - Basic - Publishing display), or conversely "404 Not Found" (for long existing custom domains, when viewing the blog). The symptoms will be observed intermittently, when the non Google server is referenced.
• Possible secondary symptoms:
  • Blog feeds, intermittently not redirected from the native BlogSpot URL.
  • Commenting problems.
• It will be diagnosed using an excerpted Dig log, for the domain root.
• It is typically resolved by a 4 step process. For best results, follow this procedure religiously.
  1. Publish the blog back to BlogSpot.
  2. Correct the DNS addresses.
  3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
  4. Republish to the domain URL.

Domain Addresses Not Properly Chosen

• The blog may, or may not, be successfully published to the domain.
• This will follow domain registration, purchased from a third party registrar.
• The primary symptom may be "Another blog is already hosted at this address" (for new custom domains, in the Settings - Basic - Publishing display), or conversely "404 Not Found" (for long existing custom domains, when viewing the blog).
• Possible secondary symptoms:
  • Blog feeds, unreliably redirected from the native BlogSpot URL.
  • Commenting problems.
• It will be diagnosed using an excerpted Dig log, for both domain URLs.
• It is typically resolved by a 4 step process. For best results, follow this procedure religiously.
  1. Publish the blog back to BlogSpot.
  2. Correct the DNS addresses.
  3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
  4. Republish to the domain URL.

Domain Previously Registered, And Used In Blogger

• A Blogger blog was successfully published to the domain, at one time - by a different person. It is now not successfully published.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "Another blog ...", when attempting to publish / re publish the blog to the domain.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs.
• It will be resolved using the Custom Domain Reset form - and much patience by the current domain owner.

Domain Registration Expired

• The blog was successfully published to the domain, at one time.
• This may follow domain registration, long ago purchased from a third party registrar, or using "Buy a domain".
• The primary symptom may be unexpected content, displayed by the blog. The nature of the unexpected content will vary.
  1. In most cases, and when the blog owner is lucky, the domain will be dead, or maybe display a page of ads or an "Offsite Warning" interstitial display.
  2. In rare cases, and when the blog owner is not lucky, the blog will display contents of another blog, another website, or an "Offsite Warning" interstitial display.
• It will be diagnosed using a WhoIs log, which shows expiry and last update dates, for the domain.
• There are two possible resolutions (see two primary symptoms, above, for possible variants).
  1. With the blog owner being lucky, it is in the control of the registrar. After domain registration is renewed, the problem is resolved by the 4 step process. For best results, follow this procedure religiously.
     1. Publish the blog back to BlogSpot.
     2. If necessary (and possible), contact the registrar, and renew the registration. Then, correct the DNS addresses.
     3. Wait for the DNS latency period to expire. This is important. Failure to consider DNS latency may later lead to Internal Database Corruption. This period will vary, as a result of the TTL setting in the "A" / "CNAME" referral.
     4. Republish to the domain URL.
  2. If the blog owner was not lucky, the domain may now be in the hand of an unknown party. This will be a subject for another article.

Blog Published To Domain, Using Mixed Case URL

• The blog will be successfully published to the domain, but will not be visible from either BlogSpot or domain URLs.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be a "404 Not Found", when attempting to view the blog using either the BlogSpot or domain URLs.
• This will, typically, occur for new custom domains, immediately after the end of the 3 Day Transition Period.
• It will be diagnosed using a RexSwain HTTP Trace, starting from the BlogSpot URL.
• It is typically resolved by publishing the blog back to BlogSpot, then re publishing to the correct URL, using all lower case letters.

Domain Redirected To Google Ad Services, Sites, or Start Page URL

• The blog will not be successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
• This will typically occur for new custom domains.
• It will be diagnosed using a RexSwain HTTP Trace, starting from either domain URL.
• It is typically resolved by deactivating or resetting the Ad Services, Sites, or Start Page service, using Google Apps.

Blog Published Partially, To The Custom Domain URL

• The blog will appear successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "404 Not Found", when viewing the blog using one of the domain URLs - and the blog will still be published to the BlogSpot URL.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs. If each of the above diagnoses are eliminated, one by one, and "404 Not Found" is still observed, internal database corruption is the only remaining possibility.
• It is typically resolved by re publishing the blog to the domain. This symptom may mask a Service Redirect, or Internal Database Corruption.
• As you diagnose the problem, re publish the blog to the domain, and / or recycle the domain settings, please do not delete the Apps desktop account.

Internal Blogger Database Corruption

• The blog will not be successfully published to the domain.
• This may follow domain registration, purchased from a third party registrar, or using "Buy a domain".
• The primary symptom will be "Another blog is already hosted at this address", in the Settings - Basic - Publishing display.
• It will be diagnosed using an excerpted Dig log, for both domain URLs. If the above diagnoses are all eliminated, one by one, and "Another blog ..." is still observed, database corruption is the only remaining possibility.
• It is typically resolved by recycling the domain settings in Google Apps, and / or use of the Custom Domain Reset form.
• As you diagnose the problem and / or recycle the domain settings, please do not delete the Apps desktop account.

The Blog And Domain Are In Transition

• The domain will be setup - but will not redirect. The blog will be published to the domain URL.
• This will follow use of "Buy a domain".
• The primary symptom will be seen only by the owner (when properly logged in to Blogger). When clicking on the "View Blog" dashboard button / link, the owner will see an "In Transition" display.
• This will be a temporary issue, for newly purchased domains, successful purchased.
• It will be diagnosed using an excerpted Dig log, for the BlogSpot, and both domain, URLs.
• It will go away, when Transition expires, 72 to 96 hours after successful domain purchase and registration. The blog, and the domain, will then redirect properly.
• While you wait for Transition to expire, spend time reading what you will want to do, when Transition is complete.

---

And if it's not too late, read Setting Up A Custom Domain, before you start.

---

Read More

Troubleshooting Custom Domain Issues

If you are trying to make your custom domain published blog work, see my guide Troubleshooting Your Custom Domain Problems.

If you want to know how to setup a custom domain properly, from the beginning - and avoid the need for Troubleshooting - read Setting Up A Custom Domain. Avoid the most basic mistakes made - read The Simplicity Of A Custom Domain Setup.

If you just setup your custom domain - and want to minimise the effects of the URL change upon your search engine relationships - read Managing The Migration.

If you're just browsing, then read on - but get a good cup of coffee first. And welcome, to Nitecruzr Dot Net.

Read More

Stats And The "Don't track ..." Option, Used With Multiple Browsers And Shared Computers

The controversial nature of Stats and the "Don't track ..." option, which requires a third party cookie to enable the option to work, continues. Even with all possible cookie filter properly set, and a consistent cookie clearing policy established, some blog owners persist in reporting that there are problems with Stats inconsistently observing the setting to not track their pageviews.

Not all blog owners realise that the Stats "Don't track ..." cookie is unique to each different browser - except when cookies are shared between computers. Some browsers use cookies which are maintained as part of the personal profile, on the local computer - and some people may have cookies which are shared between multiple computers.

• Computers which are shared by multiple people may have multiple sets of cookies.
• Computers which are part of a local network may have a single set of cookies, per person, shared across multiple computers.
• Some blog owners may use multiple Blogger accounts.

Each of these possibilities will create differing cases where the Stats "Don't track ..." cookie, like other cookies, may or may not be present when a given person is surfing to the blog in question - and which will cause Blogger to count (or to not count) pageviews from the browser being used.

Some computers are owned by, and used by, multiple people. The operating system will encourage each different person to maintain her / his own settings and styles, and to identify herself / himself when starting the computer. The settings and styles are maintained in a personal profile - and most browsers maintain the cookies as part of the personal profile. If two people, who share a computer, also share a blog, each person will have to select "Don't track ..." consistently - or face having inconsistent counting of pageviews, when reading the blog.

Some local networks, where various computers are shared and used locally, may use profiles which are maintained in common between the various computers. Changes to the profile (including cookies), made on one computer, may transfer to other computers. Clearing or setting cookies on one computer may affect presence of the same cookies, on another computer - and may again cause inconsistent counting of pageviews, against blogs involved.

Some blog owners may use multiple Blogger accounts. Similar to the issue of blogs shared by different people / used on shared computers, blogs read on computers used by people with multiple Blogger accounts will have the "Don't track ..." cookie present, irregularly. This, too, will cause inconsistent counting of pageviews.

Finally, as noted, clearing of cookies will affect presence of the "Don't track ..." cookie - and will cause unexpected counting of pageviews. This inconsistency will be more common with computers shared by multiple owners, and with computers shared across a local network.

Many blog owners use only one browser, and one computer - and own and use their own computer, exclusively. Any blog owner, noting inconsistent effectiveness of the "Don't track ..." option, however, may do well to at least consider the above issues, occasionally.

Read More

Blog Readers Report Inability To Remove Blogs From Their Reading Lists

We're seeing an occasional report, in Blogger Help Forum: Something Is Broken, about inability to manage the Reading List, using the dashboard "Manage Blogs I'm Following" wizard. Clicking on the dashboard "gear" icon to the right of "Reading List", one should expect to see a list of Followed blogs, in the familiar menu. In some cases, what is seen will be bad news.

We are unable to load your FriendConnect data at this time. We apologize for the inconvenience. Please try again shortly.

Upon trying again, the same error is seen, repeatedly. Some frustrated blog owners report that the problem has affected them, for some time.

This has been an issue for months. I need to be able to remove blogs I no longer wish to Follow - especially those which do not have a Friend Connect gadget.

This is not a heavily reported problem - but the blog Followers who cannot remove blogs, especially when faced with spam in the unwanted blogs - will not see this as a minor problem. This problem has been reported to Blogger Support - but with the low volume of reports containing any useful detail, it's not going to get a lot of immediate attention.

We have a rollup discussion where we are asking for detail - which hopefully will be monitored by Blogger Support, as detail is provided. If you are affected by this problem, please provide as much detail as you are able, using the guidelines provided there.

Read More

Anonymity, Your BirthDate, And Your New Blogger / Google Account

Not all new Blogger blog owners understand why they are asked for their birthdate, when they setup a Blogger or Google account. Some folks see this as a violation of their right to privacy, and enter a fake birthdate. Some real serious privacy enthusiasts might enter "01/01/01", just to get through the setup process - maybe intending to correct it, later.

Nobody entering "01/01/01", for one's birthdate, suspects that claiming such a birthdate makes them - in 2013 - appear to be 12 years of age. Unfortunately, 12 years is below the minimum age for owning a Blogger blog. Since Blogger / Google tries to protect the young people on the Internet from inadvertently exposing themselves - or their families or friends - to unknown dangers, people who may appear to be of insufficient age are subject to having their Blogger / Google accounts, and Blogger blogs, deleted or locked.

If you entered a fake birthdate some time ago, and now find your account or blog locked or deleted, you need to prove your age to Google - and you should do this promptly. The Google Accounts document Frequently Asked Questions about Google Account and Age Requirements explains how you do this. The process of verifying your age / birthdate is not convenient - and some privacy enthusiasts may claim that it too violates their privacy rights - but it is necessary, to let you correct your birthdate - when you are legitimately of legal age.

Now, you have to hope that you did not, intentionally or mistakenly, also provide a bogus email account as your Blogger / Google account name / recovery email address. The process of identifying yourself as the owner (former, nominally underage) of a given Blogger / Google account is easier to do, when you have access to the email account stated as the account recovery email address.

Read More

Stats Pageview Counts Fluctuate Daily, Just Not At Midnight

One of the many controversial issues about Stats involves the daily pageview counts, which are reset daily. Most blog owners accept the daily count reset, in principle - they just don't understand why the counts should be reset during their day, instead of at midnight.

My pageview count goes up during the day - but in the afternoon, it goes to zero, then starts over again. Why is Stats so unreliable?

The pageview count reset would be better understood, were it to happen daily, at midnight, for each blog owner. Unfortunately, there are over 24 different time zones, worldwide - and Blogger blogs are surely owned by somebody in all time zones represented.

There are 24 time zones which roughly follow longitudinal lines - plus specific countries which have their own national clocks. India, for instance, spans 3 time zones, geographically - but observes one time zone, offset by 30 minutes, as "GMT+5.5". WikiPedia identifies a total of 40 time zones.

Many countries observe a seasonal variation, "Daylight Savings Time", when they move the clock ahead or behind, by an hour. DST beginning and ending date varies by country, irregularly.

If the daily Stats pageview count reset were to be scheduled according to the local clock of the blog owner (which would be impossible, for all multi owner blogs), there would have to be as many reset process schedules as there are countries in the world. Additionally, twice a year, most processes schedules would be shifted, according to the local DST offset.

Considering the almost inestimable number of rules required to schedule a local midnight count reset for all Blogger blogs, during the entire year, I suspect that the only practical design involves scheduling the reset, for all blogs, at midnight GMT. This means that no blog owners will see their pageview counts reset at midnight, during the entire year. Everybody simply has to accept their count being reset sometime during their day - with the reset time varying according to the twice a year local clock shift.

Read More

We Are At The Mercy Of Every Anti-Malware Protection Program Imaginable

We see reports, from time to time, in Blogger Help Forum: Something Is Broken, about blogs which people can't read, from their computers.

One of my readers claims that I have a virus on my blog. He provided the following information:

AVG anti-virus detected the following threat on the site:

File Name: www.mydomain.com/favicon.ico

Threatname: Exploit Black Hole Exploit Kit

How do I fix this?

Similar to the many reports that we process here, about spurious spam classification, the above report is frequently determined to be a false positive. An anti-virus alert, even if a false positive, is generally not as simple to resolve as a spurious Blogger spam classification, though.

One of the frustrating problems with false malware alerts is that they come from so many different anti-malware products. I've contributed my opinion about computers, and the suggestion that no two privately owned computers are identical, many times. One way which many computers vary is the complement of security software, which is chosen by each different computer owner.

At any time, any different anti-malware product may decide that some component of your blog is unsafe.

• Maybe, a single file mentioned in your blog code (as above, "favicon.ico") is suspect.
• Maybe, content hosted by "blogspot.com" is unsafe.
• The code may be an accessory that we added, intentionally.
• The code may be content in another blog - hosted by your blog in a bloglist, a linklist, or maybe in the Reading List on your dashboard.

In either case, you (or your reader) won't be allowed to view the blog - or may be allowed to view the blog, but given a stern warning which very few chose to accept.

Like many problems with layered security, the malware alert can come from

• A native browser filter.
• A filter in a browser add-on.
• A filter installed on the computer.
• A filter in a network appliance.

Listen to your computer. some time. Your anti-virus protection may update automatically - and may audibly announce the update. On a typical day, I hear the Avast client on my several computers announce an update, several times - and I am not (contrary to some misconceptions) seated in front of my computer on a 24 x 7 basis.

Avast (my personally and professionally recommended choice, to many people) is only one of dozens of various anti-malware products which receives automatic updates, when the host computer is online. Any one of these products may be updated, at any time -and somebody's access to your blog (or my blog) becomes blocked.

If you get a message from one of your would be readers

I can't view your blog!

this could be someone reporting that your blog just went offline, for one reason or another - or it can be someone just discovering that the anti-malware program, on his computer, has decided that BlogSpot hosted content is unsafe. In either case, there is not a lot that you can do, except wait it out - and concentrate on the readers who can access your blog.

Read More