Photobucket Drops Free Image Display, Outside Their Website

One of the most popular third party image hosting services, for Blogger blogs, recently changed their photo hosting service.

Photobcket no longer allows embedding of their hosted photos on third party websites, for free accounts. They now require a $399 / year membership, for accounts with photos shared outside their website.

Some Blogger blog owners, publishing blogs which use third party templates that feature images - decorations, illustrations, and wallpaper - hosted by Photobucket - now see their blogs decorated by various demands.

PLEASE UPDATE YOUR ACCOUNT TO ENABLE THIRD PARTY HOSTING



This is (was) a small image, tiled (repeated horizontally and vertically), to fill a larger space. It's now a PhotoBucket ad, similarly tiled.

In many cases, this is simply a third party supplied template, using wallpaper designed by the template publisher. The template publisher used PhotoBucket, to host the image.

The blog owner, and others, now face the need to pay dearly, to publish their blogs using their current templates.

Whether the template objects were created by you - or by the supplier of a shiny third party template - if the images are hosted by Photobucket, they are now unusable, on your blog.

Photobucket, a US-based image and video-hosting website founded in 2003, quietly changed its policy late last month to prevent users from hosting their content on third-party websites unless they pay a $US400 ($526) annual fee.

Photobucket published a brief blog post, on June 26, referring to the service change - buried deep in their website.

We have updated our Terms of Service, effective June 20, 2017. Please take a moment to review our updated terms and policies as they may affect your account.

If your blog uses a third party template with PhotoBucket hosted images, the account in question won't be yours - but your blog will still be affected. You're going to have to find out how your template designer is going to support their product.

Third party template publishers now need to convert their templates, to use images hosted by other services. And Blogger blog owners may need to find other image hosting.

Blogger blog owners, who use third party templates in their blogs, may need different templates. Not all third party template publishers may be able to support their templates, and this change.

The simplest solution is to switch back to a Blogger standard and supported template, using the dashboard Theme page. If you've had your current template for a while, you may not know what possibilities have been added, to the Blogger template selections.

---

Photobucket, a popular third party image hosting service used by many #Blogger blogs, originally allowed their hosted images to be embedded or hot linked on Blogger and many other websites. They recently started requiring a $400 USD / year membership, for images to be displayed outside their website.

Many Blogger blogs, with third party templates that use Photobucket hosted images, now have broken templates.

Does Your Blog Need HTML Validation?

A few blog owners are concerned about blog network performance - and spend time validating and tweaking the template, based on advice from various third party services.

I don't know how to use W3C Validation, there are always errors displayed for my blog!

And we see periodic questions about validation - and sometimes reports about broken templates, with blog owners following the validation advice, blindly.

W3C Validation produces hundreds of errors, for every blog page.

I Tried Validation, For This Blog.

I used to tear my hair out, trying to fix my W3C validation errors, for this blog.

Check out the validation log, for this blog, as an example. See the size of the scroll tab? That's a 20 page report - of critical errors, in the blog home page.

See the size of the scroll tab? This display shows just the first page, of 20 or so.



Validation Is Useful, For Static Websites.

W3C validation is designed for HTML based, static websites - that are centrally located. Blogger blogs are XML based, and dynamic - and use the Google Content Delivery Network, which serves blog content from dozens of different data centres, worldwide, based upon the location of each individual reader.

With the Google CDN delivering content locally, to many readers, distance related network issues are less important - and with Blogger templates being maintained and tested by Blogger Engineering, a lot of the issues identified by validation are not easily resolved by the typical blog owner.

If you publish a Blogger blog, using a Blogger supplied template, work on content. Blogger manages the network settings, relevant to your blog, as it is served by the Google Content Delivery Network. You publish your blog - and let Blogger / Google worry about the networks, the servers, and the templates.

Custom / Third Party Templates May Benefit, In Specific Cases

It's possible that some blogs with third party templates, and non Blogger standard code, may benefit from validation.

If your blog has a non Blogger template, you could check out Blogger Developers or Stack Overflow - and ask for advice there. Or, try contacting the person / site that provided you with the template, and see what they can tell you.

But with a blog with a supported Blogger template, concentrate on content. Don't tweak the template HTML, unless necessary. Leave Blogger / Google to worry about network issues and the template.

---

Some #Blogger blog owners concern themselves about third party network performance analysis. Learn why some performance analysis advice may be unnecessary - and can be harmful to your blog.

https://productforums.google.com/d/topic/blogger/8plQKqdwSGg/discussion

Custom Domains And HTTPS Redirection Code

As most of us know, Blogger HTTPS support does not include custom domain publishing.

The advantages offered by HTTPS access are widely advertised - and have led to envy between blog owners who publish to custom domains, and native BlogSpot blog owners proudly advertising their new HTTPS connectivity.

Long ago, we saw possibly malicious code which helps our readers avoid using country code aliases, to read our blogs from an aliased country. Recently, there was dodgy code which blocked HTTPS mode, to read a customised blog.

Now, we have custom code to force HTTPS access, for BlogSpot published blogs.

