Custom Domains And HTTPS Redirection Code

As most of us know, Blogger HTTPS support does not include custom domain publishing.

The advantages offered by HTTPS access are widely advertised - and have led to envy between blog owners who publish to custom domains, and native BlogSpot blog owners proudly advertising their new HTTPS connectivity.

Long ago, we saw possibly malicious code which helps our readers avoid using country code aliases, to read our blogs from an aliased country. Recently, there was dodgy code which blocked HTTPS mode, to read a customised blog.

Now, we have custom code to force HTTPS access, for BlogSpot published blogs.

Along with providing code to help blog owners avoid country local domain aliasing, some marginally helpful hackers are providing code to help blog owners force reader access to HTTPS.

Some blog owners always wanted HTTPS to be used, to access their blog.

Some blog owners wanted their readers always using HTTPS to access their blogs, before forced HTTPS access became an option. They Googled, and found, semi helpful hackers who provide clever code to force the "HTTP --> HTTPS" redirection.

<script type='text/javascript'>
$(document).ready(function() {
  $("a[href^='http://']").each(
    function(){
      if(this.href.indexOf(location.hostname) == -1) {
        $(this).attr('target', '_blank');
      }
    }
  );
  $("a[href^='https://']").each
    function(){
      if(this.href.indexOf(location.hostname) == -1) {
        $(this).attr('target', '_blank');
      }
    }
  );
});
</script>

This is clever code - when only BlogSpot access is involved. When you add BlogSpot to custom domain redirection, it becomes another "404".



Adding this clever code is an excellent solution - until the blog owner forgets about it, and later upgrades to a non BlogSpot custom domain.

With a custom domain published blog, the redirection becomes a problem.

The added code contains no exception to permit custom domain published blogs to remain in HTTP mode. When accessing an otherwise properly setup custom domain published blog, from a reader using the "blogspot.com" URL, this prevents the BlogSpot to domain redirect from operating.

BlogSpot URLs, which should redirect to the HTTP published custom domain URL, instead redirect to a non existent HTTPS URL - and result in another "404". As the custom domain URL becomes more commonly used for a recently published blog, confusion increases when the rarer BlogSpot URL reference is encountered.

My blog has been using the domain URL for months, why is this happening now?

The problem involves dual redirection - to "https:" mode, and to the custom domain.

After painful problem diagnosis, we find the clever redirection code buried in template HTML - and we see that the blog reader is starting from the BlogSpot URL, and using the BlogSpot to domain redirection, to access the blog.

With blog access redirected to "https:" mode, then subsequently to the custom domain URL, the readers sees a "404" - because the custom domain URL is not available as "https:" content.

This problem will become increasingly rarer - but not extinct.

As self caused custom domain victims become rarer, this way of breaking ones own blog will become more obscure - and it's likely that some cases will go, unsolved. This will be similar to the problem of un migrated classic templates, which has increasingly less experienced support.

If you must install unsupported template tweaks into your template - consider the long term effects. Learn to recognise a problem that you have caused, to your own blog.

Not every helper will realise that you have added custom redirection code - and when looking at the problem code, when a problem is reported, will recognise it for what it is. Your problem may remain your problem - at least, until Blogger Engineering completes Blogger SSL integration (may this happen soon).

---

Some blog owners have added clever HTTP to HTTPS redirection code, acquired from helpful third party providers, installed in the template. When later publishing a blog to a custom domain, this code will prevent proper blog access - and as installed, may not be easily recognised.

https://productforums.google.com/forum/#!category-topic/blogger/bl5W39BKX4U

Read More

Revert A Page / Post To Draft Status

Sometimes, we need to remove a page or post from a blog - but prefer to not delete it.

There are various reasons for not wanting to delete a page / post immediately or permanently - maybe when removing a post for problem diagnosis, or to change the URL to match the publish date. Reverting to draft status is easily reversed, and has no permanent side effects.

When you want to quickly - but not permanently - remove a page or post, you can revert to draft status.

