Showing posts with label Test Blog. Show all posts
Showing posts with label Test Blog. Show all posts

Saturday, December 6, 2014

AutoSave, And Draft Mode Post Editor

Recently, we've been seeing a few reports, in Blogger Help Forum: Get Help with an Issue, suggesting more problems with Post Editor, in Draft mode.
I keep getting an error, when editing my posts.
An error occurred while trying to save or publish your post. Please try again.
I am editing Draft posts, some of which are fairly large.
This blog owner is discussing yet another facet of the Post Editor feature, AutoSave.

Early AutoSave Experience

Long ago, people would report a different problem, when composing posts.
When I compose my post, my typing is way ahead of what is displayed.
Blog owners, long ago, discovered that AutoSave, which applied to posts being composed before publishing, made their computers slow down. This made their on screen post content show noticeable delay, from their typing.

With newer and more powerful computers, and people who still type at the same speed, Post Editor slow down has become a thing of the past - but at a price.

With highway traffic engineering, a well known problem involves the regional effects of upgrading a local arterial street, to handle more traffic. This might improve traffic in your neighbourhood, but at the expense of another highway in the next city.

Similarly, upgrading the speed of your computer improves your Post Editor typing problem, but puts more load on the networks and Blogger servers. Thus we see the symptom, reported above.
An error occurred while trying to save or publish your post. Please try again.

Pre AutoSave Experience

As you compose a post, what you type is saved on your computer - and displayed in Post Editor. This lets you see what you are typing, in a "what you see is what you get" display. If you hit "Save", periodically, what you have typed gets saved to the Blogger servers.

Originally, many blog authors did not think to Save, when composing a post. Some would just type - then eventually Publish, when convenient. This technique created two problems.
  1. The longer an author waited before Publishing, or Saving, the greater the chance that something would happen with the computer being used, causing loss of what was being typed. And the greater the catatrophe from the loss.
  2. The longer the author waited before Publishing or Saving, the more work would be done by the Blogger servers, when the author finally did Save, then Publish.
Blogger added AutoSave to Post Editor, so the effects of Publishing massive amounts of unsaved post content would not affect Blogger resources so abruptly - and so less people would see their hard effort go down the drain.

Current AutoSave Experience

One known problem with AutoSave is that it generates load on the local computer, on the networks connecting to Blogger, and on the Blogger networks and servers - thus the slow typing problem, long ago.

Another problem is that it saves automatically (hence the name) - and for some people, who may have just cleared the contents of a post, AutoSave saving an empty post tends to cause a problem. The longer people work on pages or posts, without publishing, the greater the chance that this disaster may happen.

Unfortunately, having a more stable publishing process, thanks to the reverse effect of AutoSave, will just encourage people to take longer before Publishing or Saving. Thus the complaint.
I was working on my new post for weeks. Right in the middle of highlighting a section for deletion, AutoSave kicked in, highlighted the whole post, deleted the highlighted section, and saved an empty post. How do I get my post back?
And for this unhappy author, there can be no helpful answer.

Future AutoSave Prognoses

For a while, I've been suggesting that when possible, you should publish a post immediately, then continue editing your post after publishing - since AutoSave only affects post editing, before the initial Publish. Recently, I discovered that it may be possible to use Google Docs as a Content Management System, for long term post development.

A third possibility is that you compose your unpublished posts in HTML mode, instead of Compose mode. The effects of AutoSave, in HTML mode, are not as objectionable. Some of my posts, I might develop for a week or two before Publishing, using HTML mode. If you use this technique, and you include anchor links in your posts, beware of switching back and forth between Compose and HTML.

A fourth alternative, use of Microsoft Word instead of Google Docs, is known to cause problems with auto pagination and with various posts newsfeed accessories. We do not recommend use of Microsoft Word.

However you develop a post, the longer you wait before Publishing, the greater the chance that AutoSave will make you unhappy - either by sudden destruction of your post - or by contributing to the latest symptom.
An error occurred while trying to save or publish your post. Please try again.
Publish sooner, develop offline, or become a victim.

Wednesday, March 19, 2008

Always Test Your Changes

Periodically, we see an anxious query
I just got an email from a friend
Your blog looks like crap.
What do I do now? Help! Oh yes, I think I tweaked the template a couple weeks ago.

So if you made the change to the template "a couple weeks ago", why did you wait until today, to find out from your friend that you have a problem?

Blogger Blogs are easy to work on. As easy as they are to work on, though, they still demand respect, and responsible practices are still relevant.

If you make changes, test your changes using different browsers.

Any time that you make a change to the blog, or even when you post a new article, check out the change, preferably using multiple browsers. When you test, you need to see the blog as your readers may see it - so prepare to logout and login a few times, to view changes then make adjustments.

If you have a second browser or computer, this would be an excellent way to use one - to stay logged in on one browser, and make changes much easier. Or, using a sandboxed browser is an alternate way to check what your readers see - you won't be logged in, from there.

Alternately, an online website display service may be useful.

When making template changes, setup a test blog and change there first.

If you're making changes to the template, consider setting up a blog for testing, and make your template changes there first. Blogs are free - Xanax isn't.
  1. Setup a test blog.
  2. Save the template from your production blog, to your computer.
  3. Load the template, saved in Step 2, to your test blog.
  4. Export posts from your production blog, then import them to your test blog. This gives you a real test bed.
  5. Make changes, and test them, without worrying about what your readers see. They only see the production blog. If you mess up badly, go back to Step 3.
  6. When you're happy with the test blog, save the template to your computer.
  7. Load the template from Step 6 to your production blog.
  8. Save the template copy from Step 2, as a fall back.
  9. Wasn't that easier on the nerves?

Just copying the template won't give you a cloned blog.

Nowadays, and if you develop a template and decorate it using a lot of custom gadgets, merely copying the template from one blog to another may not leave you with an elegantly developed blog.

Right now, there is no procedure for backing up or restoring gadgets. If that's a problem, you develop the template, then transfer the comments, posts, and URL to the newly developed blog.

This is a bit more work, but it will preserve your gadgets.
  1. Setup a test blog.
  2. Save the template from your production blog, to your computer.
  3. Load the template, saved in Step 2, to your test blog.
  4. Export posts from your production blog, then import them to your test blog. This gives you a real test bed.
  5. Make changes, and test them, without worrying about what your readers see. They only see the production blog. If you mess up badly, go back to Step 3.
  6. When you're happy with the test blog, transfer the existing comments, posts, and the URL to the new blog.
    • Extract the comments and posts from the existing blog, to an XML file.
    • Import the XML file to the new blog, and publish all posts not already handled in Step 4.
    • Re publish the existing blog to a new URL.
    • Publish the new blog to the publicly known URL.
    • If you have administrators / members / readers, you'll have to add them to the new blog.
  7. Save the old blog, published to the new URL, as a fall back.
  8. Wasn't that slightly easier on the nerves?


And of course, in both cases, backup the blog and the template, before and after making any major changes.

Don't wait for your friends to complain.

Navigate» Become author for this Blog