CloudFlare, Custom Domain Publishing, And HTTPS

A few blog owners, who publish blogs published to custom domains, are becoming impatient, waiting for Blogger Engineering to finish the Blogger upgrade to support HTTPS / SSL.

If I get a domain through Google Domains, will I be able to get HTTPS?

Unfortunately, no. HTTPS / SSL is simply not available, to blogs published to custom domains.

HTTPS is not available, for non BlogSpot published blogs.

Whether registered by eNom, GoDaddy, or Google Domains, it simply is not possible to publish a non BlogSpot URL as a supported custom domain, and make HTTPS / SSL available. CloudFlare, a supposed alternative, does not produce a supported custom domain.

A proxied CloudFlare domain looks like malicious redirection.

In some cases, a CloudFlare DNS "solution" tried by some blog owners, will look like dangerous / malicious redirection. Some blogs will show up as "Deceptive sites", aka "phishing".

Some blogs using CloudFlare, for custom domain publishing, will be classified as "Deceptive" sites.



Others will produce alarming warnings about malware.

"This blog is not hosted by Blogger and has not been checked for spam, viruses and other forms of malware."

Click on "Details".



Look at the warning.

Phishing sites pretend to be other websites to trick you.

And there is what you get, with a redirecting proxy service, like CloudFlare.

kireisubs.id. 300 IN A 104.27.133.198
www.kireisubs.id. 300 IN A 104.27.133.198

or

topmovies21.biz. 300 IN A 104.28.0.106
www.topmovies21.biz. 300 IN A 104.28.0.106

This is the basis for malware / phishing classification.

This is most likely a false positive - most custom domain published blogs do not contain malware. Even so, it's not likely that the "Deceptive site" classification will be easily corrected, or the malware warning interstitial removed.

And this is one more blog owner, who must next be provided instruction to correct the DNS addresses.

Having corrected as instructed, DNS addresses are now asymmetrical, and righteous.

kireisubs.id. 86400 IN A 216.239.32.21
kireisubs.id. 86400 IN A 216.239.34.21
kireisubs.id. 86400 IN A 216.239.36.21
kireisubs.id. 86400 IN A 216.239.38.21
www.kireisubs.id. 86400 IN CNAME ghs.google.com.

With DNS corrected, Google shows "Not dangerous" - but the warning still displays.

"Not dangerous".

Note "CloudFlare" is still seen as the host.

You can report an error, to SafeBrowsing.



False classification now requires time consuming site review.

Use "Report Incorrect Phishing Warning", if you believe the site is safe.

Finally, get the site reviewed, from the Security Issues page in Security Console (Webmaster Tools) - Security Issues.

And while the blog remains offline, search reputation - and the owner - will suffer.

---

Some #Blogger blog owners want to provide blogs published to custom domains - and offer HTTPS connectivity. Since Blogger cannot provide custom domains with HTTPS right now, the blog owners are using CloudFlare, which provides an HTTPS proxy.

Unfortunately, a CloudFlare proxy looks like malicious redirection - and blogs using CloudFlare are being labeled as "Deceptive" sites.

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

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

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

Using A Killfile, To Filter Blogger Comments

We periodically see hopeful - yet naive - requests from blog owners, in Blogger Help Forum: Learn More About Blogger, asking about comment moderation improvement.

How do I add a disruptive commenter to a killfile list - and never see his/her nonsense ever again, without moderating every comment, being published?

This would be a popular feature - if it could be provided, in any way that would achieve results.

Using a killfile, to filter disruptive / malicios commenters, is not a likely possibility.

Anybody who does not want to be identified can comment as desired.

It is not possible to reliabily identify a comment publisher, who does not wish to be identified.

• Blogger / Google identity.
• IP address.

Disruptive individuals can't be identified, with any chance of success. Anybody who wants to publish comments can do so, using multiple accounts, and / or IP addresses.

Both Blogger / Google accounts and IP addresses can be easily cloaked.

Using either multiple Blogger / Google accounts - or IP addresses - is a trivial exercise for anybody who is determined enough to persistently publish unwanted comments.

Given the impossibility of identifying people who don't provide effective identification, Blogger is unlikely to provide a feature that would accomplish nothing - and possibly interfere with legitimate commenting.

The only solution for blocking unacceptable comments will always involve collaborative, fuzzy filters, trained by each blog owner.

---

Some #Blogger blog owners would like to use a killfile, to filter unacceptable comments. They don't understand that anybody who wants to persistently publish disruptive or malicious comments can easily mask their identity - and make killfile use an exercis in futility.

Hosted AdSense Accounts, And Blogger

Some Blogger blog owners are confused by the ability to use AdSense, with various Google and non Google services.

I monetized my YouTube videos - but when I try to sign up for AdSense, it says I need a website. So I went to Blogger to make one - but it says that I now have to buy a domain. How do I start?

The blog owner has an AdSense account - but it's Hosted by YouTube. And you can't use a YouTube Hosted AdSense account, with native Blogger.

In general, hosted accounts are useful only under the service that hosts them - and only "blogspot" published Blogger blogs can be used with a Blogger hosted account.

Rules for Blogger, and for non Blogger, content are complicated. Each service has different standards.

• An AdMob hosted account is good, only with AdMob, on a mobile computer.
• A Blogger hosted account is good, for a Blogger blog, when published to "blogspot.com".
• A YouTube hosted account is good, only with a YouTube channel.

These are rules which affect Blogger published content. Rules for Non Blogger published content are not symmetrical.

AdMob Hosted AdSense Accounts.

If you want to use a Blogger blog with a AdMob hosted account, you have to fully activate your AdSense account.

Blogger Hosted AdSense Accounts.

With a Blogger hosted account, you can only use a blog published to "blogspot.com". To use a Blogger custom domain published blog, you have to upgrade your Blogger hosted account.

YouTube Hosted AdSense Accounts.

With a YouTube hosted account, you have to upgrade your YouTube hosted account, to monetise a Blogger blog.