Reverting to draft status is convenient, safe, and simple.

You can revert a page or post using Page / Post Editor, or the Pages / Posts dashboard page.

• Revert, using the Pages / Posts dashboard pages.
• Revert, using the Page Editor / Post Editor.

Revert, using the Pages / Posts dashboard pages.

The Pages / Posts dashboard page is a menu. Simply select one or more pages or posts, then click "Revert to draft". Click on "Yes" to verify. and you're done.

Hit "Revert to draft", after selecting a page or post.



Revert, using the Page Editor / Post Editor.

Any time that you are editing a previously published page or post, click "Revert to draft". And you're done.

Hit "Revert to draft", when in page / post editor.



And when you're done, you're done.

Once a post is newly draft, it's offline. Page / post content in cache on your readers's computers will be readable until it expires. New readers, on the other hand, will see a "404" immediately.

You can recover the post with the URL - or rename to a new URL.

If you revert to draft - then later, re publish without changing the title, you will get the same post, with the same URL, back. If you change the title with the post in draft status, you get the same post content, under a new URL, when you re publish.

If you do the latter by mistake - then discover the mistake later, you can recover the mistake by merging the new and previous URLs. Just add a custom redirect from the new to old URL (or vice versa).

Review / Recover The Draft Inventory, With One Mouse Click

Any time that you need, review the inventory of Draft posts. Just click on "Draft" under "Posts". You can Edit then Publish - or just Publish, immediately.

Check out the current Draft posts complement, from Pages or Posts - Draft. Then recover one or more.

Just select one or more posts, then "Publish".

Or edit a page or post, then Publish.



Either way, you can recover any pages or posts, reverted, easily enough - as long as you revert them, instead of deleting them.

Just understand the possibilities.

---

Reverting a #Blogger blog post to draft status is a quick, yet reversible, way to take a post offline. The URL will be recovered, automatically - as long as you do not change the title.

Read More

Blogger Magic - Move Content Between Blogs

Some blog owners, who publish multiple blogs with different subjects, may decide that some subjects would be better discussed in a different blog.

With various posts published in one blog, the owner may decide that those posts should be published in a different blog, to continue discussion. The question now is how to move posts, from one blog to another?

The dashboard "Export / Import" feature, which is now labeled "Import & back up", lets us copy pages and posts from one blog to another. Just copying all pages and posts, though, will create problems with duplicated content.

If you are going to move specific posts from one blog to another - and continue to publish both blogs - you have to add extra steps to the process.

Use "Import & back up", on the Settings - Other dashboard page.

1. Export all content from the first blog.
2. Import all exported content, to the second blog, as "Imported".
3. Publish imported content, selectively, in the second blog.
4. Delete content re published, from the first blog.
5. Setup custom 404 or custom redirects, from the first blog.
6. Remove imported yet un published content, from the second blog.

Export all content from the first blog.

Using the "Import & back up" wizard, on the dashboard Settings - Other page for the first blog, click "Back up Content". This will export all pages and posts, in the blog, to the file which you select.

To make it easier, label the posts that you want to "move" to the other blog, before you start "Back up Content".

I labeled my posts "Move".

Now, "Back up Content", from the first blog.

Use the file manager provided by your operating system, to create or select a file / folder, and actually save the file.



Import all exported content, to the second blog, as "Imported".

Using the "Import & back up" wizard, on the dashboard Settings - Other page for the second blog, click "Import Content" - then find and select the file just created. This will import all pages and posts, as exported from the first blog - and place the imported pages and posts in the special "Imported" status, on the Pages and the Posts dashboard pages.

Continue with "Import Content", to the second blog.

Select the file that you just created, above.

And having Imported everything, there are the posts - including those labeled "Move".



Publish imported content, selectively, in the second blog.

Using the "Pages" and "Posts" dashboard pages, select the newly activated "Imported" menu, as you wish. This will list all imported pages and posts, in turn.

