Adding Whitelist Entries, To Adblock Add-Ons

Ad blockers are popular Chrome add-ons, which let us manage various websites abilities to serve ads in our browsers.

Many ad blockers include a script blocker. Like NoScript in Firefox, ad blockers may interfere with various Blogger features - such as the "Don't track" script, in the dashboard.

If you publish a Blogger blog, and you have a problem with any pages in the Blogger dashboard, you will want to whitelist "blogger.com" in your ad blocker.

You will do better if you not whitelist "blogspot.com". BlogSpot includes many Blogger blogs - and third party code on those blogs. If you are not very picky about what Blogger blogs you view, you won't do well permitting scripts on every Blogger blog.

Adblock Plus is an extension, in Chrome.

I use "Adblock Plus" as an ad blocker, on my Chrome installations. "Adblock Plus" installs as an app, or an extension.

There are several ad blockers available, for Chrome.



I use the "Adblock Plus" extension, in my Chrome installations.

Start with "More tools" - Extensions.

Select "Options" for "Adblock Plus".

Adblock Plus "options" are also accessible from the browser toolbar. Right click on the ABP icon, and select "Options".

Select the "Whitelisted domains" tab.

Let's whitelist "addthis.com".

Paste / type "addthis.com" into the box. Hit "Add domain".

And now, "addhis.com" is whitelisted.



And having whitelisted "addthis.com", I can support a useful third party social sharing blog accessory, by permitting ads that they host.

---

Some #Blogger blog owners use ad blockers in their browsers - and see problems with using various Blogger features. The Stats "Don't track", for instance, is vulnerable to ad blockers, and similar filters.

Fortunately, it's not difficult to whitelist "blogger.com" in your adblocker.
target="_blank"

Inaccessible Comments, On Some Popular Posts

Viewing comments, on some popular blogs, one may get the idea that not as many comments are being published, as are immediately visible.

With a large comment complement, comments are paginated - with some comments hidden behind a link, captioned "Load more". The "Load more" link is JavaScript based - and there is a problem.

The "Load more" link does not always work, on all blogs.

Comments on some blogs may be unreadable - with the "Load more" link not operational.

Some posts never display all comments.

Look at the bottom of the page, below the post.

And there is the "Load more" link.

And the link, as seen when one mouse over it, is shown to be JavaScript based.

And clicking on the link yields the caption "Loading ...".

And "Loading ..." never goes away - and we get no view of the missing comments.



I've seen this problem with blogs using both dynamic and non dynamic templates.

Both dynamic templates, and non dynamic templates, appear to use comments paginated behind "Load more" - and may exhibit this problem. I've seen this problem, reported in Blogger Help Forum: Get Help with an Issue, for both template types.

I have reproduced this problem, using two blogs.

Here are two recently reported cases, reproduced in my testing today. I do not know how long both cases may be active.

http://slifkinchallenge.blogspot.com/2016/05/thank-you-yehoshua-duker-and-yosef.html
https://productforums.google.com/d/topic/blogger/RotUfv8AwuU/discussion

http://istanbulkonstantinopel.blogspot.com/2014/03/study-in-turkey-2.html
https://productforums.google.com/d/topic/blogger/7Yau3KKR9mo/discussion

Noting that both blogs are (natively) published in countries that are subject to local country codes (Israel and Turkey, respectively), I will deny that to be a simple affinity - since I viewed both blogs from my browser, as "blogspot.com", as I reproduced the problem. That said, that is an interesting coincidence, no?

There are several possible causes of this problem. Adding the above observation, some of these causes may be more or less relevant.

• Comments feed setting.
• Comment feed content / corruption.
• Cookie / script filters.
• HTTPS Redirect.
• Occam's Razor.
• Post template corruption.

Comments feed setting.

Features like the comment reply option, and blogs published to dynamic templates, require a full comment feed. It's possible that comment pagination, behind JavaScript links, is similarly sensitive to the comments feed setting.

This detail will affect everybody - both blog owner(s) and reader(s) alike. And it will probably affect all posts, uniformly.

The solution for this problem would involve checking - and correcting - the comments and feed settings, for the blogs involved.

Comment feed content / corruption.

Similar to the problem with the Blogger blog post published location, it's possible that some unknown detail in the data could interfere with script functionality.

If the problem involves content in one post - or a comment on one post, it's possible that comments for one post could be affected; but other posts could paginate comments successfully.

This detail would probably affect everybody, uniformly.

The solution for this problem will require determining what feed content detail causes the problem. This will probably involve affinity diagnosis.

Cookie / script filters.

Any problem which involves a JavaScript based link, both cookies and scripts are always going to be involved. Any filter that interferes with either cookies (identity) or scripts (link functionality) will always be a possibility.

Filters may affect either blog owners and / or blog readers, uniquely. A problem that involves some owners / readers will likely involve filters.

Thanks to the effect of country local domains, cookie / script filters may affect individuals geographically.

The solution for this problem is to check / open up script filters - and then check / open up cookie filters.

HTTPS Redirect.

Both blogs, identified above, appear to not be using the "HTTPS Redirect" option. It's not impossible that this is another feature, broken by the SSL Rollout.

Occam's Razor.

Considering the most simple alternative, is it possible that paginated comments are simply inoperative? Maybe, because of (or incidentally involving) the SSL Rollout??

Post template corruption.

Comments are part of the post template. It's likely that proper comment functionality also requires a clean post template. This detail will probably affect everybody - though it's possible that there could be code that is sensitive to some owners / readers, but not others.