Interestingly, if you start with an approved and verified Blogger hosted account on a properly qualified blog, you can use that account to monetise a YouTube channel. You just can't go from YouTube to Blogger so easily.

Fully Activated AdSense for Content.

To upgrade to AdSense for Content, you need a properly qualified top level domain website - and a verified address with an AdSense PIN.

• Blogger custom domain published blog.
• Non Google hosted top level domain published website.

You need to plan any upgrade, carefully.

As I have observed previously, standards for publishing to an AdSense for Content account are much higher, than for a hosted account. You need to plan any upgrade, for a Blogger blog using a custom domain - or when you're using any other AdSense account.

The end result here is that AdSense Help Forum: Blogger, YouTube, Partner sites will not go away, from lack of questions. The online forums will always be needed, for answering AdSense hosting and upgrade questions.

---

Some #Blogger blog owners, enjoying successful AdSense use with AdMob, YouTube, or other hosted accounts, want to add AdSense ads to their Blogger blogs. They do not always understand the complications involved, in the upgrade.

https://productforums.google.com/forum/#!category-topic/adsense/partner-sites-eg-youtube/jB3MjTjNl_A

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

http://blogging.nitecruzr.net/2016/03/you-cant-use-hosted-non-blogger-adsense.html

Google Does Not Want Details Of All Offensive Blogs

Some people are victims of a offensive blog, want the offensive content removed - and find the Blogger Help: Report inappropriate content and the Google Help: Removing Content From Google forms inadequate.

How do I supply details of a blog which includes harassment or bullying content? I need to show the offense.

Some Blogger / Google forms, which are intended to feed Google Legal, simply allow us to state the URL of an offensive blog. There is not place to state exactly why a blog may be offensive, for all form selections.

There will be some cases where we may have to take action, ourselves - and start with court action.

In some cases - possibly depending upon seriousness of offense - Google Legal appears to only want us to report the URL of a problem blog.

In the past, we would advise providing details of offense, when reporting.

Previously, we would advise providing details, to identify specific offense - or where the offense is present, in the blog. This appears to be no longer relevant, in some form entries.

Be very very specific why you believe that they should be legally required to remove, or edit the content of, the blog in question.

With some offenses being reported currently, only the blog URL is requested.

Detail of offense, with some problem blogs, now appears to be a matter for Google to identify, on their own. Possibly, this encourages us to only reports problems which are blatantly obvious.

If the offense, in a problem blog, is subtle, it may not be relevant to them. In some cases, what is offensive to us may not be legally actionable for Google.

In some cases, an offended person may have to take legal action, on their own.

If you report a problem blog, using the appropriate form, and you wait patiently - and no action is taken - you may have to take action on your own.

This is where you hire a lawyer - and get a court order from a sitting judge, that supports your needs. Then, you must submit your court order, properly.

---

All offensive #Blogger blogs do not appear to require the same level of detail, when reported to Blogger / Google. In some cases, we can only report a blog URL - and Google Legal will take it from there.

Diagnosing AdSense Account Problems

AdSense uses various techniques to protect their content quality - and when they take action, they don't always give you a lot of clues about their actions, or warnings before taking action.

Both AdSense and Blogger use fuzzy analysis to classify unacceptable content and practices. Neither AdSense or Blogger can publish definitive policy advice, each time they classify or suspend an account.

AdSense publishes policy guidelines - and prohibited content, to define the limits.

AdSense works best when staying well within the limits.

Like Blogger, AdSense requires blog owners / publishers to stay within the limits.

We want to maintain a strong ecosystem for both advertisers and publishers. As a publisher, you are responsible for maintaining high quality inventory and traffic.

People who stray outside the limits should not expect detailed coaching, which let them determine exactly what limits can't be exceeded.

When you exceed the limits, you may not like the results.

Bad news, seen by some too late.



Dodgy techniques and traffic cause problems with both AdSense and Blogger - and both AdSense and Blogger will take action.

For best results, read and follow required practice.

When an AdSense account is suspended, AdSense provides a Disabled Account FAQ. You can use the FAQ - but you'll do better to read the policies, and stay within the limits.

You can appeal, after correcting a problem - within limits.

You'll find limited support for appealing - even after identified problems are resolved.

Thanks for contacting Google AdSense. According to our records, you already appealed to us twice in the last 30 days. Due to the volume of appeals we receive and as indicated in our help center you can't appeal more than twice per month.

If your previous appeals have been unsuccessful please remember that our actions are the result of careful investigation by our team of dedicated specialists, taking into account the interests of our advertisers, publishers, and users. Though you might be disappointed with our decision, we are unable to reinstate your account.

If you have new information which may have helped us to reinstate your account then you are welcome to submit another appeal next month.

We appreciate your patience and understanding.

An effective appeal requires two definitive details.

1. Acknowledge what you did wrong.
2. Describe what you are doing to prevent its recurrence.

The best action will be to read and observe published policies.

---

Like #Blogger, #AdSense does not provide detailed advice, or advance warning, about unacceptable content or practice. AdSense publishers are simply expected to read their policy documents - and stay well within the limits.

Dynamic Templates, And "Follow by Email"

We see occasional concern about providing email subscriptions, from blog owners in Blogger Help Forum: Get Help with an Issue.

How do I provide email subscriptions for my blog? Follow by Email does not work!

The blog in question is using a dynamic template - and it appears that the blog owner is out of luck.

The "Subscribe by Email" gadget does not work, with dynamic templates.

Add "Subscription Links" to a blog with a dynamic template.

For email subscriptions, and a blog with a dynamic template, you use the "Subscription Links" gadget. Here is my blog, Chucks Musings.

Use "Subscription Links" with a blog that has a dynamic template.



When you add "Follow by Email" to a blog with a non dynamic template, it sets up the "Email Subscriptions" service, in FeedBurner. "Subscription Links" is a collection of various subscription services - and won't activate "Email Subscriptions".

You may need to activate "Email Subscriptions".

You will probably need to activate the "Email Subscriptions" service, to use "Subscription Links" instead of "Follow by Email".