Find the pages and posts that you want moved, select them, and click "Publish". If you labeled the posts to be "moved", simply display, and Publish, all posts with the designated label.

And, I Published the posts labeled to be "moved".



Note that, once Published, the "Imported" status is cleared.

Delete or revert content re published, from the first blog.

To prevent problems with search engines detecting duplicate content, you can delete or revert to draft status, each post in the first blog, the you just re published in the second blog. If you revert to draft status, you will have backed up content and a recoverable page / post URL.

Again, if you labeled the posts, you can delete or revert posts using the label.

Setup custom 404 or custom redirects, from the first blog.

You cannot use a custom redirect to automatically redirect from the first blog to the second. You can, however, setup a custom 404 page, in the first blog - or make custom redirects to a custom 404 page, in the first blog - advising the reader that the post just requested is now part of the second blog.

The reader will still have to intentionally click to jump into the second blog - but until Blogger blogs are not used as spam hosts, this will be necessary to avoid making your blog look like a spam host.

And as noted, please don't use this technique to re use a single blog. Duplication prevention will generate suffixed URLs, for pages and posts exported then imported to the same blog.

Remove imported yet un published content, from the second blog.

As a type of basic hygiene, once all of the posts are moved ("published"), remove all imported content that isn't published. If you ever repeat the exercise, you won't enjoy the duplicated content, that you will have to identify, from having Exported then Imported, twice.

---

The "Import & back up" #Blogger dashboard wizard can be used to copy pages and posts, from one blog to another. Actually moving content requires more than just exporting from one blog, and importing to a second blog.



http://blogging.nitecruzr.net/2016/06/blogger-magic-export-from-blogger-blog.html

https://productforums.google.com/forum/#!category-topic/blogger/hJ-WrGwnIFo

Read More

Act Immediately, When Invited

Some moments come fleetingly, and never again.

One such moment may be, when you receive a blog membership invitation.

The purpose of this message is to inform you that xxxxxxx has invited you to join their private blog "xxxxx xxxxx". To accept this invitation, click on the button below.

or

The purpose of this message is to inform you that yyyyyyy has invited you to contribute to their blog "yyyyy yyyyy". To accept this invitation, click on the button below.

Unless you know the blog owner, this may be your one chance.

If you get an invitation to be a designated reader on a private blog - or an author on either a private or team blog - decide, and act as soon as possible.

Any invitation that you get will be temporary. Blog membership invitations expire, after a fixed amount of time.

Accept the invitation, to view and note the URL.

If the blog is private, and you accept the invitation as a reader, make a note of the URL too.

Long ago, you might get a "preview link" in the invitation - allowing you to view the blog, and bookmark / copy the URL for later. The "preview link" feature was abused by too many owners - and appears to be gone now.

No preview = no URL until after you accept the invitation.

Become an author, on a team blog!

Become a reader, on a private blog!



There's a limited amount of detail, in the invitation.

How useful is either invitation, if you don't accept, when viewed later? You can get the owner name (as provided by the owner), and the blog title - and that's it.

• Invitations contain only the author name, the blog title, and a membership token.
• A reader invitation, for a private blog, may not produce an entry in the dashboard "My blogs" list.
• Both author and reader invitations will expire.

Act promptly, for best result.

If you get an invitation, and you file it away so you can "think about it", don't think about it too long.

Once the token expires - and if you don't know the owner - you'll not be able to contact the owner. And until you accept the invitation - and actually view then bookmark the blog - you won't find out the URL.

Act quickly - or never.

---

If you get an invitation to be an author on a private or team #Blogger blog, or a reader on a private blog, act promptly. Invitations expire too soon - they contain few details - and won't be very useful later.

https://productforums.google.com/forum/#!category-topic/blogger/z-lKeqO-ssA

Read More

Blogger Magic - Adding Label Search URLs

One of the simplest ways to make a blog useful is to add label searches.

Adding label searches, in page / post text, is not easy - unless you know how to build the URLs. Here's a label search from this blog.

http://blogging.nitecruzr.net/search/label/Blogger%20Magic

