Some blog owners report a problem with editing posts, in post editor.
With any changes made to a published post, an attempt to update shows another monolithic error.An error occurred while trying to save or publish your post. Please try again.
But the mystery does not end there. Even seeing the error, a curious blog owner, refreshing the post as displayed, may find a surprise.
Even with the mysterious error displayed, repeatedly, the changes just made may be visible in the post.
In some cases, a new post editor session - or the post display refreshed - will even show the changes made.
Even with the post editor showingAn error occurred while trying to save or publish your post. Please try again.
you may see your changes displayed, when you refresh the displayed post.
I just updated my earlier post, Country Code Aliasing Is A Solution - Not A Problem.
My personal and recent experience.
The post, before being updated.
I added the observation to the postBlogger has described the problem, as a solution to free expression and controversial content.
to the post.
I just updated my post.
Post Editor, showing the added observation.
Then, I clicked "Update" - and waited for an eternity. No matter how many times I hit "Update", I see the same error.
It's enough to make one pull hair, in anguish (as if, Chuck!).
Post Editor, showing the added observation, after clicking "Update".
But, the story does not end here.
The post, after being updated - even with the bogus error message displayed.
Surprise! See the added observation?
Don't believe me? Examine my post, Country Code Aliasing Is A Solution - Not A Problem.
If you see the error, don't give up!
So, if you edit your post, and having made the necessary changes, you see the bad newsAn error occurred while trying to save or publish your post. Please try again.
don't pull your hair in anguish, immediately.
Refresh the post - then examine the updated display, and the change just made (in a separate tab / window). You may find your changes saved, as if nothing is wrong.
And, it's the EverReady Bunny problem of the week.
I was once again, updating my previous post, and idly wondering if this problem had been fixed - and hello!
Post Editor, showing this error, after clicking "Update" - just as I updated my previous post.
My previous post - updated, even with Post Editor displaying the error!
This, too, may involve the Blogger / Google CDN - and delay in updating the Blogger database, between the nodes in the CDN.
Just be careful when closing the post editor tab or window, with the warning about unsaved changes displayed.
So, what to do, now? I couldn't even leave that window, to update this post - I had to Stay!
And having updated this post, in this window, I have to close that window, with the changes maybe unsaved. But I'll re read the post as displayed, first.
If you see a mysterious #Blogger Post Editor error "An error occurred while trying to save or publish your post. Please try again.", when trying to update a previously published post, repeatedly, take a moment and verify that the changes being made were NOT saved. You may be surprised!
This, too, may involve the Blogger / Google CDN - and delay in updating the #Blogger database, between the nodes in the CDN.
Recently, we've been seeing queries from some anxious blog owners
Why should I have to sign out a total of three, four, or more times?
With blogs that use a template that shows the navbar, the owner may logout, using the "Sign out" link - but the navbar may continue to suggest that they remain loggedin.
This problem may start with how we connect to Blogger, as part of the mysterious Internet cloud.
Blogger provides multiple connection points ("nodes") to their databases, through the Blogger / Google Content Distribution Network ("CDN"), in many different cities worldwide.
Generally, a blog owner will connect to Blogger, using the closest CDN node. Thanks to Internet Protocol networking with Multipath Routing, the "closest" node won't always be the node with the shortest distance, "as the crow flies", from the owner.
Determining logical distance between 2 computers involves more detail than simple geographical distance. Some blog owners will be equally "close" to multiple nodes - and this is where the problem starts.
All Blogger databases, in all CDN nodes, won't update immediately.
If a blog owner logs out from Blogger, when connected to one node, the Blogger database in other nodes won't always be updated immediately, to reflect the log out status. The CDN nodes update each other periodically - and there is always going to be some delay between updates.
The logical distance between a blog owner and a nearby node can change - and a different node may become "closer", at any time. With multiple nodes equally "close", the slightest change in the network between the blog owner and any "close" nodes can make the blog owner connect to a different node. The blog owner can fluctuate between 2, 3, or more "close" nodes, within seconds.
If the blog owner logs out while connected to one node, then re connects to a second node - before the first node updates with the second - the owner will appear to be still logged in.
Different CDN nodes may show a blog owner as logged in, until updated.
In some cases, the owner can continue to appear as "logged in", when connected to a different node. After logout (log out, signout, sign out) using the "Sign out" link, and the display refreshes, the navbar status will continue to display the account name and "Sign out" link.
Some blog owners will be equally "close" to multiple nodes. They may go through 2, 3, or more sign outs - until all nearby nodes are properly updated, or updated by repeated "Sign out".
Long ago, update delay led to a different mysterious problem.
Long ago, blog owners reported the mysterious advice
You have logged out from another location. Do you want to log in again?
Now, they continue to see the navbar "Sign out" link.
This monolithic error used to make many scream, in anguish.
Previous advice, to workaround the mysterious "You have logged out from another location. Do you want to log in again?", may work for the logout problem.
- Check cookie and script filters.
- Clear cache, cookies, and sessions (yes, all 3).
- Restart the browser.
- Click on the link below, to login to Blogger.
https://www.blogger.com
A similar example of CDN node update delay involves post editor / template editor.
I see this problem currently, when updating posts. I update my posts, frequently - and see this error message, almost daily.
An error occurred while trying to save or publish your post. Please try again.
Post Editor, showing another monolithic error, after clicking "Update" - just as I updated this post.
There's nothing to do now, but hope for the best. The above procedure may or may not fix this problem.
Template editor will be subject to the same frustration. Any Blogger dashboard change that involves significant delay between opening and saving changes (such as editing) will have a similar problem potential. And here may be one more detail that affects stability of long term draft mode post editor sessions.
If you connect to multiple CDN nodes, while you update a post or edit a template, you end up with "conflicting edits". How should we expect the different database nodes to update each other, consistently, with different edits made to the different nodes?
Some blog owners connect through nodes in different countries.
With "nearby" nodes in different countries, it's possible that country local domains, affected by intrusive cookie or script filters, can complicate this problem. A cookie or script filter can prevent the "Sign out", until the blog owner is connected to a node in a different country.
A cookie or script filter can be a part of many network, performance, or security accessories, on the computer or network. Some filters are updated without knowledge of the blog or computer owner.
Network connections may change in milliseconds.
Multipath routing can cause network connection changes within milliseconds. CDN node updates won't be that frequent. Impatient blog owners may observe the lack of update from "Sign out", and report the problem.
Why would I have to sign out a total of three or more times?
No matter where Google locates their many nodes, some blog owners will be equally "close" to multiple nodes - and their connections can change frequently. The more equally "close" nodes, the more random path changes, and the more this problem will be seen, by different blog owners. Other blog owners won't care, because they may never see this happen.
The new "Responsive" templates may serve as a solution.
The new, "Responsive" class templates lack the navbar, and "Sign out". Blog owners, who publish their blogs to the new templates, won't use the "Sign out" link in the navbar - and they will not observe the delay in CDN node updates.
Some blog owners report that after logging out from #Blogger, the navbar continues to show that they remain logged in.
Thanks to the Blogger / Google Content Distribution Network, where an owner can connect to any of many different nearby CDN Nodes, this will probably always be with us.
One of the most obscure Blogger error messages - next to "Another blog ..." - is the monolithic advice seen on main page display of some blogs.
No posts.
or maybeThere's nothing here!
What can you say, to a blog owner who has started a new blog, and spent days publishing blog content - only to view the blog, and see "No posts." - or "There's nothing here!"?
In some cases, a blog may actually contain no posts - even after days spent publishing content.
Some blog owners may confuse pages ("static pages"), and posts ("dynamic pages") - and spend days publishing blog content, as static pages. Other blog owners, though having just started their first blog, may be experienced webmasters with one or more websites published for years - and publish blog content as pages, by preference.
Whether owned by a true newbie, or an experienced webmaster, a blog which is constructed using static pages will display the main page as
No posts.
or maybe
There's nothing here!
By default, the main page display will only show posts. Pages were originally provided, as a Blogger feature, because some blog owners wanted some posts that were not indexed in an archive, label, or main page sequence.
When you are queried by an anxious blog owner
Why does my blog display
No posts.
Where are my posts?
What can you do?
You need to compare "sitemap.xml" and "sitemap-pages.xml". In some cases, you'll find "sitemap.xml" to be empty - and "sitemap-pages,xml" to list static pages. Occam's Razor wins again.
Some blogs may be truly empty.
Some blogs will only have pages for blog content - and no posts.
Some blogs will only contain static pages - and the main page will show "No posts.".
If your blog does this, you can redirect the home page to a given static page - and add links between the static pages. Or, republish the pages as posts, if convenient.
If you want a main page with multiple posts, maybe using Jump Break to make the main page look cleaner, you will have to publish your blog content as posts.
The monolithic error "No posts." causes extreme anguish, to a #Blogger blog owner who has just spent days publishing content. In some cases, there is a simple explanation.
I recently updated an old post, to add a link to a newly published post - and experienced panic.
Adding a link to an old post, Deleted / Locked Blogs Have Several Causes, I discovered an oddity which caused extreme heartburn for several hours. Maybe you have experienced this, also.
Editing my post, and adding a simple single sentence, with embedded link, at the end of the post, I refreshed the display (always test your changes - no matter how minor!), and watched as the paragraphing scrambled itself.
I added a single sentence to the end of an old post - and watched as paragraphs in the post became hopelessly scrambled.
See the missing "</li>" at the end of the first list element?
Look at how the list line spacing is screwy now.
<li><a href="#DMCA">DMCA Violation</a> looks for copyright and similar violations.
Just one missing tag. Long ago, I learned to always close every list element properly.
<li><a href="#DMCA">DMCA Violation</a> looks for copyright and similar violations.</li>
But my proper list syntax policy had apparently started after the post, in question, was published.
I spent the next 1/2 hour re paragraphing the post content, following the broken list - and re spacing the list itself.
And having saved my work, the list - and the paragraphs following the list - remained scrambled.
This is no good!
How can I hope to help people, using this post?
Observing that paragraphing above the broken list was fine, I looked at the list code, line by line.
Paragraphing above the list is OK!
Much to my relief, I found a missing "</li>" tag. Adding the missing tag, I re paragraphed the post content - and this time, my changes remained.
This is what I would want to see.
Even the list remains properly spaced, in post editor.
Be very careful, when editing lists, in post editor "HTML" mode. Lack of care can lead to unpleasant consequence.
When editing a #Blogger blog post, in HTML mode, be very careful to avoid dropping closing list element tags. One dropped tag affects formatting of list content after the missing tag - and paragraphing following the broken list, even with the list properly closed.
target="_blank"
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.
- The Template Designer page.
- The Template page.
- The Template Editor ("Edit HTML") page.
- 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.
- Backup / Restore the existing template.
- 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.
- Backup / Restore the existing template.
- 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.
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.
- Social sharing activity will cause confusion.
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.
Social sharing activity will cause confusion.
Blog owners who use social sharing services for community building - and who follow activity in their stream - will observe various inconsistencies. Both inflated counts, and deflated counts, will be perceived, when reconciling stream activity and blog visitor counts.
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.
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 toRestore 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.
We're seeing the occasional evidence of concern, in Blogger Help Forum: Get Help with an Issue, from people who spend too much time examining their StatCounter logs.Why do I see "62.210.181.15:3130", in my StatCounter logs, as a referring site - reported as unknown "pool IP proxy" - and showing full BlogSpot.com and other sites' content?
This sounds scary - but it's not.
"62.210.181.15" is an unregistered proxy server address. It's like me calling myself "nitecruzr".
Google for "free proxy servers", to find such IP addresses listed.
Look for online advertisements (Google is your friend) for proxy servers. You'll see suggestions like "Surf from class, without interference". "62.210.181.15" is probably listed, in one of the suggestions.
"62.210.181.15" is probably some kidz, setting up an old computer, connected to their Mom's Internet service. Some old computers, useless for gaming, can be refurbished - and used as proxy servers. That's a popular activity, for geeks.
Unregistered proxy servers make sense, for various reasons.
By advertising only an IP address, the owners of the proxy can- Save money (no name registration, which generally costs money).
- Prevent name based filtering by the school network admins.
- It sounds kewl, and attracts more skool kidz.
So, all the kidz in one skool tell each other Yeah, so what if the admins block FaceBook, just go to "62.210.181.15", and surf from there!
That's all that it is, just people bypassing network security, at the office or school, and surfing. You see the entries in your logs, because they are surfing your blog.
Proxy servers make good tools, when you need to vary your apparent geographical location (for testing). If you're going to use one, just use it for read only surfing.
Only use unregistered proxy servers for insecure, read only surfing.
Internet activity that requires a password and userid (FaceBook, Google+, Twitter) will use SSL - and most free proxy servers do not provide an SSL connection. In no way would I ever use a proxy server, without SSL, and enter anything confidential or secret.
If you use a proxy server for publishing comments on a Blogger blog, for instance, you'll be publishing anonymous comments, because you won't be able to login to Blogger.
The ":3130" changes for every connection, because each number there is used by each different customer of the proxy. Those are outgoing port numbers, on the proxy server.
Get back to work, on your blog.
Sometimes, when diagnosing a problem which involves cache, you may be advised to "clear cache" - or possibly, "clear cache, cookies, and sessions".
Instructions, to do either, may vary according to the problem being diagnosed. Unfortunately, clearing "cache" or clearing "cache, cookies, and sessions", for problems which involve cache, may not always solve the problem at hand.
If you have a problem when viewing your blog - or if you wish to immediately refresh your personal view of your blog, you might clear "cache". If you have a problem with your Blogger dashboard - maybe when switching between Draft and Production Blogger, on the other hand, you would want to clear "cookies". Whenever you clear cookies, you should clear cache, also - so, if you have a problem when maintaining or publishing your blog, you will be advised to clear "cache, cookies, and sessions".
Not all problems involving "cache" will always be solved by "clearing cache" - or even "clearing cache, cookies, and sessions". Clearing browser cache won't help, if the problem involves- cache outside the browser being used
- cookie or script filtering
Clearing browser cache won't help, if the problem involves cache outside the browser being used. When you clear cache, you are clearing cache in one individual browser.- If you have other browsers, or other computers, you may have to clear cache there, also.
- You cannot control cache, outside your computer.
- You cannot control cache, on your reader's computers.
There is no permanent solution, for upstream cache. But, there may be a diagnostic step, that helps us understand what is going on.
This is the URL of this blog.http://blogging.nitecruzr.net/
If I need to access the main page, without refreshing the browser, or clearing cache, I can retrieve the updated content, on a temporary basis.http://blogging.nitecruzr.net?
A URL containing a "?" is normally used for retrieving a web page, dynamically, with extra settings embedded in the URL.http://blogging.nitecruzr.net?something
A dynamic retrieval is evaluated immediately, using the Blogger server (in this case) - and without any interference from any caches.
Even without a real need to have the URL evaluated by the server, we can still make the URL dynamic, just by adding the "?" at the end. And this bypasses any cache - including cache upstream from the browser.http://blogging.nitecruzr.net?
Just remember - this is a temporary solution.
Clearing cache won't help, if the problem involves cookie or script filtering. If you clear cache when diagnosing a problem with the Blogger dashboard, a problem with commenting, or any other problem which requires logging in to Blogger, you will need to clear cookies and sessions, at the same time. This won't always be successful, even so. If a problem starts from improper filtering of private data, you won't solve anything by clearing private data.
Cookies, needed when viewing a Blogger blog, are vulnerable to "third party" cookie filters.- A preference cookie (aka "cookie") is created under "blogger.com", where an interstitial display runs.
- A session cookie (aka "session") is created under "google.com", where you login.
Both types of cookies are read under "blogspot.com" - or under whatever custom domain, or whatever country code alias, is being used by the blog, as displayed.
Whether a cookie is needed, but non existent - or needed, but can't be read - the result is the same. The reader is unable to continue, and does not get to view the blog, when necessary.
If a problem which appears to be caused by out of date cache is actually caused by a cookie filter, and you clear cache, cookies, and sessions, you won't solve anything. A cookie, wrongly filtered, will continue to be a problem, even with cache cleared.
If a reader is subject to a filter that blocks "third party" cookies, and a preference or session cookie is needed, the reader will be unable to continue. This is a condition that Blogger Engineers cannot program around, because it is part of the security code, in the browser - and helps to protect us from malicious activity, when we surf dodgy websites.
The bottom line is you need to know when to clear cache (and cookies and sessions), in your browser - when you need to clear cache, elsewhere - and when you need to check your cookie and script filters. None of the 3 makes either of the other 2 redundant - advice given in Google - Blogger Help: Fix a Blogger error notwithstanding.
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.
I've been using affinity analysis, and differential analysis, as tools for diagnosing intermittent problems with custom domain published blogs, for several years.
Some people may be using a browser which is more forgiving of DNS problems than others - and people who use the right browser, when accessing a domain with righteous DNS addresses, should expect to generally get more consistent service. But that's only a small part of the story.
DNS is the basis for custom domain publishing - and DNS is used in a number of ways. This creates a number of bases for inconsistencies.- Inconsistencies From The Browser
- Inconsistencies From Individual DNS servers
- Inconsistencies From Large ISP DNS Servers
- Inconsistencies From The Google Name Servers
- Inconsistencies From WorldWide DNS Services
- Inconsistencies From The WorldWide Internet Infrastructure
The Browser
Some browsers, if they have a problem getting an IP address for the domain root (using the 4 x "A" servers) may automatically use the "www" alias.
If your domain provides only 1 x "A" address, it may be more susceptible to problems, when this aliasing of the domain root and "www" host are in use - since an outage which involves 1 "A" server may be more common than an outage which might involve all 4 x "A" servers simultaneously.
If your domain is not setup with both the domain root and "www" host properly addressed - or if the domain root to "www" host redirect is not enabled, the domain may not perform consistently.
Individual DNS servers
No people (you, or your readers) access the domain registrar's servers directly, to get the address of your domain. You use "local" DNS servers - the DNS severs provided by your ISP (or maybe a custom third party service like like GoogleDNS or OpenDNS). The "local" DNS servers that you use retrieve DNS addresses from the "authoritative" DNS servers provided by the registrar. The registrar servers reference the 4 x "A" / "CNAME" servers, provided by Google, using "referral", to get the address of your blog.
The servers that you use only access the registrars servers periodically, thanks to DNS cache. That's the mysterious TTL, which your domain's authoritative DNS servers specify. If the address for your domain is in cache, on any local DNS server, and cache is not expired (the address was retrieved any time in the previous TTL period) the local DNS server that you use simply issues what it already has.
Since almost every different reader of your blog uses a different "local" DNS server, you're going to see inconsistency in problem reports, from your readers.
Large ISP DNS Servers
If your domain is popular, people accessing your domain from a large ISP - or an ISP that is close to you geographically (if your readers are geographically concentrated) - is more likely to have the DNS addresses, for your domain, in cache. In this case, no retrieval from the registrar's servers will be necessary. The higher the TTL, the greater the chance this will be the case.
The Google Name Servers
If your readers are accessing your domain using the "www" alias, they are using the "ghs.google.com" name server for accessing your blog. The design of "ghs.google.com" means that everybody on the Internet, accessing any Blogger blog published to a custom domain, uses the same DNS addresses, cached locally. This too means that large ISPs - who are more likely to have somebody (if not you) accessing some Blogger blog published to a custom domain - are more likely to have the address for your blog in cache.
Your blog, and your domain, are addressed separately, and require separate DNS servers. This is why a righteously addressed domain uses "CNAME" referral, when mapping your domain to your blog. And this is why you have to purchase (or setup) DNS hosting, when you register your domain.
WorldWide DNS Services
Some of the 4 x "A" and "CNAME" servers, provided by Google, are not completely unique. Many large DNS infrastructures - like those provided by eNom, GoDaddy, and Google - have "unique" IP addresses replicated worldwide, using "Anycast DNS". This feature can sometimes create regionally concentrated outages, with some domains - as we have seen periodically, with eNom.
The WorldWide Internet Infrastructure
The combinations of browser used, domain popularity, ISP size (customer population), and regional outages, will always cause discrepancies between domains, and people in different locations and using different ISPs. What you (one person) see, where you are, may be completely different from what one of your readers (or my readers) sees, when using a different ISP, in another country, and a different browser.
Thanks to the transient nature of IP networking, you may "test" or observe problems over minutes or hours - but many DNS problems can appear and disappear in seconds. That''s in spite of what you would expect from cache / TTL latency.
All of these seemingly insignificant details, when fully understood, may help to explain why I continually insist on using righteous DNS addresses, whenever a custom domain publishing problem is encountered. Righteous addresses won't necessarily solve all of the above problems - but it may eliminate some of the inconsistencies, and make it possible that we could, eventually, diagnose the problem.
>> Top
We get occasional odd problem reports in Blogger Help Forum: Something Is Broken about mysterious display oddities.
Why is my sidebar vibrating?
Here I'll note that the problem about "vibrating" has been reported, using various synonyms - in different syntaxes.
This symptom has many possible phrasings, as mentioned in different forum problem reports.
- Dancing.
- Jiggling.
- Jumping.
- Leaping.
- Moving.
- Shaking.
- Shimmering.
- Trembling.
- Vibrating.
- Waving.
- Wiggling.
Identifying the words used, in the problem reports, is one challenge.
The problem appears to involve the Followers gadget (possibly, specific versions of Followers), being positioned at the top of the sidebar, above other accessories.
One can only wonder what terms are used, in non English speaking countries.
This problem is not easy to identify in quantity, because of the many different synonyms used - and with some synonyms used, in different syntaxes.
Why does my sidebar vibrate?
or
My sidebar vibrates!
instead of
Why is my sidebar vibrating?
for one example. This makes any forum text search, to look for similar reports, require multiple, exhaustive attempts.
The list of 11 words, above, is just a list of examples, alphabetised (as I do with most lists). I have seen all 11 words (33 possible syntax combinations), and more, from time to time, in various blog comments, blog posts, and forum questions.
Positioning of the Followers gadget can affect multiple template gadgets.
Some blog owners have positioned the Followers gadget above the posts column - or even beneath the blog title / description (and spread across the entire blog width). This will make the posts column - or even the posts / sidebars (the entire blog width) - subject to this effect.
The problem appears to involve the Chrome (possibly Safari too) browser - and is visible only at specific Zoom levels.
If you see this problem when viewing someone else's blog, try zooming in or out, and see if the problem persists. Chances are, it will stop. Also, try using a different browser.
If you see this problem when you are viewing your blog, try repositioning the Followers gadget lower in the sidebar. Observe what gadgets are positioned below the Followers gadget, as you move the gadget downward.
A few times recently, we've had reports, in Blogger Help Forum: Something Is Broken, of mysterious text, appearing in the middle of the posts.How do I remove unwanted text appearing in the middle of the page?
Frequently, all that we can see is a mass of text.
Occasionally, the mysterious text has been readable. Extracting key phrases from the text, we can some times locate the source of the mysterious text, in the post code.
Having located the mysterious text, we are no smarter than we were just previously, however.
The mysterious text. In this case, the text is simply unreadable.
In some cases, we've been able to read the text. A text search, in the source code for the page, might turn up this snippet of post HTML code.
<div id="stcpDiv" style="left: -1988px; position: absolute; top: -1999px;">
The project sees local artists joining forces with the University’s smart material researchers to work with local community groups to explore, create and design different applications for smart materials - See more at:
http://www.bolton.ac.uk/MediaCentre/Articles/2013/Feb2013-3.aspx#sthash.JEpPZWbT.dpuf</div>
stcpDiv
The key phrase in the code snippet appears to be the div id, "stcpDiv".
A Google search turns up a few discussions about the mysterious text. It appears that "stcpDiv" is part of a copy protection technique.STopCoPyDIV
Apparently, this allows source websites to publish content with metadata - the equivalent of a non visible watermark - linking back to the source, when content is copied to another website.
To resolve this, you have to edit the post which contains the "stcpdiv" code in Compose mode, and use the "Remove formatting" tool. Then reformat the entire post.
Alternately, edit the problem post in HTML mode, and find and remove all "stcpdiv" code - one section at a time.
And in the future, never copy formatted content from a protected website.
This is yet one more reason why copying formatted text is not a good idea. If you must copy text, copy it unformatted - then re apply formatting, as necessary, after copying.
One of the more intriguing subjects of confusion, about feed gadgets, involves gadgets with more feeds in the list then they are set to display.
Occasionally, in Blogger Help Forum: Something Is Broken, we see the petulant queryWhy does my blog disappear from (feed gadgets on) other peoples blogs?
This confusion starts with the question of how often and when we update our blogs, as opposed to how often and when the other blog owners update their blogs. It continues with the little known effect of the difference between how many feeds are in the gadget list, as opposed to how many feeds the gadget is set to display.
A gadget which has 10 feeds in the list, but is set to display only 5 feeds, will display the 5 most recently updated feeds.
A feed gadget will display only the count of feeds that it is set for.
The other 5 feeds will not display - and since the display order will vary according to date last updated, so will the set of feeds displayed. As different feeds are updated irregularly, they become the 5 feeds displayed. The other 5 feeds, updated less recently, will seem to disappear from the display.
This blog has a BlogList with 6 entries (currently) - but set to display the 5 most recently updated feeds. There will always be 1 feed which does not display - and the missing 1 feed, at any time, will be the least recently updated.
Look in the sidebar, for the gadget labeled "THE REAL BLOGGER STATUS - POSTS". Below that gadget, you'll find an unlabeled feed gadget, displaying feeds from 6 different blogs.
What displays, over time, will vary - depending upon recent updates.
If you watch this blog over a period of days or weeks, you'll see 5 feeds display, in an occasionally changing sequence. That sequence, seemingly random, will reflect the 5 feeds most recently updated - and the 6th feed will seem to disappear.
If you are an owner of one of the blogs which are featured, in that feed gadget, you may be occasionally asking yourself
Why does my blog seem to disappear from The REAL Blogger Status, from time to time?
The disappearance will not involve your imagination - just how often you update your blog, compared to how often the other blog owners update theirs.
You can look at the gadgets on your blog - and see the effect on your blog.
Look at the various BlogList and Feed gadgets, on your blog. Do any of your gadgets have a list that's longer than the display number? It's perfectly valid to do this - but if you are doing this, consider that somebody who publishes one of the blogs, that you've featured in your gadget, is occasionally asking himself
Why does my blog disappear from (your) blog?
Occasionally, we see the query, in Blogger Help Forum: How Do I?How do I change these captions? / Add this feature? / Remove specific components of this feature?
Conversely, we see in Blogger Help Forum: Something Is BrokenWhy does this new Blogger feature not work in my blog?
These questions, in many cases, may be related. We can see the connection, when we look closer at how the changes are applied.
Many changes to our blogs, that are part of the comments / posts / post header / footer, are made in the post template.
The post template is an unobtrusive section in the blog template, that lets us change the blog template as we wish - while allowing Blogger to update the comments and posts code, as they add new features, or update existing features.
Blogger lets us change the post template, using "Configure Blog Posts".
Blogger provides the "Configure Blog Posts" wizard - and lets us change specific features in the post template.
The options in "Configure Blog Posts" do not satisfy everybody - and here is where many problems start. Some blog owners want features or selections that are not provided by "Configure Blog Posts" - but are part of the post template.
Some features have to be installed as post template tweaks.
To install these features, the blog owner uses the Template Editor, and tweaks the "Blog1" template widget.
Once the post template is tweaked, by the blog owner, the blog has a non standard post template. When Blogger applies their next post template update, to install or update a Blogger supplied feature, against a blog with a non standard post template, they have 3 options.- Overlay the entire post template, with their updated post template. The blog owner sees all tweaks previously made, suddenly vanish. Some of the owner applied features simply disappear, others stop working - with no explanation or warning.
- Overlay specific portions of the post template, with their updated post template changes. The blog owner sees some tweaks previously made, suddenly vanish. Some of the owner applied features simply disappear, others stop working - with no explanation or warning.
- Not install the updated post template. The new Blogger feature doesn't work - and the blog owner is left complaining about broken Blogger updates, while other blog owners are enjoying the new feature.
When Blogger upgrades the post template, what happens to your tweaks?
If Blogger updates the post template, and some owner applied features disappear or stop working, the blog owner can simply install the necessary tweaks, again. Having kept the notes, or code snippets, from the original install, many blog owners simply install everything again.
Unfortunately, if the Blogger post template changes were applied in the same post template section as the owner applied tweaks, the owner retained notes or code snippets may be out of date - and installing them again may break one or more Blogger supplied features.
Some post template tweaks can have effects outside the post template.
Some owner applied changes, if installed improperly, can affect other sections of the template, in general - and cause mysteries such as problems updating accessory gadgets, and problems using the Template Designer.
The end result is that owner installed post template tweaks must be made, selectively - and any Blogger changes, publicised or non publicised, may necessitate re install of any owner applied tweaks. Owner applied tweaks must be re installed, character by character - and frequently with the readers complaining about an unexpected change or broken blog.
The post template is actually another example of "well enough", for many blog owners.
---
Tweak The Post Template, When Necessary - And Only, When Necessary
Some Blogger blog owners, as they develop a post, use Preview mode to periodically observe what the post looks like.
A few owners are confused about the privacy of a post, as it is Previewed. Some think that the temporary nature of the Preview window makes the content, as Previewed, intentionally unavailable for viewing by their readers.
Fortunately, the links - even though they may be clickable by the readers, lead nowhere.
Here is a Preview URL for this post.
http://blogging.nitecruzr.net/b/post-preview?token=yV1fKDYBAAA.ySUB0XKSvMXVATQkgsbJpQ.vf2Wk6Ed_TXX54XVpLn3uA&postId=1855542079708688719&type=POST
If you're interested, click on the link. Does it show you anything? How about another?
http://blogging.nitecruzr.net/b/post-preview?token=zx9iKDYBAAA.ySUB0XKSvMXVATQkgsbJpQ.r_B4NGbmR453Nsa2tYZPKg&postId=1855542079708688719&type=POST
See anything interesting?
This post, being edited.
This post, being previewed. See the preview URL?
The preview URL:
https://24069595_d291cd04e6207d111fa5388b4e8893fada5ac690.blogspot.com/b/post-preview?token=xZUz-VoBAAA.O0Vfemj-2Qck1xmWN_at645qjM-E809UONHYWYK-IbP8yGx0F6eRm-z3UxF8qMPs.HwrOVypOYd44GQ-D0znhaw&postId=1855542079708688719&type=POST
Click on the URL, above - and see what you get.
Presumably, the tokens attached to the URL make the visibility of the post temporary - and the previewed post becomes secure by obscurity. That is, if anybody cares enough to view this.Why did I see evidence that 5 people had already read the Preview (and now, said evidence is gone)?
But like every Blogger feature, there are always ways to complicate the issue.
Similar to people who, years ago, published web sites, with the web site access logs published as part of the web site (and became the original target of referer spam attacks), we have Blogger blog owners who publish a real time access log on their blogs.
A popular blog accessory, Feedjit, provides a real time list of blog pages, as read by various people. Similar to a visitor log, but displayed in real time, and shown to the public in general, Feedjit shows everybody what blog content is being viewed.
And here is the complication, of the Preview content. Some blog owners are concerned that the public can view their Previwed content, because Feedjit displays the URLs of the Preview displays, as they (the blog owner) develop a new post.
Please examine the URL quoted below - does any component of that URL contain any tag, suggesting to you that the content is treated as private? It's simply obscure, because (without the involvement of Feedjit, or a similar access display log), the Preview post is not visible. To check it, here's the latest Preview URL for this post.
http://blogging.nitecruzr.net/b/post-preview?token=PYh8KDYBAAA.ySUB0XKSvMXVATQkgsbJpQ.6T7Xf_PcgR7nXI_xZCq_Kw&postId=1855542079708688719&type=POST
Personally, I don't use Preview mode that much. I like to Publish my posts over a period of days - if not longer. None of my posts are actually static, I call this Progressive Publishing. You're welcome to view any of my posts, any time you feel the urge.
Watch this post, and see what changes. To start, I'll now observe that, with the post Published, all of the Preview links (above) all appear to load the finished post - until the token (in the URL) expires. If you just clicked on any of the above Preview links, you are probably now seeing
Invalid security token: Error 403
since the Previews, for this post, have long expired.
The conclusion would be that Preview content is only visible until the post is Published. Until the post is Published, the Preview is available to everybody - if you choose to publicise the URL of the Preview.