To use "Subscribe by Email" as a selection in "Subscription Links", be sure that the "Email Subscriptions" service is activated, from the FeedBurner dashboard.

Alternately, add "Subscribe by Email" in a linklist gadget.

Sometimes, you may not want to use "Subscription Links". So, just add the "Subscription Link Code", in a linklist gadget.

Here, we have a new sidebar accessory.

And when you click on the link, you get the familiar FeedBurner "Email Subscription Request" verification form.



So, either add "Subscription Links" - or make a custom LinkList accessory. One, or the other, will give you "Subscribe by Email", in a dynamic template.

---

Owners of #Blogger blogs, wishing to provide email subscriptions, find that "Follow by Email" won't work with a dynamic template. Fortunately, "Subscription Links" will provide email subscription - though the necessary FeedBurner service has to be activated.

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

Custom Domain Publishing, And World Culture

People who speak (read / write) languages, that do not use Roman character sets, need to publish in their native language - and the Internet now supports that need.

Some registrars will register domains which use non Roman character sets, in the URL. Not all Internet services will accept non Roman characters, however.

My favourite online DNS diagnostic services, DigWebInterface, and intoDNS, and Rex Swain's HTTP Viewer, only use ASCII. One cannot use non ASCII ("non Roman") characters, with either service.

"بحث-سناب.com", as converted, shows an example of an Internationalized domain name.

To use DigWebInterface to retrieve DNS addresses, and intoDNS to check the domain setup, we have to convert the native URL to Ascii.

I use three reliable online services, which will convert URLs to ASCII.

• DomainTools
• WhoIs - Identity for everyone
• Who.is - Powered by Name.com

Converting "بحث-سناب.com" to ASCII involves use of one of the latter services.

DomainTools

WhoIs - Identity for everyone

Who.is - Powered by Name.com



Using the 3 tools, we see that "بحث-سناب.com" == "xn----zmcbcml8b0j.com", "XN----ZMCBCML8B0J.COM", and "xn----zmcbcml8b0j.com", respectively. Look carefully, in the body of the display for each service, for the IDN equivalent.

We can then use "xn----zmcbcml8b0j.com", with DigWebInterface, and intoDNS - and get the necessary diagnostics.

And using the latter tools, we see a properly setup domain - which is now being used for a properly published Blogger blog, verified in Rex Swain.

DigWebInterface

intoDNS

Rex Swain's HTTP Viewer



And when assistance is requested, in Blogger Help Forum: Get Help with an Issue, we can use these tools with non Roman character URLs.

---

The Internet now supports use of non ASCII characters, in URLs. In order to publish #Blogger blogs to Internationalised Domain Names, we need to convert native URLs to ASCII - using any one of three identified online DNS services.


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

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

Recovering From A Corrupt Template - Persistence

Of the many Blogger Mysteries that confound blog owners and readers, none are more obscure than the many bX codes.

Some problems, reported in Blogger Help Forum: Get Help with an Issue, start so innocently.

As I edited the Template HTML, I saved my changes - and the bX error suddenly appeared.

Each different bX code refers to a different problem, with Blogger in general. Of the bX codes that refer to template corruption, each different bX code may refer to a different template corruption problem.

When a template corruption problem can be reset, the resetting process may involve repeated use of one or more dashboard pages.

Different problems may enable - or prevent - use of a different dashboard page. For problems with multiple causes, you may have to use each different wizard, persistently.

1. The Template Designer page.
2. The Template page.
3. The Template Editor ("Edit HTML") page.
4. If the blog is not operational, you start again.

Unfortunately, some problems may prevent use of all 3 pages. For the problems that permit use of one or more pages, you try each available page, repeatedly, until the blog becomes operational.

To access each page, you may need to bypass the dashboard menu.

The Template Designer page.

The Template Designer is used for one task - "Remove customizations".

The Template Designer.



"Remove customizations" may be the simplest reset that you may try - when possible. Some customizations, when removed, may enable subsequent use of the Template page, or the Template Editor.

The Template page.

The Template main page is used for two tasks.

1. Backup / Restore the existing template.
2. Get a new template.

The Template main page.



Some problems, when reset using the Template main page, may enable subsequent use of the Template Designer, or the Template Editor.

The Template Editor ("Edit HTML") page.

The Template Editor ("Edit HTML") is used for two tasks, as an alternate to the Template main page. Also, it may be used to reset any "rgba" colour combination problems.

1. Backup / Restore the existing template.
2. Get a new template.

For template corruption problems that prevent use of the Template main page, the Template Editor - combined with a second blog, where a clean template is developed and tested - can be used.

The Template Editor (aka "Edit HTML").



Some problems, when reset using the Template Editor, may enable subsequent use of the Template Designer, or the Template main page.

If the blog is not operational, you start again.

If you get a new bX code, you repeat the above sequence. Some problems, with multiple causes, may require repeated retries.

In extreme cases, you may end up creating a new blog at the URL.

---

Some #Blogger template problems, which lead to a bX code display, may have multiple causes - and all causes may require solution, to make an affected blog operational. With some causes preventing solution of others, a repetitious use of the various dashboard pages may be required - to solve some template corruption problems.

You Cannot Fit Your Entire Blog Onto The Main Page

Some blog owners would like their readers to view the entire blog in one page.

A small blog, with very limited size, can theoretically fit on one page. If you intend to publish a blog with any future, and page rank, you will have to publish content periodically - and the size of the blog will increase, steadily.

And eventually, thanks in part to main page limitation by auto pagination, older posts in your blog will be forced into archive pages.

For a blog with any future, and publishing activity, there are four possibilities for main page size.

• Segment main page, limiting post count.
• Segment your blog, using virtual blogs.
• Use a dynamic template, and "continuous scrolling".
• Use a non dynamic template, and Jump Break - and accept archiving.

Segment main page, limiting post count.

One of the simplest ways to make your blog reader friendly is to limit main page size, using a post count limit. This won't work as a final solution, however, if you're planning to publish the blog with any regularity.