All that I want, when using that label search, is to add another reference to my "Blogger Magic" post series.

"Blogger Magic" emphasises how easy it is, to use Blogger. How easy is it, to remember that syntax - to add a label link? Maybe, a "Blogger Magic" reference, in this post?

When you read a blog post, that has label references, look at the bottom of the post.

---

Please note the advice, at the bottom of the post.

---

Look in the post footer, for the "Labels" section.

Here's the bottom of another post, from this blog.

Here's the bottom of this post.



Note that not all blogs will provide a "Labels" posts section. That is an owner choice.

Look at a label link, in the "Labels" section of the post - when provided.

There's the bottom of two of my "Label Search" posts - "Blogger Magic - A Blog Within A Blog", followed by this post "Blogger Magic - Adding Label Search URLs". Now, look at the Labels links.

In most blogs, the Labels links would be labeled "Labels". I call mine "Topics". As owner of this blog, that is my personal choice.

Also, in most blogs, the "Labels" section will be found, in the post footer. Some blog owners have chosen to position their "Labels" in the post header. This, too, is their choice - and carries with it, some risk.

See "Label Search"?



Look in the browser status area, when hovering over the link caption.

Look at the "Topics" section. See "Label Search"? Hover the mouse cursor, over the "Label Search" link.

See the label search URL, in the browser status area?



Look in the browser status area, when hovering over the link caption.

Hover the mouse over "Label Search", and look in the browser status area.

blogging.nitecruzr.net/search/label/Label Search

For a blog using an HTTPS redirect, you might see a slightly different URL.

If this blog uses the "HTTPS: Redirect" option, you might see it slightly differently.

https://blogging.nitecruzr.net/search/label/Label%20Search

Click on either of the above 2 links. OK, I cheated with the second link - since this blog, right now, does not support HTTPS - and I obviously don't want you looking at an HTTPS Error display.

Whether HTTP - or HTTPS - is in use, there is the label search link.

Whichever you see - and decide to use - with your blog, there is a label search URL. Now, get a label search URL from your blog - and use the URL, in another page or post in your blog.

This post opens many links in new tabs / windows, intentionally.

BTW - and if you have clicked on any of the links above - and since you have apparently read to this point - I have to warn you that many of the links, above, are intentionally coded to open in a new tab / window. That is necessary, based on the nature of the links in this post.

Many of the links in this post are clickable, simply to illustrate to you the content in label searches - as opposed to links which lead you to additional information in the blog. So as not to lead you away from this post, you should not lose context after clicking on a link - as long as you simply close the new (illustrative) tab / window.

My sincere apologies, if my seemingly gratuitous opening of new tabs / windows inconveniences or offends you.

---

Some #Blogger blog owners want to use label search URLs, in page or post text. Getting a label search URL is easy enough, when you look in the post label search section - which is generally in the post footer.

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 DNS Addresses For Custom Domains. 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

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 363 posts (as of 2015/06/15) - 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 - right now, a book with 363 chapters.

---

How To Use This Guide

• Always start properly, with properly setup 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 properly setup 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
• Blog Published To Domain Root, With Asymmetrical DNS
• 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
• All Issues May Not Be Discussed Here

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 addresses are properly 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 set, 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.

Blog Published To Domain Root, But Asymmetrical DNS Used

• 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" - though "Buy a domain" will be far more commonly seen.
• The primary symptom will be a "404 Not Found", when attempting to view the blog using either the BlogSpot or domain URLs - or the warning "Blogs may not be hosted at naked domains." or "Another blog or Google Site is already using this address.", when trying to publish or re publish the blog to the domain.
• This will, typically, occur for new custom domains.
• It will be diagnosed using a RexSwain HTTP Trace set, starting from the BlogSpot URL, and confirmed with a screen print of the Publishing wizard display, taken as the blog owner sees the error message in question.
• It is typically resolved by publishing to the "www" alias.

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 or Google Site ..." / "Key already exists ..." / "code CONFLICT" (or a similar phrasing), in the Settings - Basic - Publishing display, when attempting to publish or re publish a blog to the domain.
• 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. The latter symptom, "code CONFLICT", is unique to domains purchased using Google Domains - and can be resolved by use of their domain dashboard.
• 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.

