Identify The Gadgets In The Template, Reliably

When you tweak the code in a gadget, based upon my instructions, you'll be editing the template HTML. Or, you might be using the Layout wizard, to locate and remove a problem gadget.

You'll do most editing with widget code unfolded. You'll have a lot of code to sift through - and with many gadgets in your blog, there's always the chance that you'll see the code for one gadget, and confuse it for another.

If you delete or tweak the wrong gadget, you may not like what you get. Before deleting anything, or editing the template, take an extra minute, and find the specific gadget, by its name. This could save you a lot of grief.

Here, I'll look at the Welcome message in my Buzz blog.

This is what I did, as I tweaked it to make it show up only on the Home page.

So, welcome to The Buzz.

If I right click on the screwdriver / wrench ("dragonfly") under that gadget, and select "Copy Link Location" (or possibly "Copy link address"), I can paste the URL into Notepad for easy examination.

Alternately, use the Layout wizard, click on "Edit" - and stretch the gadget window out horizontally, until the entire URL is visible.

http://www.blogger.com/rearrange?blogID=6525860816441104874&widgetType=Text&widgetId=Text1&action=editWidget

The gadget in question is "Text1". To find the code to tweak, I use the Template "Edit HTML" wizard - and completely unfold the code for "Text1".

<b:widget id='Text1' locked='false' title='' type='Text'>
<b:includable id='main'>
<b:if cond='data:blog.url == data:blog.homepageUrl'>
  <!-- only display title if it's non-empty -->
  <b:if cond='data:title != ""'>
    <h2 class='title':gt;<data:title/:gt;</h2>
  </b:if>
  <div class='widget-content'>
    <data:content/>
  </div>
</b:if>

  <b:include name='quickedit'/>
</b:includable>
</b:widget>

That beats an eyeball based search, any day. It's 100% reliable, and takes just a few seconds to find the code for "Text1". After you do this a few times, you'll be able to hover the mouse, and spot the widgetId=Text1 in the URL display in the browser status area - and go straight to

The gadget in question is "Text1".

---

(Update 2014/12): If you use a text browser, you can locate and identify a problem gadget, much more easily.

---

>> Top

Renaming Your Blog - Planning The Change Properly

Your blog depends upon traffic for its success.

Anything that affects the traffic to your blog, such as a change in the URL, affects the success of your blog. If you republish your blog to a different BlogSpot URL, as with migration to a custom domain, you will not lose any content. Both comments, posts, the template, and all custom settings, will stay with the blog. And if you plan the republishing effort, you can minimise the loss of traffic.

Properly planning the migration, to a different BlogSpot URL, will require different techniques than a simple custom domain republishing.

All 3 URL changes produce similar effects, though - and it's in your best interest to do what you can, to minimise the effects.

1. BlogSpot to BlogSpot URL change.
2. BlogSpot to custom domain re publishing.
3. Custom domain to BlogSpot re publishing.

All 3 changes require your blog to be re indexed by the search engines - and leave the blog with less search engines generated traffic, while being re indexed.

A BlogSpot to BlogSpot URL change is different from a custom domain publishing.

Custom domain re publishing has a feature that BlogSpot to BlogSpot URL changes lack. This will reduce negative effects of the URL change - with the domain properly setup.

With a custom domain republishing, the old (BlogSpot) URL is redirected to the new (domain) URL, using a "301 Moved Permanently" instruction. A "301 Moved Permanently" redirect simply repoints each individual URL in the blog to the new URL.

Unlike a custom domain renaming, you cannot choose an available URL, before you begin.

This post (using the domain URL) is "blogging.nitecruzr.net/2010/03/renaming-your-blog-planning-change.html". I can, alternately, advertise it as "bloggerstatusforreal.blogspot.com/2010/03/renaming-your-blog-planning-change.html". That's the "301 Moved Permanently" redirection, in action. All traffic is forwarded, automatically.

There is no way to add "301 Moved Permanently" redirect to a BlogSpot rename.

Blogger won't provide a "301 Moved Permanently" for a BlogSpot rename, as this would encourage spammers to move their splogs around, endlessly. The best that you can do is to use a stub blog, with proper planning.

If you want the blog offline permanently - or if you don't want other people recreating the blog under its current name, you will want to plan the renaming - just as you would (or should) plan a deletion. If the URL becomes available, the same content / impersonation / privacy issues will exist.

Consider the categories of traffic sources, and the effects.

As with a custom domain migration, you'll want to consider the traffic to the blog, in categories.