Along with providing code to help blog owners avoid country local domain aliasing, some marginally helpful hackers are providing code to help blog owners force reader access to HTTPS.

Some blog owners always wanted HTTPS to be used, to access their blog.

Some blog owners wanted their readers always using HTTPS to access their blogs, before forced HTTPS access became an option. They Googled, and found, semi helpful hackers who provide clever code to force the "HTTP --> HTTPS" redirection.

<script type='text/javascript'>
$(document).ready(function() { 
  $("a[href^='http://']").each( 
    function(){ 
      if(this.href.indexOf(location.hostname) == -1) { 
        $(this).attr('target', '_blank'); 
      } 
    } 
  );
  $("a[href^='https://']").each
    function(){ 
      if(this.href.indexOf(location.hostname) == -1) { 
        $(this).attr('target', '_blank'); 
      } 
    } 
  );
});
</script>

This is clever code - when only BlogSpot access is involved. When you add BlogSpot to custom domain redirection, it becomes another "404".



Adding this clever code is an excellent solution - until the blog owner forgets about it, and later upgrades to a non BlogSpot custom domain.

With a custom domain published blog, the redirection becomes a problem.

The added code contains no exception to permit custom domain published blogs to remain in HTTP mode. When accessing an otherwise properly setup custom domain published blog, from a reader using the "blogspot.com" URL, this prevents the BlogSpot to domain redirect from operating.

BlogSpot URLs, which should redirect to the HTTP published custom domain URL, instead redirect to a non existent HTTPS URL - and result in another "404". As the custom domain URL becomes more commonly used for a recently published blog, confusion increases when the rarer BlogSpot URL reference is encountered.

My blog has been using the domain URL for months, why is this happening now?

The problem involves dual redirection - to "https:" mode, and to the custom domain.

After painful problem diagnosis, we find the clever redirection code buried in template HTML - and we see that the blog reader is starting from the BlogSpot URL, and using the BlogSpot to domain redirection, to access the blog.

With blog access redirected to "https:" mode, then subsequently to the custom domain URL, the readers sees a "404" - because the custom domain URL is not available as "https:" content.

This problem will become increasingly rarer - but not extinct.

As self caused custom domain victims become rarer, this way of breaking ones own blog will become more obscure - and it's likely that some cases will go, unsolved. This will be similar to the problem of un migrated classic templates, which has increasingly less experienced support.

If you must install unsupported template tweaks into your template - consider the long term effects. Learn to recognise a problem that you have caused, to your own blog.

Not every helper will realise that you have added custom redirection code - and when looking at the problem code, when a problem is reported, will recognise it for what it is. Your problem may remain your problem - at least, until Blogger Engineering completes Blogger SSL integration (may this happen soon).

---

Some blog owners have added clever HTTP to HTTPS redirection code, acquired from helpful third party providers, installed in the template. When later publishing a blog to a custom domain, this code will prevent proper blog access - and as installed, may not be easily recognised.

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

Your Blog, And Third Party Accessories

Third party accessories are a big part of many blogs.

As Blogger proceeds to command a larger and larger share of the free online web site market, they encourage (directly or indirectly) the development of third party templates, and accessories. This lets us make our blogs more personal to our desires, and shinier to our egos.

Layouts Blogger is more mature, and commands an ever growing share of Blogger. And so, the the selection of Layouts compatible templates and accessories, again provided by third parties, will grow.

And as the selection grows, so does the possible risk, from installing what's available on our blogs. As I wrote long ago, what better way to hack somebody's blog (or computer) than by conning the victim into installing the hack, on his own?

As we install third party accessories, we need to remain aware of the risks involved, in using non Blogger components.

• Some accessories may not work as well as Blogger developed and certified products.
• All accessories may not work together, if developed by different third parties.
• Some accessories may not work at all.
• Some accessories, maliciously crafted, may work as designed - but their design may not be to our benefit.
• Some accessories, maliciously crafted, may attack the computers of our readers. What better way to acquire new victims en masse, than to con a third party into distributing malware without realising it?

Consider the last possibility carefully. It's one thing to unintentionally download and install a hack on your own computer - it's another thing to intentionally install the hack onto your blog, and then onto your readers computers.

Properly designed, a blog installed hack has to only contain code linking the blog to a web site where malware is distributed. Not all malware scanners, either installed on the computer or run from a web site, will detect the blog based component that merely redirects the victim to a malicious web site.

However, we are currently seeing reports of some malware scanners which do validate, on a page by page basis, against all links on the page.

Spread malware onto your computer, and you answer only to yourself. Help spread malware onto your readers computers, and you won't even know all of the people to whom you should answer.

In some cases, your readers won't know that you were the one who contributed to their problems - but you'll still be responsible. Your readers may not blame you for their troubles - but your blog will still suffer from less activity, because your readers are busy carrying their computers to the nearest tech shoppe, and paying for malware removal services, instead of reading your posts.

And should you choose to install a third party accessory or template on your blog, make sure that it's properly chosen and installed. And carefully control the install process.

And finally, keep track of what you install, after it's been installed and tested. Some accessories will work fine immediately when installed, and will fail later - giving your readers unwanted content, when they try to read your blog.