All Issues May Not Be Yet Discussed Here
You could, occasionally, have a problem which is not diagnosed in this Guide - and in that case, please ask for help, politely, in Blogger Help Forum: Something Is Broken.

Before asking for help, you can help the helpers if you have tried some affinity diagnostics or maybe some differential diagnostics - and if you are aware that not all problems may be exclusively caused by Blogger. And have some idea how many possibilities exist, for problems.

---

And if it's not too late, read Blogger Magic - How To Setup A Custom Domain, and Setting Up DNS Addresses For Custom Domains, before you start.

Read More

"Delete permanently" Means Delete, Permanently

For a long time, blog owners have been requiring the ability to delete their blogs.

In the beginning, people would delete a blog - whether intentionally or mistakenly - then change their mind, or realise their mistake.

I did not really want to delete my blog.

And the inevitable question.

How do I get my very important blog back? Surely, it's in your computer somewhere??

But this question was not always answered, with encouragement.

Too often, Blogger Support would be forced to give the bad news.

You deleted it, and it's gone.

Blogger added the "Deleted blogs" dashboard list.

Eventually, Blogger Support tired of providing negative answers - and Blogger Engineers added the "Deleted blogs" display, to the dashboard.

A blog, deleted by the owner, and listed under "Deleted blogs", can be recovered by the owner, when desired - up to 90 days from deletion. Unfortunately, the dashboard "Deleted blogs" list was not the final solution.

Some blog owners did not want a deleted blog listed, under "Deleted blogs".

Some people would delete a blog - then sometime later, learn that the blog was not really deleted.

I deleted my blog - but now I see it listed, under "Deleted blogs". How do I delete my blog, so it does not exist?

And the answer.

Wait 90 days - and it will be removed.

But that answer did not always satisfy.

I can't wait 90 days - I want it deleted, now!

And for that requirement, there was no answer.

Blogger recently added the "Remove permanently" option.

Recently, Blogger added the "Delete permanently" option, to the dashboard "Deleted blogs" list. Now, a deleted blog can be removed immediately, at the discretion of the blog owner.

• A blog, when deleted, goes offline - and is moved to the "Deleted blogs" list.
• If the owner wants the blog restored, he can use "Restore blog".
• If the owner wants the blog gone, he can use "Delete permanently".

And, as noted in Blogger Help: Back up, import, or delete your blog

• When you delete a blog: you have a short period of time to restore it if you change your mind.
• When you permanently delete a blog: all of your blog information, posts, and pages will be deleted, and you won’t be able to restore them.

And one additional advice.

Note: After a blog is permanently deleted, the blog’s URL cannot be used again.

The "Delete permanently" option can't be reversed.

The option "Delete permanently" has final and immediate results.

• The blog is removed from "Deleted blogs".
• The blog contents cannot be restored.
• The URL can never be re used.

In the words of the philosopher,

He's dead, Jim.

End of story.

Let's examine the deletion sequence.

Here's my dashboard home page - showing my test blog, awaiting deletion. Compare this display, with my test blog, deleted.

Here's my test blog - "Delete Blog Test".

Go to the dashboard Settings - Other page, and click on "Delete blog".

There is the "Delete blog" wizard - and a chance to "Download Blog".

So, click on "Delete This Blog".

And, it's deleted. But what does that really mean?



Here's my dashboard home page - showing my test blog, deleted. Compare this display, with my test blog, awaiting deletion.

Now, we see "Deleted blogs" has 1 entry.

And there is my test blog listed, with two choices - "Permanently delete" or "Undelete".

Unfortunately, "Undelete" won't work, for me.



We do get an on screen warning, before permanent deletion.