• Blog Feeds - Automated processes, that help your readers track changes to your blog, using a newsfeed reader.
• Following - The two way community process, that lets you see who your readers are.
• Google Webmaster Tools - Key diagnostic and management utilities, that - among other things - enable indexing of the blog by the search engines.
• Search engines - Robotic processes which methodically surf your blog, and provide dynamic indexing to people who search for information.
• Viewers - People who read your content from their browser.

Blog Feeds are the easiest and cleanest category to redirect. Even though Blogger won't provide a "301 Moved Permenantly" for the blog URL, they will provide this for the feed URL, using a blog post feed redirect URL.

With the post feed enabled for both the live blog (under the new URL), and the stub blog (under the old URL), set the Post Feed Redirect URL for the stub blog to the exact value of the feed URL for the live blog. Your Followers and subscribers, using the old URL, will continue to see newsfeeds for your live blog, while using the old URL.

Following, with the renaming done correctly, is easy to redirect. Your Followers, as mentioned above, can view the blog feed using the old URL, with no problem. With the blog renamed simply using Settings - Publishing, your Followers will continue to be associated with the blog, with no further action by you.

Google Webmaster Tools are a vital part of the migration, and should be handled immediately after you re publish the blog, and then immediately after you setup the stub blog. You'll have several challenges here.

1. The "robots.txt" file for the blog, as renamed, may contain the old URL.
2. The new URL for the blog won't exist in Google Webmaster Tools, so you have to add that. When you verify blog ownership, you'll have to remove the GWT verification tags for the blog, that were used under the old URL.
3. You'll have to setup sitemaps for all posts in the blog, under the new URL, to complement / replace those under the old URL before the blog was re published.

The search engines will be the most frustrating part of any blog rename. Without any possibility of a "301 Moved Permanently" redirect, or anything remotely similar, any SERP hits will land the prospective viewer on a 404 display. Your best strategy is to manage the other categories aggressively, and hope that the search engines re index your blog promptly under the new URL.

Your viewers will have to be redirected using the stub post in the stub blog, published under the old URL. Your viewers looking for the main page of the blog will see the stub post, with no problem. Your viewers clicking on a direct link to a single post, an archive or label search, or possibly a SERP hit, will get a 404 display.

Page not found
Sorry, the page you were looking for in the blog The Real Blogger Status does not exist.

Go to blog homepage

The "Go to blog homepage" link will, hopefully, display the stub post - and they can follow the link to the new URL. That's a start, and it's all thanks to the Blogger custom 404 display.

OK, lets summarise the tasks involved.

1. Is this blog published to a Google custom domain? If so, read about specific issues related to custom domain URL changes.
2. Re publish the blog, under the new URL.
3. Enable the feeds, and verify feed URLs.
4. Setup Google Webmaster Tools for the blog, under the new URL. Look in the Sitemap list for the blog. Any sitemaps in there right now will likely point to the old URL, so these need to be removed. Then, add sitemaps for all posts.
5. Setup a stub blog, under the old URL.
6. Set the Post Feed Redirect URL, to point to the feed for the new URL.
7. Check Google Webmaster Tools for the blog, under the old URL. Look in the Sitemap list for the blog. You'll probably have to re add all sitemaps for the blog, to enable the search engines to index the blog, starting from the old URL, through the redirected feed.
8. Are you using a FeedBurner (or another custom feed)? If so, update FeedBurner, then check the Post Feed Redirect URL setting.
9. Check and update all Google Webmaster Tools settings, between the old and new URLs. Think carefully about each setting, and decide whether it should apply to the blog under the old URL, under the new URL, or both.
10. Are you using Mail-to-Blogger to publish to the blog? If so, check your Mail-to-Blogger addresses.

And if possible, read about the details involved in the rename process before you rename the existing blog. This last caution especially applies to changing one non BlogSpot URL to another non BlogSpot URL.

Including Content From Other Websites In Your Posts

I use excerpts of articles from other websites, in a few of my posts - when the other websites provide more in depth description of the issue being discussed.

I use some websites, such as WikiPedia, more than others. It's good practice to at least link back to the originating website, when copying or quoting any significant amount of unique content. There are so few restrictions, in general, what content we may include in our blogs - so it makes sense to be polite when we include content from other websites.

In most cases, and to keep my posts relatively short, I prefer to simply quote a brief, relevant snippet of content, and link back to the originating website.

In WikiPedia: Occam's razor, we see the advice

the simplest solution is usually the correct one.

For best results, ask for permission from the legal owner.

Since every different blog / website, with a different owner, could be published under a separate content policy, it's always best to ask for permission, before copying. Without permission, you could find yourself here later, asking about various content related penalties.

• Some owners might appreciate the free publicity.
• Other owners might not want their content used in another website.
• Some owners might be paying a third party for the right to use their content.