Segment your blog, using virtual blogs.

If you can break your blog into multiple subjects, you can use a Pages tabbed index to access each different subject. You can fit each different subject, possibly using Jump Break, onto one page.

To complement the virtual blogs, you can have a static main page - providing a "welcome" message, and / or indexing the virtual blogs.

Use a dynamic template, and "continuous scrolling".

For public blogs, a dynamic template, with continuous scrolling, may provide a solution. Dynamic templates, unless you a very comfortable with editing the blog template, will never offer the accessory and customisation possibilities of non dynamic templates, however.

With a dynamic template, you won't be able to use Jump Break - though some dynamic views may provide a summarised main page view.

Use a non dynamic template, and Jump Break - and accept archiving.

Careful use of Jump Break will let you limit the size of the main page. If you continue to publish posts - which is necessary for a blog with any future - you will eventually have posts displayed on archive pages.

For best results, design the blog structure - and the posts structure - consistently, and accept archiving and pagination.

---

Some #Blogger blog owners would like to display all post content in one page - and ignore page display size. They do not realise that not all blog readers want to read a blog with an unlimited page size, all at once.

Commenting Requires Login, To Suppress Spam

Some blog owners don't understand the need to identify themselves, when commenting on our blogs.

We see an occasional question, in Blogger Help Forum: Get Help with an Issue, about comment authentication.

Why, if I've selected "Anyone - including Anonymous Users" under comment settings, for "Who can Comment?", do my visitors complain of having to login?

This blog owner, like many others, does not understand the Blogger spam mitigation policy, in Blogger Comments.

Blogger lets us select who we wish to allow to comment, on our blogs.

When we do not moderate, they require authentication, to cut down on the spam. Moderated comments, with CAPTCHA ("Show word verification") not required by the owner, appear to go straight to moderation.

Comment authentication makes genuine comments more normal.

By requiring authentication, Blogger makes it more likely that a comment, awaiting moderation, will be genuine - instead of more spam. This encourages us to moderate comments more frequently - and helps us publish moderated comments, more promptly.

And more frequent moderation discourages spam - and makes it more likely that we will see actual comments, later.

Blog owners choose how to allow comments.

As a blog owner, it's your choice how / whether to allow comments.

• Anyone - includes Anonymous Users.
• Everybody with a Google, or an OpenID, account.
• Everybody with a Google account.
• Blog members only.
• Comments disabled.

Blog readers choose how to publish comments.

Depending upon the choices that you provide, your readers choose how they may authenticate.

• "Anyone" allows a reader to comment anonymously - or identified.
• If they wish to comment anonymously, they login, using a CAPTCHA.
• If they wish to comment using a profile, they login, using an account.
• Login is generally only required, with the first comment.

"Anyone" allows a reader to comment anonymously - or identified.

"Anyone" allows anyone to comment anonymously (if they wish). To cut down on spam, anyone commenting has to login.

If they wish to comment anonymously, they login, using a CAPTCHA.

Solving a CAPTCHA lets them remain anonymous - but still identify themselves as a person, not a bot. Any comments, awaiting moderation, or published, are more likely to be genuine - not spam.

If they wish to comment using a profile, they login, using an account.

They can login, as permitted, using a Google or OpenID account. Anyone able to login with a Google or OpenID account can still publish a comment anonymously, if they wish.

Login is generally only required, with the first comment.

If someone has to login repeatedly, to comment, they have a problem with identification, and filters. With cookies and scripts properly permitted, login (with the first comment) will be remembered (with any later comments).

The Blogger / Google login status, and the ability to post comments, is sensitive to both cookie and script filters. Your readers may need to enable (stop filtering) "third party cookies", in their browser and on their computer - if they wish to comment, most easily.

---

Both a #Blogger blog owner - and blog readers - get choices how to authenticate when commenting. Depending upon the choices made by the owner, the readers get more, or less, choices.

Add A FaceBook Gadget With FaceBook SDK Code

Some blog owners can't get their new FaceBook gadgets to work, on their blogs.

We see the occasional report, in Blogger Help Forum: Get Help with an Issue.

The blog won't accept the code that Facebook Developer generated for me.

Adding HTML gadgets - and HTML gadgets using FaceBook code - can be frustrating. But, it's possible.

Adding a FaceBook gadget, to your blog, is not difficult - but success is found, in the details.

• Add the gadget as a new HTML gadget.
• Add the FaceBook SDK code, to the first FaceBook gadget.

Add the gadget as a new HTML gadget.

Blog maintenance is far easier, with a FaceBook gadget - or any other HTML / JavaScript based accessory - added as content, in a new HTML gadget - far smarter than using Template Editor.

Add the FaceBook SDK code, to the first FaceBook gadget.

FaceBook instructs us to add SDK code to each page which will display a FaceBook gadget - but advises that we should only add the SDK code once / page.

Gadget code, as provided by FaceBook Developers:

<div class="fb-comments" data-href="http://ourladyofoutrage.blogspot.com/" data-numposts="5">
</div>

Gadget code, as added to a new HTML gadget:

<div id="fb-root">
</div>
<script>(function(d, s, id) {
var js, fjs = d.getElementsByTagName(s)[0];
if (d.getElementById(id)) return;
js = d.createElement(s); js.id = id;
js.src = "//connect.facebook.net/en_US/sdk.js#xfbml=1&version=v2.5&appId=528167400699401";
fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

<div class="fb-comments" data-href="http://ourladyofoutrage.blogspot.com/" data-numposts="5">
</div>

A new FaceBook gadget, being added.



Just pay attention to the details, for best results.

---

Some #Blogger blog owners try to add accessories provided by FaceBook Developers, without success. They don't realise the importance of the details involved.

Financial Advice Blogs Do Not Need AdSense

We see unhappy blog owners, in AdSense Help Forum: Blogger / Host Partners, asking about the ads which they should have, on their blogs.

Please let me know why ads are not showing, on the blog - or how much time it will take more in showing ads.

Sometimes, the answer(s) are simple - but will not satisfy the owner.

Not all blogs are suitable, as AdSense ad hosts.

Financial advice blogs are not suitable, to host AdSense ads.

One example of unsuitability involves commercial and financial experts. Some blogs offer financial advice - and the owners would like to add ads to their blogs.

The reference AdSense Help: Prohibited content provides no reference, to financial blogs. The problem with financial blogs, that will not display ads, involves conflicting interest.

Ads hosted by a financial advice blog would be for services of a competitor.

If ads were to be displayed, on a financial expert blog, they would be for competing financial advice services. No ad manager, however, would pay for his clients ads to be hosted on a website belonging to a competitor.

In order for ads to be meaningful, on a financial advice blog, the financial expert would have to be making very little money. This would conflict with the business strategy of any financial expert.

Anybody who needs income from ads, to support a financial advice blog, does not make enough money - and therefore is not worth paying for advice. And nobody will pay for ads, from would be customers of someone who publishes a blog with bogus advice.

Anybody who publishes a blog with financial advice does not make enough money.

Any successful financial expert makes far more money, from providing advice, than income from any website which hosts AdSense ads. Anybody who can successfully provide financial advice is much better off spending more time providing more financial advice directly, to qualified customers.

Nobody who has enough money to interest a successful financial adviser is going to be surfing the web, looking for advertisements selling financial advice. This consideration, too, is going to prevent any web savvy ad manager from paying any clients ads to being hosted on a website owned by somebody publishing dodgy financial advice.

There is simply no market, for websites providing financial advice, in hosting AdSense content. Pure and simple.

---

Some financial advice experts would like to finance their websites, using AdSense ads hosted on #Blogger blogs. They do not consider that there is no market for AdSense hosted financial advice ads - because anybody who sees an income improvement, from AdSense, is not making enough money from financial expertise - and is not worth paying for advice.

Blog Security Review Is Not Instantaneous

Blog owners do not always understand the reasons behind the mysterious blog security check (following "suspicious" / "unusual" activity account lock).

We see periodic complaints about deleted blogs and locked accounts - and the inconvenience involved, in Blogger Help Forum: Get Help with an Issue.

I get the security and all - but I don't get how a blog is just deleted.

This blog owner, like so many, does not understand how Blogger is trying to keep our blogs under our control - even after detection of "suspicious" / "unusual" activity.

Blog security check, if immediate and instantaneous, would not be noticed.

Blog security check is an art - not a science - and it takes time.

If blogs could be checked for hacking interference without delay, most owners would not complain. Unfortunately, examining blogs for hacking interference requires intense study - and most security experts do not work on weekends.

One unfortunate issue, about all of this, is that not all "suspicious" / "unusual" activity is malicious. Some of it is a simple result of people unable to use account / blog recovery - being innocently told to try every account name and password that can be remembered.

Owner delay, in requesting account unlock, contributes to security check delay.

In some cases, the locked account / deleted blogs may not be immediately discovered by the owner - and this may lengthen the security check process.

Not all blog owners publish - or even read - their blogs regularly. Nor do they accept the need to intentionally keep their account and blogs under their control.

Some owners are very casual about blog security - until a blog is successfully stolen.

---

Some #Blogger blog owners are not terribly impressed by the need to keep their blogs under their control, until a blog is stolen. The measures taken by Blogger / Google Security staff are considered mere annoyances.

Blogger Resolves The FaceBook Photo Sharing Issue

Blogger Engineers recently added Blogger template code, to provide images in shares to FaceBook.

The added code is included in the standard template header. If you have a custom template, you may need to verify template header content.

If you have added the previously recommended Open Graph Code to your blog, to allow Open Graph based post / photo sharing - and you use the FaceBook Developers Debugger tool, you may see a new diagnostic suggestion.

Given newly added template code, blogs with added OG code may generate ominous warnings in the FaceBook Developers Debugger tool.

Looking at my blog, and the blog main page.

Object at URL 'http://blogging.nitecruzr.net/' of type 'article' is invalid because it specifies multiple 'og:url' values: http://blogging.nitecruzr.net/, http://blogging.nitecruzr.net/.

Looking at my blog, and a FaceBook Debug log, for this post.

Object at URL 'http://blogging.nitecruzr.net/2016/03/blogger-resolves-facebook-photo-sharing.html' of type 'article' is invalid because it specifies multiple 'og:url' values: http://blogging.nitecruzr.net/2016/03/blogger-resolves-facebook-photo-sharing.html, http://blogging.nitecruzr.net/2016/03/blogger-resolves-facebook-photo-sharing.html.

With Blogger now providing a properly resized image, automatically, from each post, the image provided in the previously suggested Open Graph code is now redundant - and causes duplication.

The browser source listing, for this post.

The FaceBook Debugger log, for this post.



Here's what I see now, in the standard template header.

<meta content='Blogger recently added template code, to properly share content to FaceBook. Learn how this affects your blog.' name='description'/>
<meta content='http://blogging.nitecruzr.net/2016/03/blogger-resolves-facebook-photo-sharing.html' property='og:url'/>
<meta content='https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYoNmMZMeZRUpzFIuXA-fvRaacglFAZDveaf29C-3qn_m57gI8nh3-8Ih7rPMtA2p9LmZoSg-KR0FtRxHoO7HX88g8SMmEOKL7hkN7kftW9jYajRpsZJTwH0Y9JRIDrwYBqF3W83I7X8dI/w1200-h630-p-nu/Screenshot+2016-03-13+at+14.35.32.png' property='og:image'/>

So, what do we have?

<meta content='https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhYoNmMZMeZRUpzFIuXA-fvRaacglFAZDveaf29C-3qn_m57gI8nh3-8Ih7rPMtA2p9LmZoSg-KR0FtRxHoO7HX88g8SMmEOKL7hkN7kftW9jYajRpsZJTwH0Y9JRIDrwYBqF3W83I7X8dI/w1200-h630-p-nu/Screenshot%2B2016-03-13%2Bat%2B14.35.32.png' property='og:image'/>

The chosen image - resized to 1200 x 630, to suit the FaceBook recommended 1.9 aspect ratio - and large, to suit the FaceBook recommended size.

Now, 3 data elements (2 Open Graph) may be redundant.

• description
• og:image
• og:url

This makes the immediately previous advice unnecessary.

If one wishes to provide author information, that also becomes slightly simpler.

<!-- BEGIN Open Graph tags -->
<meta expr:content='data:blog.metaDescription' name='description' property='og:description'/>
<meta expr:content='data:blog.pageTitle' name='keywords'/>
<b:if cond='data:blog.pageType == "item"'>
<meta content='article' property='og:type'/>
<meta content='https://plus.google.com/nnnnnnnnnnnnnnnnnnnnn/about' property='article:author'/>
<meta expr:content='data:blog.pageName' property='og:title'/>
<b:else/>
<meta expr:content='data:blog.title' property='og:title'/>
<meta content='blog' property='og:type'/>
</b:if>
<meta expr:content='"en_US"' property='og:locale'/>
<!-- END Open Graph tags -->

If you truly want to share author details, you still have some work to do - but photos should now be shared, automatically, if your blog has a template with a standard header.

---

Recently, Blogger Engineering added OG code to the standard template header, to allow us to share posts with images to FaceBook, without having to add special code. This should help, for owners of blogs which have standard headers.

Base64 Photo Hosting, And Open Graph Code

Some blog owners make photos an important part of blog content.

When sharing a post to FaceBook, problems are seen with photo content. In some cases, this is because of how the photos were added into the post, when using Post Editor.

We've known about problems with photos installed using drag and drop, and post editor, for a few years. Drag and Drop photos, in some cases, are stored as "Base64" content - with the photo content hosted in the post, instead of Google Photos (or Picasa).

Photos added to posts in post editor, using "drag and drop", have been a problem for many years.

Base64 hosted photos make posts abnormally large.

Posts containing "Base64" encoded photos are abnormally large - and will cause problems with the index pages, and auto pagination. That is a nuisance - but just that.

With posts shared to social media, such as FaceBook and Twitter, photos hosted using Base64 become more than a nuisance. When normal posts are shared to FaceBook, OpenGraph code is used to identify key post content - such as a photo to accompany the shared post.

Open Graph code uses URLs to reference photos.

OG code uses HTML / XML tags, in template code - with a URL identifying a shared photo. A post that contains Base64 hosted photos won't have URLs identifying the photos - it will have the actual photo content.

This photo was installed, using drag and drop. Interestingly enough, it is not Base64. It is possible that Blogger no longer uses Base64 encoding - which would explain why the problem with OG code is rather irregular.

When shared to FaceBook, the photo must be converted to normal Google Photo hosted content, so it can be shared using a URL - as normal photos are shared, using OG code. If shared using Base64 content (if OG were to support Base64), the post, again, becomes abnormally large.

Base64 hosted photos simply present one more complication, when sharing posts to FaceBook, Twitter, and other social services.

---

Some blog owners publish posts that contain photos added using drag and drop. Some drag and drop installs result in Base64 hosted photos - which must be converted to Google Photos hosted content, when shared to FaceBook or Twitter.

Private Google Groups Email Distribution Is Broken

Some blog owners have reported in Blogger Help Forum: Get Help with an Issue, about broken email distribution.

There are various ways to distribute Blogger blog content, to email. For those unable or unwilling to use FeedBurner Email Distribution, one popular alternative is Google Groups.

One drawback of FeedBurner based distribution is that FeedBurner uses the blog newsfeed - and is unusable for private blogs.

Google Groups is the best content distribution medium, for private blogs.

The only scalable distribution medium, for private blogs, is Google Groups. Right now, Google Groups, for some owners, is not accepting incoming email.

This problem may not be unique to Blogger blogs. There are other reports of this problem, in the Google Groups Support Forum.

We are asking for details, in a previously posted forum Problem Rollup topic.

We have a previously discussed article, and a Problem Rollup topic, in Blogger Help Forum: Get Help with an Issue - where we are requesting details, as phrased above, about the problems. If you have details to contribute, solution to this problem may result from your contribution.

Please help Blogger Engineering to help you - and make your responses polite, relevant, and responsive. If this problem is to be identified, and you are affected, resolution depends upon you. And also report your problem in Google Groups Support.

---

Some #Blogger blog owners are reporting that distribution of private blog content, using Google Groups, is not operational. This problem may not be unique to Blogger blogs, as there is some discussion in Google Groups Support.

Please, Don't Try Guessing Your Account / Password!

We see too many problem reports, in Blogger Help Forum: Get Help with an Issue, about locked accounts and deleted blogs.

My Google account was suspended because of 'suspicious activities'. Last month, I realized that my two connected blogs, to that account, were also put offline!

Somebody else was unable to use the supplied account / blog recovery tools - and tried guessing what could not be remembered.

The first would be a blog owner, whose only mistake was having a Blogger account with a name similar to another account, owned by the second.

The second would be someone who could not remember her (his) account name / password, could not use account or password recovery, and who got well meaning advice.

Just do the best you can - try what may be your account name, and any passwords that you can remember!

One blog owner must suffer, because another cannot remember login details.

And owner #1 is suffering, because of owner #2. Owner #1 is now anxiously waiting for action by the security experts (with the blind queue of unknown length) to examine his blogs - and possibly, waiting while not knowing why.

Owner #1 may be seeing this - and not know why.



Password guessing may be necessary, in extreme cases - but it can cause misery - and owner #2 will never realise the pain caused to owner #1. Even if owner #2 recovers access to her / his blogs, innocent brute force attempts can cause account lock / blog security lock, to owner #1.

Protect yourself against the anguish, using Google 2-Step Verification.

The best way to protect against this sort of abuse is to use one or more Google Two Step Verification options. This will leave owner #2 seeing (for instance).

Insert your USB security key, and tap the lighted button.

And having no security key, owner #2 will simply have to try guessing a different account name. It may be an inconvenience (for owner #1), carrying a never used USB security key - but the one time it's needed (and available), it will make up for the inconvenience.

---

One #Blogger blog owner, unable to remember a necessary account name or password, may try guessing what cannot be remembered. Guessing an account name can leave one trying an account that somebody else owns - and can cause account lock and blog deletion for somebody who they will never know.

Our Blog Content Is Our Responsibility

We see evidence of occasional confusion, in Blogger Help Forum: Get Help with an Issue, about blog content responsibility.

One of my blog posts disappeared. I have tried every known recovery procedure. There is no way to actually contact anyone from Blogger Support.

Long ago, Blogger Support would provide assistance, in recovery of deleted posts. That service ended some time ago.

Blogger promises us that our blogs will be ours, forever - and that they will support that promise.

That promise is most likely to be upheld if we maintain control of our blogs - and of the content in the blogs.

Blogger will ensure that our blogs remain under our control - but we have to maintain the content. If we change or delete a post, Blogger is not going to second guess our intention, and revert our change, or un delete our deletion.

If we change a page or post, there are two possible recovery procedures.

• Undo the change - using the browser editor menu.
• Recover the contents - using search cache.

Undo the change - using the browser editor menu.

If you make a mistake, the Blogger post editor, like many edit windows, supports "Undo" aka "Ctrl - Z". You have to act immediately, though. If AutoSave becomes active, you may not get the chance.

Recover the contents - using search cache.

This is the procedure currently used, for recovering deleted pages and posts. It is most effective, for established (cached) pages and posts - draft and new pages and posts may not be found, in cache.

Our chances are otherwise limited.

Short of using undo or cache recovery, we may be out of luck - if we make a change that needs to be reversed. As long as we do not violate Content or TOS Guidelines, our content is ours - to have and to maintain.

---

As we publish our blogs, Blogger promises us that they will ensure our ownership, forever. That promise requires that we take responsibility for any mistakes - and that we take responsibility for the content in our blogs.

Train Security Products, And Keep Your Blog Clean

Everybody who uses a computer - and expects to use their computer for any amount of time - has one or more protective products on their computer.

Anybody who publishes a blog, with an audience that has any need for security, is going to receive occasional reports from would be readers.

I can't read your blog! My computer displays an "Unsafe website!" warning!

All computer security products, unfortunately, will occasionally generate false positives. Analysing false positive malware reports is as much a part of every security product, as identifying the actual malware.

If you publish a blog, you need to know how to handle reader malware alert reports.

Know online tools, for researching reported problems.

Google provides 2 websites, for analysis of blog / website malware alerts. Both Google SafeBrowsing, and VirusTotal, are Google products that can help to identify actual problems with blogs and websites.

Besides the two Google products above, I use 3 security analysis websites, which can identify specific security problems in blog / website code. Quttera Online Website Malware Scanner, and Sucuri SiteCheck, and Trend Micro SIte Safety Center, have been useful at various times, when a security problem is reported.

You may, from time to time, use all of these - and possibly others - in identifying and verifying a security problem with your blog, or with blogs and websites that you link. For best results, always specify the canonical blog URL, when requesting security analysis - and when sharing the blog, or individual posts.

Specify the canonical URL.

Not a country local domain.



Know what you need to do, to keep your blog healthy.

As a blog publisher, you will occasionally have 2 jobs to do, when receiving a malware alert report which references your blog.

1. Verify / identify / remove any actual malicious content.
2. Report false positives, to the protective service displaying a false positive.

Everybody who publishes a blog, with any reader audience, has seen this advice, or something similar, when surfing their blog.



Know how to keep your blog clean - and your reputation clean.

You have to use online malware analysis services, to identify any problem which you may have created, by installing the latest "gotta have this!" accessory on your blog. And, you have to report any false positive alert, to the owners of any security product, that falsely identifies your blog as a problem.

You do both, to support your readers. You do not want your readers computers hacked, through your inappropriately accessorising your blog - but at the same time,you want your readers to be able to read your blog.

1. Keep your blog content clean.
2. Keep your blog reputation clean.

Do both - or you may not have readers, to read your blog.

---

Any #Blogger blog owner needs to support the blog readers, by publishing a blog clean of any malware, and with a good reputation with the various security products that prevent malicious action by dangerous blogs and websites. Your readers need the ability to use their computers to read your blog - and they need their security to not falsely identify your blog as a problem.

Some bX Codes Caused By Zero Alpha ("rgba") Value

We're seeing a few reports of bX codes, that are not solved by simply resetting the template - and do not involve the mysterious "500 Internal Server Error".

In some cases, the blog owner may see a bX code when trying to use "Configure Blog Posts", or another Layout gadget wizard. If the blog itself can be viewed, and Template HTML Editor is usable, the bX error may come from use of a "0" Alpha color setting.

Blogger Engineering is aware of the problem, and has suggested that a fix is being developed. While we await the necessary fix, we may need to work around the problem.

The suggestion by Blogger Engineering is that we use a "Transparent" option, instead of "0" alpha value.

It seems that this issue is triggered by color variables with a value that has zero alpha, e.g. 'rgba(0, 0, 0, 0)'.

Some gadgets, and template sections, have the "transparent" selection in their color setup. Not all have this option, however. Some template CSS rules are not so easily edited.

The problem here is the "rgba" 4th value of "0" - ie, the "alpha" "0" value. The simplest solution is to change the "0" to a non zero value - without changing the "rgb" values.

The simplest solution, to get "Configure Blog Posts" or any other affected gadget usable, may be to use Template Editor, and change the values, directly. Look at every CSS rule, that has an "rgba" setting - and look for a 4th value of "0".

• For "rgba(0, 0, 0, 0)" - Change to "rgba(0, 0, 0, .1)".
• For "rgba(255, 255, 0, 0)" - Change to "rgba(255, 255, 0, .1)".
• For "rgba(255, 255, 255, 0)" - Change to "rgba(255, 255, 255, .1)".

A transparency setting of ".1" should be visually close to "0" - and should get the blog in question back online and updatable. And after Blogger Engineering fixes their gadget / template editor code, to accept the "0" value - and if the ".1" creates a noticeably unacceptable condition - this can be corrected, when necessary.

It's possible that this error, being seen, is part of a larger problem. You may need a persistent solution.

---

Some #Blogger bX codes, being seen in the forums right now, do not appear to involve terminal template corruption, and the mysterious "500 Internal Server Error". Some bX codes can be easily corrected, when they involve a "0 alpha" value (a CSS color rule involving an "rgba" setting).

When the Template Editor is usable, a simple search and replace for "rgba(nn, nn, nn, 0)" to "rgba(nn, nn, nn, .1)" may be sufficient to correct the error.

Stats "Don't Track" - You Cannot Satisfy Everybody

Blogger recently redesigned the Stats "Don't track ..." option - and removed third party cookies from the picture.

The "Don't track ..." wizard is now accessed from the blog URL. The wizard still produces cookies - but they are ordinary first party cookies, which are much less feared than third party cookies.

But, every silver lining has a cloud.

In making the "Don't track" wizard accessed under the blog URL, Blogger created a new requirement - which is no more understood, by some blog owners, than "third party" cookies.

"Don't track" now runs scripts from the blog URL, instead of the Blogger dashboard.

In order for a blog to observe - and preserve - the "Don't track" setting, any computer that the owner uses has to permit first party cookies - and all scripts - from the blog, instead of from the Blogger dashboard.

Since "Don't track" is designed to be used by the blog owner, this new requirement should not be a problem. Every blog owner should be able to trust herself / himself, to not add dodgy code to his / her own blog.

Many security products block scripts from personally owned blogs.

Unfortunately, general security practice is to block scripts from "blogspot.com", "blogspot.xx" (for every "xx" for every country local domain"), and preferably for blogs published to custom domains.

You can trust scripts from "blogger.com", and the Blogger dashboard. You cannot trust the individual blogs, since you cannot trust every blog owner. Even if you could trust some people not to intentionally try to hack your computer, you cannot trust everybody to not stupidly install malicious software from a very convincing hacker, providing one more "gotta have this" blog accessory.

And since you cannot trust the individual blogs, you will have filters. And those filters have to be adjusted, to trust your own blogs - if you want to ignore your own pageviews.

Some blog owners add security software, and don't know how to maintain the filters.

There are too many Blogger blog owners who have installed protective software on their personal computers - without knowing how to adjust the filters, in the protective software. And some of those owners think that it is a Blogger responsibility, to provide them instructions, how to adjust the protective software on their own computers - when only they are capable of knowing what they installed.

---

The new version of the Stats "Don't track" option is an improvement, because it no longer requires third party cookies - and involves the associated security risk. Unfortunately, it now requires blog owners to permit scripts, from the blogs themselves.

This is not a security risk, in that only personally owned blogs need to be trusted - but the blog owners do need to know how to adjust the filters involved. And not everybody with a computer knows how to configure their security accessories.

Blogger Magic - Stats Accuracy And Consistency

One of the least understood Blogger features is the Stats visitor counters, and the various displays.

We see the confusion, in Blogger Help Forum: Get Help with an Issue, periodically.

The "weekly" Stats numbers don't add up, properly!

or

Why is "Popular Posts" so out of touch, with reality?

Magic is fun to watch, when it's just for amusement. When your numbers seem to have magical quality - changing from day to day, or display to display - it becomes annoying.

With its many lines and pages, the various Stats displays look like they could be part of one big balance sheet - but they are not.

With a balance sheet, you'll have detail lines in one page, that can be added up and reconciled against totals, in another page. This makes some balance sheet components redundant.

With Stats, nothing is redundant. Whether provided in a dashboard page, for you to examine - or in a gadget, to encourage your readers - all numbers are significant, exactly as displayed.

What you see for each day cannot be added up and balanced against a week - nor can a collection of weeks add up to a month. Nor can detail lines in "Pages" add up to totals, in "Audience".

• Components and features are provided for different purposes.
• Different dashboard pages reflect different details.
• Time periods do not begin and end equally.
• You may, or may not, be able to ignore your own pageviews, consistently.

Components and features are provided for different purposes.

The "Popular Posts" gadget displays popular posts, for the convenience of the blog readers - and there is no "Popular Pages" gadget, for people who choose to build a blog, based on static pages. The dashboard Stats pages are displays for informing the blog owner.

The (3) time range selections in "Popular Posts" also differ from the (5) selections in the dashboard Stats pages - further preventing comparison between Popular Posts and dashboard displays.

Different dashboard pages reflect different details.

The "Posts" dashboard page lists (only) the 10 most popular posts ("dynamic" pages), and the 10 most popular pages ("static" pages). "Pageviews today", and "Pageviews yesterday" reflect all blog activity - all index pages, all "pages", and all "posts" together.

Time periods do not begin and end equally.

"Pageviews today", and "Pageviews yesterday" counts are reset based on the global day - not on any local clock. Your "today" will never be the same, all days of the year - if ever. 23 / 24 of the world will never see their "today" equal to "Pageviews today", and "Pageviews yesterday".

And everybody knows that weeks, months, and years never begin and end in synch. You cannot add up weeks into months - nor months into years.

"Pageviews today", and "Pageviews yesterday" are the best known objects of confusion - but by no means the only - in the Stats data complement.



You may, or may not, be able to ignore your own pageviews, consistently.

Even given the recent improvement to the "Don't track" option, not all blog owners will be able to ignore their own pageviews. Every blog owner has their own required complement of performance and security products, which may interfere with the Stats "Don't track" code.

The bottom line.

Everybody needs to accept reality - that Stats will simply perform differently, for every different blog, and for every different owner of every team blog. Enjoy and use Stats for what it is.

---

Many #Blogger blog owners become concerned, when they add up detail Stats numbers on one display, and find the numbers do not agree with the totals from another display. They do not notice that the numbers have different origins, and purposes - and simply cannot add into any different display, with any degree of accuracy.