We do get a warning, before deletion. "Deleting Nitecruzr Delete Blog Test is permanent and you won't be able to undo it"

---

A #Blogger blog, once deleted, can be restored within 90 days - if "Delete permanently" is not used. Once "Delete permanently" is used, the blog and all content is gone - and the URL can never be used, again.

Read More

The Mysterious "Destination" / "Points To" Label

Some blog owners buy domains, for publishing a Blogger blog, and ask about how to address the domain.

What address do I use for "Points to"?

Other owners may ask a similar question, referencing "Destination" or maybe "Target".

There is no real difference, between all 3 labels. "Destination", "Target", and "Points to" all refer to the same DNS address value.

To compound the confusion, 4 different addresses are required, when addressing a Blogger custom domain root.

Defining the DNS servers used by the domain root ("naked domain") requires 4 address records - and the labels used, in the zone editor, will vary from registrar to registrar.

We know of 3 different labels, used by Blogger custom domain instructions.

The referential Blogger document How do I use a custom domain name for my blog? uses 3 labels to identify the 4 name servers, which are provided by Google. Blogger uses the triplet label "Destination, Target, or Points to" as their example.

Google provides 4 name servers, to give us multiple redundancy.

Google provides four mutually redundant individual servers, each responding to a specific IP address - for custom domain clients to address the domain root, in a round robin sequence.

There are 4 name servers provided by Blogger, to address a custom domain root.



Each domain root name server entry uses 2 important label values ("Name, Label, or Host" - and "Destination, Target, or Points to").

Each label may have 1 of 3 values, depending upon the zone editor provided by the registrar.

Here is the Dig Log, for the domain root. Look at the 2, 4, 6, and 8, in the 4 address entries.

mydomain.com. 3600 IN A 216.239.32.21
mydomain.com. 3600 IN A 216.239.34.21
mydomain.com. 3600 IN A 216.239.36.21
mydomain.com. 3600 IN A 216.239.38.21

In the GoDaddy zone editor, you'll see these entries depicted as

  Host   Points to           TTL
  @      216.239.32.21    1 Hour
  @      216.239.34.21    1 Hour
  @      216.239.36.21    1 Hour
  @      216.239.38.21    1 Hour

The GoDaddy zone editor uses the labels "Host" and "Points to".

Similar labels ("Name", "Label" and "Destination", "Target") are used by various other registrars, in their own zone editor.

A Zone Editor display, showing the base DNS addresses, for GoDaddy.

Here is the display, used by GoDaddy, for "nitecruzr.co.uk".


Here is the zone editor display, as provided by GoDaddy.

Do you see the 4 address records, beneath "Points to"?



The labels in the address records differ, from registrar to registrar. The "Name, Label, or Host" address values (here, shown as "@") will differ, from registrar to registrar - but the "Destination, Target, or Points to" address values will not differ. A properly addressed domain will have the same 4 "Destination, Target, or Points to" address values, as every other properly addressed domain.

mydomain.com. 3600 IN A 216.239.3n.21

Each address will have one of four values for n: 2, 4, 6, or 8.

Complementing "Destination, Target, or Points to", we have another label set.

Complementing the 3 "Destination, Target, or Points to" label address values, for addressing the 4 name servers provided by Google, we have a similar set of 3 "Name, Label, or Host" label address values.

Addressing "Name, Label, or Host" is somewhat simpler - as all 4 entries are identical to each other, for any domain root address entry.

The Blogger instructions, like the GoDaddy zone editor, use "@", when addressing the domain root. The zone editor value used, however, may differ from registrar to registrar.

Any blog owner, wishing to have a working custom domain, needs to understand how to setup a domain for the registrar involved.

The end result.

Both the "Name, Label, or Host" - and the "Destination, Target, or Points to" - label triplets are only examples. Other unidentified registrars may use other labels.

Considering the Blogger instructions, and the terminology required, Blogger Help Forum: Get Help with an Issue will not soon run out of blog owners, requesting assistance for making their custom domains work.

---