The solution for this problem is to reset the post template, on the blogs involved.

The bottom line.

This problem, if not incidentally solved by a Blogger code change, will probably not be diagnosed, immediately.

More examples of this symptom are badly needed. Right now, we have seen only a handful of people with blogs that are popular - and generate comments in sufficient volume - and have reported this problem.

---

Some #Blogger blog owners, who publish blogs with posts that receive large volumes of comments, report inability to display all comments published. Comments, when displayed in large volumes, are paginated behind JavaScript based links - and some links, when clicked, don't seem to work.

https://productforums.google.com/d/topic/blogger/7Yau3KKR9mo/discussion
https://productforums.google.com/d/topic/blogger/RotUfv8AwuU/discussion

Microsoft Windows Security Updates, May 2016

If you use a computer that runs Microsoft Windows, you may have been affected by Microsoft supplied updates, distributed 3 weeks ago.

May 10 was the day termed "Patch Tuesday" - the day when Microsoft releases important security related patches, to its various Internet updated products. During the 3 weeks after May 10, we've seen a significant number of security related discussions, in Blogger Help Forum: Get Help with an Issue.

It appears that Microsoft updates, for May 2016, affect use of Blogger.

The Microsoft Security updates, applied May 2016, appear to have affected various Blogger features, that are known to be vulnerable to layered security.

• CAPTCHA visibility when daily post limit is exceeded.
• Publishing comments, or replying to published comments.
• Quick Edit icons.
• Followers / Reading List maintenance.
• Stats self initiated pageviews.

All of these features are known to be affected by cookie filters, and / or by script filters.

If you are using a computer that runs either Microsoft Windows 7 or Windows 10, and you are experiencing a problem with publishing comments, or with using Quick Edit, or with blocking your own views in Stats, or similar problems, you may want to check your cookie and script filters.

I note that some of the reports mention the browser used as Chrome or Firefox. You'll want to check filter settings in Windows Security Essentials.

Being realistic, it's also possible that Microsoft broke something within Windows - but we'll have to wait patiently, for them to admit that.

If you need different or more advice, please start a new topic in Blogger Help Forum: Get Help with an Issue.

---

Microsoft released monthly security updates May 10, 2016 - and since that date, there have been a number of security filter related issues, reported in Blogger Help Forum. It appears that the the Microsoft Updates involve cookie or script filters, which affect use of Blogger.

Blogger Magic - Enabling Exceptions, In Chrome

Some blog owners and readers prefer to ignore recommendations in Chrome - and block cookies and / or scripts.

Blocking cookies can cause problems with many Blogger features - and blocking scripts will cause problems with both Blogger and with Google, and with various other websites.

If you want to use Blogger and Google effectively, you need to allow cookies to be installed, and to allow scripts to be run, on your computer.

If you cannot allow cookies and scripts for all websites, you can allow cookies and / or scripts on specific websites.

With Chrome, if you are willing to selectively allow specific websites to install cookies / run scripts, you should enable exceptions for those websites.

Start with the "Content settings" wizard.

Select "Block third-party cookies and site data", and / or "Do not allow any site to run JavaScript".



Add cookie exceptions, for specific websites.

Click on "Manage exceptions" under Cookies, to get the "Cookie and site data exceptions" wizard.

To add "google.com" as a cookie exception, paste / type "[*.]google.com", and select "Allow".

Click anywhere in the wizard window, to see the addition - then click "Done".



Add JavaScript exceptions, for specific websites.

Click on "Manage exceptions" under JavaScript, to get the "JavaScript exceptions" wizard.

To add "google.com" as a JavaScript exception, paste / type "[*.]google.com", and select "Allow".

Click anywhere in the wizard window, to see the addition - then click "Done".



Remember that cookie and script filter settings, in Chrome, may not be the only settings which you need to consider - and that many filters are subject to change, without your knowledge or approval.

For more detail about cookie and JavaScript exceptions, see Chrome Help: Manage exceptions. These are settings that you must determine and install - neither Blogger nor Google can make these changes for you.

---

Security conscious #Blogger blog owners may wish to ignore #Chrome recommendations, and block general permission for websites to install cookies and / or run scripts on their computers.

Some websites will not run properly, without cookies and scripts. If one is to use websites like Blogger and Google successfully, they need to be trusted - and Chrome must allow those websites to install cookies / run scripts.

Now, You See It - Now, You Don't

Some blog owners create a post, with content that should be visible, only when required.

The post contains a question - accompanied by the answer to the question. The question should be viewed, without the answer being visible, to make the reader think about the answer. This is called, by many, a "spoiler".

Not everybody knows how to construct a spoiler. Some blogs use JavaScript - painful to construct, and maybe not effective for every reader. Security conscious blog readers may block scripts from Blogger blogs - and either your spoiler is visible, immediately - or never becomes visible.

Neither of the latter scenarios make the post a lot of fun to read.

You don't need JavaScript, to make a spoiler.

This is fortunate, because not every reader is going to allow scripts, from every blog. Personally, I block JavaScript, in general - and enable only for my own blogs - and for specific websites, like the Blogger dashboard and most Google pages.

If the blog posts have a solid white background, you make the post text white.

Examine a post, in my text blog.

Two spoilers - both blank.

Click and drag across the first spoiler - and see the first answer.

Click and drag across the second spoiler - and see the second answer.



The spoiler code is not complicated.

What would YOU do?