You won't know, until you ask.

I like to add " target="_blank"" to any link that takes the reader to another website, however temporary.

In WikiPedia: <span style="font-style:italic;"><a href="http://en.wikipedia.org/wiki/Occam%27s_razor" target="_blank">Occam's razor</a></span>, we see the advice<blockquote>the simplest solution is usually the correct one.</blockquote>

Content such as Lorem Ipsum is ancient public domain, and it's available all over the Net. It may or may not be necessary to attribute that, for brief snippets.

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

When you include original content from a specific website, however, it's good practice to attribute.

The text is derived from sections 1.10.32-33 of Cicero's De finibus bonorum et malorum (On the Ends of Goods and Evils, or alternatively [About] The Purposes of Good and Evil ).[3] The original passage began: Neque porro quisquam est qui dolorem ipsum quia dolor sit amet, consectetur, adipisci velit (Translation: "Neither is there anyone who loves grief itself since it is grief and thus wants to obtain it"). It is not known exactly when the text acquired its current standard form; it may have been as late as the 1960s. The passage was discovered by Richard McClintock, a Latin scholar who is the publications director at Hampden-Sydney College in Virginia, by searching for citings of the rarely used Latin word "consectetur" in classical literature.[1][2]

The original version (with the excerpted items highlighted) appears in Book 1, sections 1.10.32-33 (pagination varies by publisher):

[32] Sed ut perspiciatis, unde omnis iste natus error sit voluptatem accusantium doloremque laudantium, totam rem aperiam eaque ipsa, quae ab illo inventore veritatis et quasi architecto beatae vitae dicta sunt, explicabo. Nemo enim ipsam voluptatem, quia voluptas sit, aspernatur aut odit aut fugit, sed quia consequuntur magni dolores eos, qui ratione voluptatem sequi nesciunt, neque porro quisquam est, qui dolorem ipsum, quia dolor sit amet, consectetur, adipisci[ng] velit, sed quia non numquam [do] eius modi tempora inci[di]dunt, ut labore et dolore magnam aliquam quaerat voluptatem. Ut enim ad minima veniam, quis nostrum exercitationem ullam corporis suscipit laboriosam, nisi ut aliquid ex ea commodi consequatur? Quis autem vel eum iure reprehenderit, qui in ea voluptate velit esse, quam nihil molestiae consequatur, vel illum, qui dolorem eum fugiat, quo voluptas nulla pariatur?
[33] At vero eos et accusamus et iusto odio dignissimos ducimus, qui blanditiis praesentium voluptatum deleniti atque corrupti, quos dolores et quas molestias excepturi sint, obcaecati cupiditate non provident, similique sunt in culpa, qui officia deserunt mollitia animi, id est laborum et dolorum fuga. Et harum quidem rerum facilis est et expedita distinctio. Nam libero tempore, cum soluta nobis est eligendi optio, cumque nihil impedit, quo minus id, quod maxime placeat, facere possimus, omnis voluptas assumenda est, omnis dolor repellendus. Temporibus autem quibusdam et aut officiis debitis aut rerum necessitatibus saepe eveniet, ut et voluptates repudiandae sint et molestiae non recusandae. Itaque earum rerum hic tenetur a sapiente delectus, ut aut reiciendis voluptatibus maiores alias consequatur aut perferendis doloribus asperiores repellat.[2]

- From Wikipedia: Lorem Ipsum

Blogger spam classification looks for scraped content.

Blogger is now diligently screening blogs for "spam" and other forms of misbehaviour. One of their classifications of "spam" is termed "scraping". Many blogs consist, largely, of content scraped from various websites, minimally relevant.

Your blog needs more than scraped content - if you wish to continue.

People who publish blogs that contain material from other websites, simply must make it a consistent practice to distinctly attribute copied material - or face the possibility of spam classification by the Blogger bot.

Note that, however you attribute, yor blog will simply serve as a gateway to the other source blog / website. With the other website higher in page rank than yours, you'll just be sending your readers to theirs - and the SERPs will list theirs ahead of yours.

You're not going to gain much - except empty volume - by including their content.

You will be responsible for content from other blogs and websites.

Note that any time you include material from - or link to - another blog or website, what you include or link to must be abuse and malice free. You are responsible for the comfort and safety of your readers - and anything that you do, to possibly disturb their comfort or safety, can cause your blog to be locked or deleted, as abusive or malicious.

A connection to another blog or website - using a feed, iframe, or link - puts a portion of your blog under the control of the other blog or website. If an abuse / spam classification bot determines the other blog or website to be abusive / malicious, your blog will suffer the consequences.

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.