Some #Blogger blog owners, in the process of setting up their blogs using custom domain publishing, find that labels "Name", "Label", or "Host" - and "Destination", "Points to", or "Target" - are only examples, in the Blogger Help document.

There is no attempt at standardisation, used by the thousands of different Internet registrars, in their dashboards (aka "zone editors").




https://productforums.google.com/forum/#!category-topic/blogger/kMDo0O1xtDM

Read More

Reader Zoom Level Affects Screen Space Needed

I have suggested that properly sizing the Jump Break and Title sections of each post is an important decision, when publishing a post in your blog.

Publishing this blog, using carefully sized post title and jump break sections, allows me to consistently publish posts, with maximum detail visible in main page view - and with the "Read more" link visible.

Potential readers may read a post in this blog - instead of returning to a SERP, and reading another blog. This affects a key reader retention metric, the "bounce rate".

All of that considered, sizing of the introductory post sections won't always produce predictable results.

Reader zoom level is a semi random factor, which makes blog section sizing less predictable than one would wish, when trying to increase reader retention.

I size my posts using "100%" zoom, in the Chrome browser. This may, or may not, produce the same effect, for readers using Edge / Internet Explorer, Firefox, or any other browser. And the differing browser will not be the only varying factor.

All of these details can affect zoom level, screen space requirements, and reader retention - for any different blog. Here it is helpful for the blog owner to know about the typical reader.

• Display screen size.
• Reader age.
• Multi tasking activity.
• Tech interest level.

Display screen size will affect how the blog sections look, to each reader.

Browser choice is not the only variation, that can affect screen space and blog section display sizes.

Reader display screen size used is a detail, that I cannot control. The computer on which I compose most posts has a 6" high screen. A second computer, that I use from time to time, has an 8" high screen. The second computer, even at a 125% zoom level, still displays more post content in one screen page.

This post (in main page view) displayed, at 100% zoom, on an 6" vertical display.



Let's compare this post, displayed at several zoom levels.

Here's this post, in the individual post page display - without Jump Break. See how it looks, zoomed in various font sizes. Note that here I use a maximised browser window, though some readers will resize the browser window to fit the blog content.

This post (in Preview mode) displayed, at 100% zoom, on an 6" vertical display.

This post (in Preview mode) displayed, at 100% zoom, on an 10" vertical display.

This post (in Preview mode) displayed, at 75% zoom level.



Smaller zoom is more likely to be used by people with better eyesight - using better resolution and more expensive computers, and smaller browser windows.

This post (in Preview mode) displayed, at 125% zoom level.



Larger zoom is more likely to be used by people with marginally worse eyesight. This will frequently involve older people.

Older readers will be more likely to use higher zoom levels.

Reader age is another detail which each blog author may consider, in blog design.

Blogs which attract older readers should be designed for displays which use higher zoom levels - or use larger fonts, to begin. Older readers, with marginal eyesight, will be more likely to surf the web with their browsers zoomed higher.

Multi tasking encourages smaller browser windows - and lower zoom levels.

Younger readers, who like to multi task, will probably use low zoom - and size the browser window smaller, so they can have multiple windows, simultaneously visible in large computer displays. Older readers will be more likely to focus on one task at a time - and will maximise the browser window, with higher zoom.

Blog subject may produce readers of differing age and tech interest.

Each blog, depending upon its content, may be more or less likely to interest readers of a given age and / or and tech interest level. People of different tech interest levels may also be more or less likely to use computers with higher resolution, and may multi task using smaller browser windows.

The bottom line.

Each blog owner will have to consider the various issues mentioned above - for each post published - and decide what screen sizes and zoom levels might be preferred by the target reader audience.

Only a blog owner can decide what reader audience may be more interested in each individual post - and may benefit from a specific zoom level. And this affects the proper sizing of the jump break and title section of each post.

---

Several details of a #Blogger blog audience affect what post title and jump break section will be more appropriate, for each individual blog. These details, in turn, can affect bounce rate / retention rate.

Read More