What Lancelot chose is hidden. But - make <span style="font-weight:bold;">your</span> choice before peeking. To see the answer, highlight the area indicated, by clicking the mouse and dragging the cursor between the arrows.

The answer is here ==><span style="color: rgb(255, 255, 255);">Noble Lancelot said that he would allow <span style="font-weight:bold;">her</span> to make the choice herself. Upon hearing this, she announced that she would be beautiful all the time because he had respected her enough to let her be in charge of her own life.</span><==

Now - what is the moral to this story? To see the answer, highlight the area indicated.

The answer is here ==><span style="color: rgb(255, 255, 255);">If you don't let a woman have her own way, things are going to get <span style="font-weight:bold;">ugly</span>.</span>==

Hoping that your blog does not use a semi transparent floating background over a multi colour background, just make the text the same color as the background. Then, instruct the reader to click and drag the cursor, to highlight and make the spoiler visible.

---

A #Blogger blog post which contains a question and answer section is fun to read - but not every blog reader will benefit, with posts that use JavaScript, to hide text content.

An easy way to hide content is to make the text the color of the background. The reader can click and drag, to highlight the text, when then is visible.

http://blogging.nitecruzr.net/2011/10/cookies-vs-scripts-two-types-of-server.html

http://blogging.nitecruzr.net/2009/04/many-faces-of-google.html

</span>

Blogger Magic - Enabling Scripts, In Your Browser

Similar to the need to properly filter cookies in the browser, we have the need to properly filter scripts.

Cookies and scripts are completely different elements - but proper filtering of each is essential, to making many Blogger features operate properly.

If you have a problem with Blogger - either accessing / using the dashboard, or using / viewing a blog - one of the simplest things to check, complementing cookie filter settings, is the browser script filter settings.

The browser is the most important component, when setting up security - and scripts, like cookies, are a common challenge.

Script filters are adjusted differently, for each browser. Consider the multiple domains used by Blogger / Google - and layered security, on any computer, used by the owner and readers of any blog.

• Chrome.
• Firefox.
• Edge / Internet Explorer.
• Opera.
• Safari.

Setting the script filters in Chrome.

With Chrome, you enable scripts, using Settings ("Customize and control Google Chrome") - aka the 3 bar toolbar icon.

In Settings, if necessary, click on "Show advanced settings" at the very bottom of the page.

Under Privacy, click on "Content settings", which gives you the "Content Settings" wizard. Here, you have selections for Cookies and Javascript - including "Manage exceptions" for each section. Select the recommendation.

• JavaScript: Allow all sites to run JavaScript

Hit "Done" - and close the Settings tab.

From "Privacy", hit "Content settings".

Under "JavaScript", select "Allow all sites to run JavaScript (recommended)".



Alternately, you may select "Do not allow any site to run JavaScript" - then use "Manage exceptions", and allow all blog(s) that you publish, and the many Blogger and Google domains, to run JavaScript. Make your exceptions complete, for best results.

Setting the script filters in Firefox.

Firefox does not contain any native script filters. The most popular add-on for Firefox is NoScript - and this is how most Firefox users filter scripts.

You'll need to designate "blogger.com", "google.com", and any Google domain excepting "blogspot.com", as trusted - when you load any display for the domain in question. An untrusted domain will show a "NoScript Untrusted" icon in the status area at the bottom of the window. To enable each domain, you position the cursor over the NoScript icon and select "Allow (domain URL)" in the popup menu.

Setting the script filters in Edge / Internet Explorer.

With Internet Explorer, you enable security settings - both cookies and scripts - from the browser menu, using Tools - Internet Options. Optionally, you may access the "Internet Options" applet directly from the Windows Control Panel.

• IE uses a zone defense setting, where you designate "blogger.com" and "google.com", in Security, as being in the Trusted zone. Please note that "blogspot.com", in general should not be in the Trusted zone - .
• You will want the published URL of your blog(s) - including any country local domain URLs, in the Trusted zone.
• Default settings for the Trusted zone will allow proper filtering of scripts.
• Verify proper settings, with "Trusted sites" selected, and the Security level slider control set to "Medium". Hit "Custom level", and examine the Settings list.
• Look for the "Scripting" section, 3/4 of the way to the bottom of the list.
• You will observe 6 options under "Scripting". Default settings will have all options Enabled, except "Allow Programmatic clipboard access"; you may wish to Enable this to allow easy use of Post Editor.
• Hit "OK", and "Yes" if necessary, then "OK" again.

Setting the script filters in Opera.

With Opera, you enable cookies and scripts from the Advanced tab, in the Preferences wizard. The Content menu contains selections for scripting.

Setting the script filters in Safari.

With Safari, you enable scripts, using the Preferences wizard. The Privacy wizard, in Preferences, contains selections for scripts ("Cookies and website data”).

Script filters cause problems with Stats "Don't track ..." and other Blogger features.

Many problems, reported in Blogger Help Forum: Get Help with an Issue, with various Blogger features - and the Blogger dashboard - involve script filters.

Stats and the "Don't track ..." option used to involve third party cookies, for many years. In March 2016, the "Don't track" wizard was rewritten to run under the URL of the blog, when being set - and now requires enabling scripts from the blog URL.

Consider how your blog is published.

If your blog is published to "blogspot.com", consider the non "blogspot.com" alias that may be relevant to your country. If your blog is published to a custom domain, consider the custom domain URL.

Many computers have other relevant settings, which block scripts.

Many blog owners and readers will have computers, and networks, with additional protection. Scripts, in the browser, may not be the only filter that needs to be checked - but this is a start, to learning how to control the script filters.

Having checked and corrected your script filters, continue by checking browser cookie filters - then check cookie and script filters, outside the browser. Also check settings on any ad blocker add-on - which may be an app, or a browser extension.

Be aware that many settings may not be obvious - and that both obvious and obscure settings may be updated, without your intention or knowledge.

---

Many #Blogger problems are cause by overly restrictive script filters. If you, a blog owner or reader, are going to use Blogger successfully, you need to configure your browser properly - for both cookies and scripts.

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.

Owners of blogs published to custom domains will have to tweak the URL used by the "Don't track ..." Stats wizard, to set "Don't track" - since custom domains do not support HTTPS.

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.

The New Stats "Don't track" Option, And Script Filters

The new Stats "Don't track" option is an improvement, to many blog owners.

"Manage tracking your own pageviews", as before, starts from the Stats dashboard page. The wizard now runs from a sub directory of the blog managed by the dashboard - and uses a normal (first party) cookie.

Now, blog owners no longer must enable third party cookies, to make Stats ignore their page views. This is an improvement - but it can still present a challenge, for some blog owners.

Besides filtering "third party" cookies, not all blog owners and readers will permit complete control by content under the individual blogs.

If you want "Don't track" to work reliably, enable scripts for the blog URL.

If you want the "Don't track" option to work reliably for your blog, you now must enable scripts to run under the published URL.

We have to trust scripts run from "blogger.com" - that is the Blogger dashboard. The Blogger dashboard is produced by Blogger Engineers - and if we trust Blogger to host our blogs, we have to trust their code.

Scripts which run under the individual blogs - "blogspot.com", local country domains, and custom domains - can be added by the owner of each individual blog. Not all blog owners should be trusted.

People who mistrust third party cookies may also mistrust scripts which run under "blogspot" etc. Unfortunately, to make "Manage tracking your own pageviews" work, you (the blog owner) now have to open up any script filters, which block content run as part of your blog.

Start from the Stats dashboard page.

Click on "Manage tracking your own pageviews".



"Manage tracking your own pageviews" now runs under the blog published URL. This removes "third party" cookies from the problem.

With a custom domain published blog, you must use the wizard in "HTTP:" mode.

By default, the new wizard runs in SSL mode. This will be a problem, with blogs published to custom domains.

If the blog is published to a custom domain, you will need to change "https" to "http".

Check "Don't track my views for this blog." - then close the tab / window.



The new wizard, "Would you like to have your pageviews counted when you visit this blog?", now runs as "blogging.nitecruzr.net", for this blog.

http://blogging.nitecruzr.net/b/statsCookieManage

If you publish to a custom domain, and you can correct the URL, you will see the same, for your blog. If you publish to "blogspot", you can see the same also. This is a script - and the script is subject to security filters.

And yes, there is no "Save" button, or link. Just the box.

Don't track my views for this blog.

Click the box or don't. As soon as you click, it's set. If you change your mind - now or later - click the box, again, and clear the option.

You should trust your blog - even though you do not trust other blogs, in general.

Generally, as the blog owner, you can safely trust content run under your blog. You probably should not trust "blogspot.com", and all blog publishers, however. This means that you will require multiple filter rules - for every browser and security add-on, that contains a script filter.

• Block all "blogspot.*". (Please!).
• Permit "yourblog.blogspot.com".

If you publish to "blogspot.com", and live in a country which has a local domain, such as the UK, you need a rule to permit the local domain alias.

• Permit "yourblog.blogspot.co.uk".

If you have multiple blogs - and want to block pageviews from being counted, for each blog, you need permissive filter rules for each blog.

• Permit "yourblog1.blogspot.*".
• Permit "yourblog2.blogspot.*".
• etc.

If you publish your blog to a custom domain, you need a rule to permit the domain URL. For this blog, I need

• Permit "blogging.nitecruzr.net".

If you do not permit the proper URL(s) for your blog, you will find Stats counting your own pageviews. Possibly, this will happen even with "Don't track my views for this blog." checked. In some cases, the check mark will be cleared, when you close the window.

---

Owners of #Blogger blogs who don't want their activity tracked by Stats now see a new "Don't track" wizard. Using the "Don't track" option no longer requires enabling third party cookies - and worrying about the security issues.

Unfortunately, this now means that the "Don't track" wizard may now be vulnerable to filters which restrict scripts that run under blogspot, and any custom domains.

Account Owners Can't Maintain Their Reading Lists

We've been seeing suggestions, for years, that the Reading List is unreliable.

Many Blogger account owners have reported the mysterious disappearing Reading List. A few have reported a second problem - inability to remove blogs from the Reading List.

Few account owners connect the two problems. The two problems may each affect different account owners. Of the few affected by both problems, not many are likely to see them as having a common cause.

Aggressive cookie / script filters contribute to both problems with the Reading List.

Inability to identify the account owner affects using and maintaining the list.

Both the empty Reading List, and inability to remove Reading List entries, may result from inability to properly identify the account owner. Since the Reading List is unique to each account owner, lack of identification, caused by cookie / script filters, can lead to either problem.

Most account owners can recognise a problem with displaying the Reading List. This problem - even with the cause unknown - is obvious. It's not hard to recognise an empty Reading List.

What's not so obvious, though, is that an account owner, if not properly identified, can't successfully accomplish removal of a blog from a Reading List. Only the owner of the account can request removal of a Reading List entry for that account.

The dashboard Reading List - and the Followers gadget - complement each other.

The Reading List complements the Followers badge. The Followers badge, found on many Blogger blogs, lists everybody who Follows the host blog.

The Reading List, found on many Blogger account owners dashboards, list the blogs which an account owner is Following. In order to remove a given blog from the Reading List, the account owner must stop Following that blog.

You can use either a dashboard script, or a Followers GUI, to un Follow a blog.

The process for Un Following a blog starts from a link on the Followers badge, or in the Reading List. Both the link in the Followers badge, and in the Reading List, lead to scripts that are subject to cookie and script filtering.

In order for you to Un Follow a blog, using the Followers gadget on the blog, you have to identify yourself using the correct Blogger / Google account. When you remove a blog from your Reading List, you are identified by your login cookie - if the cookie is present and is readable - and if the script is allowed to run.

When the un Following is actually done will affect success of the process.

Some scripts run while the account owner is present - and those scripts may return an error message, while the account owner is watching, indicating a problem. Other scripts may run while the account owner is not present. Those scripts, when not successful because of cookie or script filters, can't display an error message, because the account owner is not watching.

In the latter case, the account owner starts the process of deleting a blog from the Reading List - and later finds that the blog was not actually deleted. And then wonders why the blog is still listed.

And this is why.

---

Account Owners Can't Remove Blogs From Their Reading Lists
http://blogging.nitecruzr.net/2015/01/account-owners-cant-remove-blogs-from.html
Account Owners Can't Maintain Their Reading Lists
http://blogging.nitecruzr.net/2015/01/account-owners-cant-maintain-their.html

Not All bX Error Codes Are Temporary

Everybody who has owned or read a Blogger blog, for more than a week, surely knows about the infamous bX codes - and has probably asked how to fix one.

Some people have fixed one - but immediately, seen another. Others have seen theirs go away, then later discovered that the blog is broken.

Some folks see the errors as major problems, others minor annoyances.

it's disheartening to see that the bx error code problems are still existing.

Not everybody realises that the codes are not the problems - they are simply a method to identify the problems. Many Blogger problems cannot be identified easily in language.

Many problems, many "solutions"
There are many known "solutions" for the codes, because there are many different problems, with many different causes. Here, we have 5 examples.

• Some codes are caused by an inconsistency in private data. These codes can generally be cleared by "clearing cache, cookies, and sessions".
• Some codes are caused by over enthusiastic template customisation. These codes can be cleared by getting a new template, or restoring the template from backup, for the blogs that are issuing the code.
• Some codes are caused by bogus custom domain addressing, for the blogs that are issuing the code. These codes can be cleared, only, by correcting the DNS addressing, for the blogs that are issuing the code.
• Some codes are caused by trying to use an unsuitable browser. Right now, Blogger does not support Internet Explorer V11 These codes can be cleared only by using a different browser.
• Some codes are caused by dodgy Blogger code. These codes cannot be solved by blog owners or readers. The bX codes, in many cases, are simply from Blogger Engineering adding "break points" into their code, so they can diagnose a known problem.

Above, we see just 5 examples. There is one rule, which you may want to consider, when diagnosing bX codes.

There are no rules, in diagnosing bX codes.

That is the plain truth.

History
Before they started issuing bX codes, Blogger would simply issue one universal error, that was incredibly annoying, to everybody seeing it.

We apologize for the inconvenience, but we are unable to process your request at this time. Our engineers have been notified of this problem and will work to resolve it.

Replacing that error, with the unique bX codes, was so simple - and elegant. The program, that issues a bX error report, simply takes the address of the failure point in the Blogger code library, where an unacceptable condition has occurred, and hashes the address into a 6 character alphanumeric code. And there is the bX code. Yes, that simple.

Blogger keeps a database listing of bX codes that are currently active, and a running count for each code. When a given code becomes more noticeable than others, an engineer simply uses the 6 character code to locate the failure point in the Blogger code library, and diagnoses the cause of the error. Fixing the code will vary, depending upon the cause of the code.

A hypothetical example
If you add an extra "<div>" tag in your template code, using the Template Editor, it's possible that the Template Editor code may detect it, and specifically advise you.

Don't add a "<div>" tag there!

In many cases, through, an extra "<div>" tag won't be noticed until you try to save the changes - or even until a reader views the blog under specific conditions. Either of the latter two cases may result in another bX code.

When you report your bX code in Blogger Help Forum: Get Help with an Issue, if other people have reported that same code, it's possible that we might have a known solution, ready for you.

Don't add a "<div>" tag, there!

In many cases, though, you will be advised to

Restore the template from backup - or get a new template from the dashbooard Template wizard.

In either case, though, the advice to get a backup or new template is not a solution - it's a workaround. The proper solution is for you to figure out what you did, that was wrong, and correct what you did.

In some cases, if we see enough of the same code, as we do now with the "bX-w7tr63", currently being reported in Blogger Help Forum: Get Help with an Issue - we may advise you.

Blogger cannot support you, using Internet Explorer, right now.

Internet Explorer V11 has too many internal changes, for Blogger Engineering to update the Blogger dashboard utilities, and remove all known problems. That may be vaguely similar to the problems where we alternately advise.

Restore the template from backup - or get a new template from the dashbooard Template wizard.

In either case, we provide most advice based on feedback from other blog owners.

Reality
Be aware that each bX code may have a different solution. Be wary of advice that simply instructs.

Most bX errors are temporary and will usually go away on their own.
You may read [FAQ] What Are The Mysterious bX Codes? and try clearing your cache and cookies.

Some errors may go away, on their own - but most require somebody to take some action. Not all that many are temporary.

Don't Password Protect A Blogger Blog

We see the signs of naivete, periodically, in Blogger Help Forum: Learn More About Blogger.

How do I require my readers to enter a password, to keep my blog safe from public view?

This blog owner does not understand the realities of setting up a private blog.

Long ago (very long ago), a computer system might have "private" files, and a shared password, known by everybody, for each file. Nowadays, a private Blogger blog uses team blog access - or team blog ownership - and each team member gets to choose her / his own Blogger account, with a password that he / she decides to use (and hopefully, remember).

Having a group shared password is fine, for a small group, where nobody leaves. What happens when somebody leaves the group?

Group shared pass codes are fine - until the group changes.

Have you ever worked in an office, where the doors are protected by a tumbler key set - or maybe combination push buttons? That's a shared password system. What happens when somebody leaves the group? Every door has to be re keyed - or the locks have to be changed.

What if the blog owner has to change the password for the blog, because somebody shared the password with a stranger - or somebody just left the group? Have you ever gotten to work, and found that your key - or assigned push button combination - doesn't work?

Have you ever had to wait for the department secretary to get to work, and give you a new key, because they changed the locks last week, while you were out of town? Have you had to anxiously search your email, looking for the message from the manager, providing the new password (here's hoping that you can get online, and your computer / phone has a freshly charged battery)?

Personal pass codes promote individual responsibility.

The personal account / password approach is so much more supportable - and it promotes responsibility. Have you ever had the manager ask everybody who came in over the weekend, and left the office in a mess?

With everybody using a common physical key, to open the door, there is no telling who comes and goes. Using individual passwords - or preferably, a card key system - you can audit employee presence, and encourage responsible attendance.

Use personal Blogger / Google accounts, for better security.

Using a personal account / password is so much better than a group shared password. Don't waste time trying to protect your blog, behind a shared password script.

Just make the blog private. Invite designated members - and let each member choose their own account / password, for blog membership.

The Blogger Dashboard, And Non Responding Scripts

We're seeing an occasional report from blog owners, trying to access the Blogger dashboard, using Firefox.

I am trying to update my blog, and I get an error

WARNING UNRESPONSIVE SCRIPT

A script on this page may be busy, or it may have stopped responding. You can stop the script now, open the script in the debugger, or let the script continue.

I'm using Firefox, and I need help here!

This has been a problem, for a few years - just a very low volume has been reported.

Mozilla Support has acknowledged the problem.

This error is telling you that Firefox thinks that a script may be running out of control and would make Firefox hang if nothing is done. The script could be something on a web page you're accessing, in an extension you installed, or even Firefox itself.

And, they provide a rather well defined procedure for diagnosing the problem.

Some problems with Firefox are caused by extensions, themes or hardware acceleration. This article will help you determine whether one of these is causing your problem and, if it is, describe how to make Firefox run normally again.

If you follow the troubleshooting procedure, you'll observe that the focus is on add-ons and extensions. The non responding problem will generally be solved by disabling programs which provide protection by examining each script, on a one by one basis. You'll end up disabling any filters, that prevent the Blogger dashboard scripts from loading and / or running.

In this case, you'll be better off knowing what security products are resident on your computer, and in your browser - and possibly, what changes have been made, recently.

Once again, this is not a problem that Blogger Engineers can fix, on their own.

>> Top

The "Reply" Option, For Embedded Comments

The option provided some time ago, to the embedded comment form, to allow "threaded" comments, is becoming quite popular.

Unfortunately, the "Reply" link does not always work. Blog owners and readers alike complain.

I click on "Reply", and nothing happens!

This problem appears to have accelerated recently, possibly resulting from the hasty rollout of the new anonymous comments CAPTCHA - but there are other less obvious possibilities, too.

The threaded comments "Reply" feature, a seemingly minor addition to the Blogger code base, can have problems with a number of issues.

• A Full Blog Feed.
• An up to date post template,
• The Google "One account" login, and cookie filtering.
• The recent addition of the anonymous commenting CAPTCHA.
• The threaded comments script, and recent script filter updates.

A Full blog feed is required.

Many blog owners are not aware that the "Reply" option won't be available, without a Full Blog Feed. Go to the dashboard, and look at "Allow Blog Feed", under Settings - Other - Site feed.

For threaded comments, you will need a Full Blog Feed (for both comments and posts) - and this will exclude private blogs.

Any "Allow Blog Feed" selection, other than "Full", will be a problem.



An up to date post template is a good idea.

Threaded comments, like every other post and comment feature, works best on an up to date post template. Any time threaded comments stops working, and you have not changed the blog feed, try resetting the post template. Now, here's hoping that you have not made extensive post template tweaks.

The identity of the person who wants to reply is useful.

Threaded Blogger hosted comments code, like threaded Google+ hosted comments, other commenting scripts, and many other Blogger features, needs access to the login cookie, to identify the person preparing to comment. Because of the use of the Google "One account" login, "third party" cookie filters must be examined.

Anything that interferes with the CAPTCHA will be a problem.

The recent addition of the anonymous comment CAPTCHA, appears to have caused some problems. This may be an matter for Blogger Engineering to correct.

Anything that interferes with scripts will be a big problem.

All Blogger scripts, including the script which services the "Reply" link, are subject to script filtering. Script filters are subject to update, on every different client computer - generally without notice to the computer owner. Always check script filters.

Blog owners and readers, alike, need to be aware of the issues, to use Blogger effectively. Threaded comments are no exception to this requirement.

The Mysterious Disappearing Reading List

One long known mystery, reported from time to time in Blogger Help Forum: Get Help with an Issue, involves the dashboard Reading List, and panic from disappearing entries.

Where are the blogs, in my Reading List?

Some Blogger blog owners and readers can spend days setting up their Reading List complement - and see their work vanish, in seconds.

One of the reasons why this problem has not been solved is that it is not reported in consistently high volume, and has no obvious pattern. Another is that many people who use the Reading List - as opposed to a third party NewsFeed Reader - are not of the highest in technological skill level, and do not have the patience to provide coherent and relevant details about the problem.

From my observation of forum problem reports, I suspect that there are at least 3 different problems, which cause this intermittent Reading List scenario.

It's likely that each problem is caused in part by the people, who depend upon the Reading List to follow blogs published by them, and by other people. Some people also publish their own blogs, while others only read blogs, using their own Reading List - and this can complicate both the diagnosis, and resolution, of the problems.

At least some of the reports of "My Reading List has disappeared!" involve three long known problems - each problem caused, in part, by the Blogger account owners who use the Reading List.

• Cookie / Script Filters, which prevent the Reading List code from identifying the reader, and displaying the personal Reading List.
• Multiple Blogger accounts, where an account owner sets up their personal Reading List while logged in to one account, and later uses a different Blogger account, with no personal Reading List setup for that account.
• Load Timeout is a problem with the Reading List assembly process, similar to timeout by the Dynamic Template assembly process.

The cookie / script filtering issue is similar to another long standing problem - Blogger Comments, particularly using the Embedded comment form. Third party cookies, which carry the identity of the person logged in to Blogger, being filtered and unavailable to the Reading List generation code, lead to the empty Reading List display. The Blogger Comments problem, like the Reading List problem, seems more common to people with lower tech skills set.

The cookie / script filters issue may also involve people who access the Internet through countries subject to country code alias redirection. People who live in the UK may not consistently update their security filters to permit cookies or scripts from "blogspot.co.uk", as they do for "blogspot.com". People who live close to international boundaries may not be aware of the vagaries of geolocation, and how their country code alias redirection may be affected, from day to day.

Another filter issue may involve recently updated filters. Thanks to ever changing security needs, and frequent unannounced updates by many security product vendors, a filter which worked yesterday may not work today. People unaware of the intrusive nature of security updates won't think to check the update log for any security product.

The empty Reading List problem can be caused by aggressive cookie / script filters, as is a similar problem - inability to remove specific blogs from the Reading List.

The multiple accounts issue is common to almost every Blogger feature. Ever since Blogger added the "Create an account" link to the Blogger / Google login screen, people have been setting up multiple Blogger accounts. Some people setup multiple accounts accidentally, and others do so on purpose.

If you combine the "Create an account" link with the ease of setting up a non GMail based Blogger account, you see that many people who don't use GMail can easily setup a new Blogger account without realising what they are doing. The owner of a new account, newly able to login, finds an empty dashboard. People who use the Reading List, purely to Follow other peoples blogs, will not be interested in the empty "My blogs" list, and will simply observe the lack of entries in the Reading List.

Other people setup additional Blogger accounts intentionally, to host different blogs under different accounts. People who intentionally segregate their blogs may not understand the similar personal nature of the Reading List.

Cookie / script filters can also block the contents of the Google "One Account" display from being properly generated - and may similarly contribute to creation of multiple accounts. The "reflexive action" design of the "One Account" display also contributes to use of the wrong account, in multiple account situations.

Both aggressive cookie / script filtering, and use of multiple Blogger accounts, can lead to lack of proper identification of the Blogger account owner - and to an empty Reading List.

The load timeout issue is similar to Dynamic Template load timeout. If you have any interesting assortment of feeds, in your Reading List, clear cache, cookies, and sessions, restart the browser, and login to Blogger. Immediately, scroll to the bottom of the screen, and watch the Reading List on your dashboard.

The list will, initially, be completely empty - then suddenly, it will fill with some number of posts, instantaneously. This is the same way a blog displays, in a dynamic view.

The various feeds in the Reading List have to be merged, so the individual posts can be displayed in proper sequence - in the same way that the components of a dynamic template display are assembled. This will make the Reading List display vulnerable to intermittent local and network problems, as the dynamic templates are vulnerable.

Different client computers will be differently vulnerable to load timeout, because of details like differing reading list content, individual network problems, and individual local computer problems. Reading List load timeout will have the same effect as Dynamic View load timeout - no display. This will be a truly intermittent problem.

Besides the inconsistent and intermittent load timeout, we'll see consistent errors, like the empty Reading List - and the mysterious lack of ability to remove Reading List entries.

All of the above issues are caused, in part, by the Blogger account owners. Blogger Engineering has worked for many years to solve the problem of cookie filtering and commenting, in vain. I suspect that they have also worked on the Reading List display problem, with similar result.

As long as people use their own computers, with security components of their own choosing - and neglect to consistently use the same Blogger account - Blogger is never going to solve the problem of the empty Reading List. The panic will never go away.

Thanks to the Google "One account" login, as Blogger is made a way of life to more of a reader population who have no interest in maintaining security on their computer, these issues will become more problematic.

Blogger Browser Support, And Layered Security

The official Blogger browser compatibility reference, Compatible browser and operating systems states Blogger requirements, very succinctly.

To use Blogger, your browser must allow cookies and have JavaScript turned on.

This is a very brief hint of Blogger browser support policy.

Use of Blogger includes various activities.

• Moderate Blogger hosted comments.
• Post comments, as a blog reader.
• Edit, preview, and publish posts.
• View Stats.
• Use the Template Designer.

Each of these activities, and more, require cookies and scripts - and each are vulnerable to improperly setup filters.

As Blogger implies, both cookies and scripts are vulnerable to being disabled (turned off) - although the term "turned on" suggests that there is one single setting, possibly affecting each individual cookie or script. Considering the effects of layered security, we know this won't always be true.

Layered security can include settings in multiple components.

1. Native browser settings.
2. Various browser add-ons, extensions, and plugins.
3. Security accessories, installed on the computer, outside the browser.
4. Network appliances, installed outside the computer.

Any of these accessories and components can have filters, which can block cookies and / or scripts.

Filters are serial in nature. If any one filter blocks a necessary cookie or script, that cookie or script becomes unavailable to the Blogger feature in question.

• You can't moderate Blogger hosted comments.
• You can't publish a comment.
• You can't publish a post (use Preview).
• You can't view Stats (or exclude your own pageviews).
• You can't use the Template Designer (or Live Preview).

Each JavaScript filter can affect a small portion of one Blogger feature. Sometimes, the feature will load, then terminate with another infamous "bX code", or a monolithic error message. Other times, the feature may not even load, and you get a blank screen.

As noted several times, just because it worked yesterday, that does not mean that it will work today. Every filter is subject to update, by its creator. And both BlogSpot published blogs, and non BlogSpot published blogs, are subject to different, and ever changing filters.

>> Top

Comments And Layered Security

One of the most common complaints, seen regularly in Blogger Help Forum: Something Is Broken, involves publication and visibility of comments.

Why can't I publish comments, on some blogs?

or

Why can't I see my comments, after I publish them?

or even

Why do my blog posts show no comments?

These are questions asked by blog readers and owners, alike. The answers all start with security filters and settings.

Security filters and settings affect the ability for you, and your readers, to use commenting, on your blog.

Comment Form Style

The majority of the problems, with commenting and filters, involve blogs which use the Post Page ("Embedded") comment form. Use of the embedded form requires third party cookies, on the reader computers.

The Full Page form is least vulnerable (though not totally so), of the 3 form styles. Embedded, Full Page, and Pop Up comment forms are all vulnerable, to differing extents, because of the different blogs, that attract different reader populations, each with differing abilities and needs to maintain security on their own computers.

The problems with comments involve the clients (ie, the blog readers), their computers, and their choices, reacting to the options chosen by the blog owners.

Security Accessories

Every different computer, accessing the Internet, has a different combination of security accessories. Every different security accessory will have its own filters - and be subject to updates, by the provider. And every different filter will be triggered, from time to time, by different components in the various Blogger (and Google+) comment scripts.

The commenting process - and accompanying security problems - involves many different details, besides comment form placement.

The blog URL, and the geographical location of the reader, will trigger filters. Both blogs subject to country code alias redirection, and those using custom domain publishing, will be affected by filters, in different ways. Both involve blogs not accessed as "blogspot.com".

Commenting Options

Authentication options, which are selectable by the blog owners, will vary.

• Anyone (no authentication required).
• Google / OpenID account.
• Google account only.
• Blog members only.

Within those 4 levels of authentication, the blog reader will have 1 to 3 choices. Each of those choices (by the blog readers), combined with each of those options (chosen by the blog owners), will involve different sections of code.

Besides the authentication choices and options, there are options (for the blog owner) to include CAPTCHA verification, and to include comment moderation and notification. Again, different sections of code will be involved.

The different sections of code involved will trigger different filters.

Comment Moderation

Besides the per blog choice to include comment moderation, the real time per comment choice of the blog owner, is to publish (or not to delete), or to not publish (or to delete) any given comment. This filter leads to the subject of community moderation, and training of the collaborative and heuristic filters, for Blogger hosted comments.

The community moderation filters provide automatic moderation of Blogger hosted comments - and the need for active moderation, by the blog owners.

Google+ Comments

The choice of Blogger hosted comments, vs Google+ hosted comments, provides one more option, to the blog owners.

Blogs which use Google+ hosted comments use community moderation, and free the blog owner to spend more time on blog content. Google+ hosted comments provide real time relation based filters, where the publisher of any comment can designate who will be allowed to view the comment, providing filters which are relevant to the comment publisher.

Cookies and Scripts

Each separate section of code can trigger different script filters - and may require different cookies, which may or may not be present and accessible to the Blogger scripts. Both cookies and scripts are essential parts of Blogger code, which are vulnerable to different security filters at different times.

The mysterious vanishing comments is just one consequence.

Use Of Supported Browsers And Computers

Some people prefer to ignore the crowd, and to use browsers and operating systems that nobody else knows about.

Individuality is good, in general - but in the world of web applications such as Blogger, use of unsupported browsers and computers may bring frustration. Blogger simply can't support all browsers and computers, with equal attention to the oddities presented by each one.

The End Result

The various filters involved cause comments to be published (or not), to remain published (or be deleted), and to be visible when published (or invisible). Many of these details are transparent, to the casual blog reader - until there is a problem.

These details may help to explain the apparent random nature of Blogger blogs and commenting - why comments, posted to some blogs, appear without problem - while comments, posted to other blogs, may never appear, or be invisible.