I've been writing about Custom Domain Publishing, and about FTP Publishing, and the relative advantages and differences, for several years now.
In August 2007, I went out on a limb (for me, anyway) and I suggested thatFrom an economic and support viewpoint, it makes more sense for Blogger to concentrate its attention on Custom Domain publishing, where they control everything but the domain directory process, and can eliminate the uncertainty of supporting communications with hundreds of third party servers, complicated by geographical and network distance issues.
Blogger, in FTP vs. Custom Domains, last year, provided their view of why custom domain publishing has more future.As I've dug in over the last few weeks on issues relating to FTP, as often as not the problems were not Blogger-related but were a byproduct of a webhost implementing stricter security on FTP logins (only whitelisting certain IP addresses, for instance, or throttling access for certain users). These are notoriously hard to isolate, particularly when they involve coordinating support with a third party. No one - including us! - enjoys the terrible back and forth of "it's the webhost's issue" "no, it's Blogger's issue" "no, we're pretty sure it's the webhost's issue" when all you want is to be able to post to your blog.
I've written numerous articles about various problems with FTP Publishing - some problems directly attributed to changes by remote server support staff, others suspected to be related to changes - but not proven.
Many problems have been fixed by Blogger Support. So I sort of had an idea that problems existed, but what I was seeing - and suspecting - was merely the tip of the iceberg.
In Deprecating FTP, we see statisticsFTP remains a significant drain on our ability to improve Blogger: only .5% of active blogs are published via FTP — yet the percentage of our engineering resources devoted to supporting FTP vastly exceeds that.
In The Technical Side of FTP, we see even stronger details.Google runs many datacenters, and Blogger runs in several of them. Each datacenter has a different Internet address (a.k.a. "IP address") when it connects to your FTP server, so if your hosting service requires an IP whitelist, you would have to list all of the IP addresses associated with each of our active datacenters. ... This leads to a significant amount of user frustration, and regularly results in blogs failing to publish successfully. Diagnosing these issues has taken up a large part of our engineering and support team's time.
andIn a great deal of cases, FTP publishing works but is extremely slow due to shared hosting plans having slow or limited network or disk per user. We have seen cases of full FTP republishes taking over a month, entirely due to the FTP server being slow.
and even a concludingWe spent a significant amount of engineering time improving FTP support in the last two years, not including support and troubleshooting user issues. Even after this effort, approximately 10% of all FTP publishes fail.
So you see, folks, when you saw the well known errorPublishing your blog is taking longer than expected ...
you weren't alone. Blogger engineers were seeing it, too - from a different, and equally, frustrating viewpoint.
>> Top
This week, we have yet more reports of the chronically present old friendConnectException: Connection timed out.
for bloggers publishing by FTP.
So far, the reports of this problem seem to be associated with server space provided by Aruba.
If you are suffering from this problem, please provide diagnostic information:- The blog BlogSpot URL (if applicable).
- When was the blog setup in Blogger? (If the blog was published immediately by FTP, say so).
- The blog domain URL.
- When was the blog setup for FTP publishing?
- The name of the server hosting company.
- The Blogger FTP server setting (name or IP address of the server), in use right now.
- What operating system, browser, and version of Java do you use?
- Where are you located, and what ISP do you connect through?
If you have other blogs that are not having a problem publishing, the same information may be relevant too. Remember, we're looking for a solution for your problem, so be generous, and precise.
>> Top
If you are still publishing your Blogger blog to an external, non Google server, using FTP, in spite of many recommendations, you are probably used to various advice, such as that which instructs you to contact the support staff for the host server, when problems are seen. Not everybody knows how to deal with server support personnel, though.The host server staff says they don't see any log errors.
orI can update using FastFTP, with no problems. The problem must be with Blogger!
These are common attitudes, which probably should be expected. Common or expected, they may not get your problem solved.
The clues are in the server logs. What the host server support personnel see as "no log errors" may need to be interpreted properly. You pay them for service, so they work for you.
FastFTP, and similar desktop clients, require a series of server profiles which you setup, by hand - one for each server. You have no problem with FastFTP because you configure FastFTP, specifically, to work with your host server. Blogger code, on the other hand, has to support hundreds or thousands of different host servers, never knowing if any 2 should be treated the same, or differently. Many host servers are specified as domain URLs. How can the Blogger code identify and track each individual domain / server URL, and know what precise tweaks are required for each?
If you look in the forums and see a few questions about FTP publishing problems already asked, this possibly indicates a problem that Blogger has caused. Find a common question with similar symptoms being reported, and add yourself to that question. When there are others sharing your symptoms, adding your symptoms to the question may help Blogger solve your problem faster.
On the other hand, if you don't see any similar questions, it may be up to you to deal with your problem. And you should start by learning to assert yourself, when you need help with your FTP publishing problem, by patiently and persistently involving the host server support staff. Ask a question in the forum - somebody has to be the first, after all. But concentrate your efforts on the host server support.
Occasionally, we see problems that are actually caused by host server changes. Keep an open mind here.
>> Top
Recently, we're seeing an assortment of complaints about blog feeds, either not working at all, or updating slowly. Whether presented in a browser display, in a Following Reading List / Google Reader, or in a bloglist gadget, the accuracy of the feed as displayed can be affected by a few issues.- Custom feed redirection.
- Custom Domain redirection.
- Classic vs New feed URL, and Blogger vs BlogSpot / domain served feed.
- Feeds served by third party servers (FTP publishing).
- Feeds from private blogs (which don't exist).
- Cached feed content.
Custom Feed Redirection
A custom, redirected feed, redirected through FeedBurner or a similar service, will be affected by problems with the service. When you check out a problem with a redirected feed, it may be helpful to compare the redirected feed content with the non redirected feed content.
Custom Domain Redirection
A feed coming from a blog that's published to a custom domain will be affected by the custom domain DNS issues. Feeds redirected through DNS addresses that use spurious solutions, like frames or URL forwarding, will be slow to, or never, update.
When you check out a problem with a feed from a blog published to a custom domain, start by examining the DNS setup for the domain. For each person reporting a problem, see if they are using the BlogSpot URL, or the domain URL. If the former, check the BlogSpot to domain redirection.
Feed Format and Source
For any feed with a problem reported, find out if the problem is with a classic, or a new, feed URL. The exact feed URL may be relevant. Look at the 3 feeds served from this blog page, as provided in the blog header.
<link rel="alternate" type="application/atom+xml" title="The Real Blogger Status - Atom" href="http://blogging.nitecruzr.net/feeds/posts/default" />
<link rel="alternate" type="application/rss+xml" title="The Real Blogger Status - RSS" href="http://blogging.nitecruzr.net/feeds/posts/default?alt=rss" />
<link rel="service.post" type="application/atom+xml" title="The Real Blogger Status - Atom" href="http://www.blogger.com/feeds/24069595/posts/default" />
Here, we have 2 new URL feeds served from the custom domain, plus one feed served from Blogger.com.
Third Party (FTP Published) Feeds
When you're looking at feed URLs, watch out for a feed that comes from an external third party server. Feeds published from non Google servers may have many issues. Use of the Blogger based feed, vs the third party server served feed, may be especially significant. We've even recommended use of the Blogger served feed, as a workaround for feed problems in some FTP published blogs.
Feeds From Private Blogs
A feed coming from a private blog will never be updated. If the blog was just made private, you'll be seeing the blog feed as it was before the blog was made private, for a long time.
Effects Of Caching Upon Your Clients
Also, consider the effects of cache. Your readers that are affected by a local cache, or an upstream cache, will see irregular performance when they view a feed. Depending upon the nature of a blog, a given blog may have more readers who use a bloglist or feed reader, and who have Internet service that includes an upstream cache. A regional, or reader service, affinity may point to a cache issue.
Summary - When Reporting A Problem
Anybody reporting a problem with a feed viewed in somebody else's blog should state their geographical location, ISP name, and type of Internet service. Anybody subscribed to a feed with a problem should state the complete and precise URL of the feed. All of these details may be relevant to the problem.
All of these are details which will affect peoples access to any blog feed, and the displayed content in the bloglists and feed readers which they view.
>> Top
This month, we have several reports from bloggers who, for one reason or another, have changed the FTP username and / or password on the domain host server, and then updated the username / password in their Blogger FTP settings. Much to their dismay, when attempting to publish their blog, they find the old username / password being sent to the remote server.I have verified it's saving my new username in the publishing settings and yes, I'm seeing the error based on the posting status. I get the following ...FTP login failed (server: ftp.domain.com, username: myoldusername, reason: 530 User myoldusername cannot log in. )
Are you seeing this behaviour, when trying to publish your blog?- What is the blog URL?
- What is the FTP server setting?
- When did you make the setting change?
- Did you verify the problem, by examining the host server activity logs?
>> Top
This month, we continue to see reports of several frequent symptoms, causing much anguish in bloggers who publish their blogs by FTP. The well knownYour publish is taking longer than expected. To continue waiting for it to finish, click here.
andConnectException: Connection timed out.
and a variant of the latterFTPConnectionClosedException: Connection closed without indication.
But this month, there is hope. Several workarounds for these symptoms have been discovered by various relieved bloggers.
In several cases, bloggers have found use of the domain name, as opposed to the host server IP address, in the blog (Settings - Publishing - ) "FTP Server" setting, to resolve the problem. In one case, the reverse was true - changing from the server name (domain name?) to an IP address provided relief from the problem noted. It's possible that checking with the host server support team, and verifying the correct setting, may provide help here.
If your blog is hosted on a shared hosting service, you'll have to use the domain name rather than an IP address. If you use the IP address of the server, the FTP service on the server will try to publish your blog to the default space in the FTP service. On a shared hosting service, your blog will probably not be the default. You'll either get an explicit "Security Violation" (name / password checked immediately), or "Your publish is taking longer than expected" (name / password checked with data stream).
I suspect that this change is necessitated by a change in the host configuration. GoDaddy, who is one of the hosting services in question, has been making server configuration changes in recent months, and it's possible that other hosting services have been doing the same.
In other cases, the support staff for the host server made changes in the firewalls protecting the host servers, and resolved the problem. In one case, Blogger started using Passive FTP. Passive FTP, identified in FTP logs with the "PASV" command, is easier to configure (and secure) at the client end (ie, Blogger), but is harder to support at the host end. In one case, Network Solutions staff required several weeks of troubleshooting before settling on this configuration change.
If you are currently experiencing either of the noted symptoms, making the mentioned changes may resolve the problem. Trying either change is surely better than simply reporting the problem to Blogger and sitting around waiting for them to resolve the issues on their own, while your blog grows stale.
And in yet other cases, some host firewalls use IP Address filtering, sourced from a list provided by Blogger. Not all Blogger documentation, including the list used for the IP address filter, is 100% up to date.
And of course you should also continue to keep aware of the many general network issues that can also cause problems with FTP Publishing.
>> Top
I've been writing about browser display differences for a while - known differences between Firefox and Internet Explorer are legendary. Most differences, though, are in how the blog gets rendered - simply different display appearance. Cosmetic issues, not all so minor but still cosmetic.
Then we have the case of "run4istrun.blogspot.com", which is intended to be published to "run4istrun.com". The problem was originally reported as "blogspot URL not redirecting as Blogger says it should (for an FTP Published blog)", as indeed it wasn't redirecting, when viewed in Safari. In the latter case, it was just another "404 Not Found".
One intermittent problem with FTP Publishing is that blogs published using FTP are having an annoying redirect notice (called by Blogger Support, the "interstitial"), implying some degree of possible insecurity, inserted in front of the home page when the BlogSpot URL is loaded. I reported this, first, several months ago. The Safari browser, in this case, simply causes more confusion.
This is what you expect (though not prefer) to see, in Firefox.You're about to be redirected.
This is what you see, in Safari, run in Windows.You're about to be redirected.
This is what you see, in Safari, run in Apple.This page can't be found.
A significant difference there, folks. Safari users, beware.
>> Top
So once again this week, we have various bloggers, publishing (wanting to do so, any way) to remote servers using FTP, and complaining of the well known errorYour publish is taking longer than expected.
Sometimes, having reported this to Blogger, a Blogger employee will come back almost immediately withWe reset the server, and you should be good to go.
Other times, this symptom will drag on for days, and weeks. Occasionally - and keep an open mind here - problems with the host server can contribute to this error.
While awaiting action by Blogger, you might do yourself and others a favour, and provide details of your problem (as best you are able).- Name of host server and connection type (FTP / SFTP).
- Geographical location of host server.
- Path, within the FTP server, of the blog.
- URL of blog.
- Name of template.
- How many posts in the blog?
- How many posts / days of posts in the main page?
- How many photos (average / best guess) in a typical post?
- How many photos (best guess) in the blog, but not in posts?
- How old is the blog?
- How is the blog archived (weekly, monthly, yearly)?
- How many posts (average / best guess) / archive period?
- What size (average / best guess) are your photos (160, 320, 480, 1600)?
- How many labels defined in the blog?
- How many posts / label, and labels / post (average / best guess)?
Note that- Blogs published by FTP use HTML and static publishing.
- The number and average size of statically published pages will affect the amount of time required to publish your blog.
- Each archive link, and each different label link, will be one more statically published page. The more posts in an archive, or the more posts with a given label, will make that static archive or label page larger.
- The amount of time required to publish the blog will, in turn, affect how likely you are to see the mentioned error
Your publish is taking longer than expected.
Considering all of the details, is it any wonder that you don't see that message more often? These are some reasons why I suspect that moving to custom domain publishing makes more sense, as your blog gets larger.
>> (Update 8/25 05:00): We see one example of where the host server was involved in the problem, and in finding a solution for the problem.
>> Top
Long ago, when you attempted a two factor authentication (account name / password) process with a server, the normal connection procedure would verify for the existence of a given account, and verify the password against that account. If either verification failed, a properly written server based script would tell the user what he was doing wrong - either "Invalid account" or "Invalid password".
Then security experts realised that if you issue an error saying "Invalid account", you were, in effect telling a possible intruder what accounts did not exist on the server in question - enough connection attempts would then tell an intruder what accounts did exist. This is a known hacking technique, called by some security experts "account name mapping". Knowing the existing accounts, the hacker can then try to guess the passwords on those accounts.
Some secure servers, made resistant to mapping, don't issue any error messages, they simply ignore your unsuccessful attempts (non existent account or invalid password) . Make too many unsuccessful attempts, and your IP address gets blackholed.
If you're a person trying to connect, you just keep trying - try another password, or another account name. If your IP address is blocked, you wait a while (5 minutes or so) and try again.
But what if you're not a person connecting interactively, but a person running a script? Like publishing from Blogger by FTP, to a distant host server? That complicates matters.
One of the problems with establishing a connection with a distant server is not knowing if the server in question is there, or is there but not responding, or is there but intentionally ignoring you. The Blogger FTP publishing script has to allow for all of these possibilities. Blogger doesn't want for you (really, they don't) to sit and watch the Spinner Of Death any longer than you want to watch it. They also don't want to come back to you and sayWe can't publish today, the other server isn't answering.
It's a tuning issue. Wait too long, and the bloggers get impatient. Don't wait long enough, and the bloggers get angry. Each distant host server will have different connectivity issues, and the issues will vary by current load, and by network status.
So add the authentication process on top of that, and add some servers that will simply ignore improperly authenticated connections. How is the Blogger FTP Process realistically expected to reliably connect (or not) to all distant host servers? Especially with some problems knowingly tolerated by the operators of the distant host servers?
So the next time that you can't publish your blog to your distant host server, don't just get into the forum and yellHey everybody, Blogger is hosed again.
Do some diagnostic work first. Please.
>> Top
Not all problems with FTP Publishing are caused by Blogger, directly or indirectly. Sometimes, the operators of the host servers, involved in the FTP publishing process, provide subtle yet significant clues to bigger problems. You have to keep your eyes open, though.
Here is an example, with a customer of Network Solutions.
My host is Network Solutions - yesterday they sent an e-mail reading
We are aware of an issue with FTP and UNIX packages. They will generally deny the first connection, but allow subsequent connections. We are requesting that our customers attempt to connect to their server twice until we have a resolution.
Blogger isn't going to (in reality, they can't, reliably) tweak their FTP publishing process to repeatedly attempt a connection with a host server, just because the operators can't solve their own server problems. This is a case where the customers have to get involved, and convince the server operators to fix their server problems.
>> (Update 8/25 5:00): It appears that this problem was related to security at Network Solutions.
Blogger publishes with "passive FTP". To overcome this, Network Solutions identified the IP addresses from which Blogger publishes, then "white-listed" those addresses to its servers so they would accept FTP uploads from Blogger.
>> (Update 8/4 14:00): We have an interesting communication (edited) from Network Solutions.
Hi this is Connie at Network Solutions. I’m writing to affirm that our engineering team is aware of the issue and they’re working diligently to resolve it. It’s a short-term issue, and we’re sorry about the difficulties you’ve experienced along the way. If you would, please try to reconnect to your server. If you continue to run into a snag please contact me at (email address edited).
>> Top
Security awareness, in almost every feature of every computer application, operating system, and security program, is reaching an intense level. Any time that you enter a password, don't be watching the screen and counting the number of "*" or "#" characters displayed there, expecting the count to match the number of characters you know that you put in the password.
Just in case there's somebody standing behind you, shoulder surfing your password entry process, a masked password of "n" number of characters won't necessarily be displayed as "n" number of "*" or "#" characters on the screen.
Blogger is part of the paranoia, too. In various places where Blogger accepts entry of a password, after you hit "Enter" or "Save", the number of "*" may change. This is to keep people from walking up to the screen, counting the number of "*" displayed there, and guessing that 7 "*" could be your wife's name. Or maybe the car that you drive. Or ... (I'm sure that you get the picture by now). When you see the number of "*" suddenly reduced, if you don't pay close attention, you might think that it's truncating the entry.
The above describes interactive entry of a password, after it's been set in a database. In one case, FTP password entry, this appears to be the case when you're setting the password for accessing the host server, for later use when you publish your blog.
As you enter a password, keep the count in your head. Don't be expecting to see the count verified on the screen, before or after you hit "Enter", consistently.
>> Top
Occasionally, settings which identify the location of your blog, relative to the FTP folder on the server where your blog is hosted, may change. Some changes may be related to changes at Blogger, other changes may be related to changes in the server itself. Symptoms may vary, but will typically mention denied access, or missing content.
Access is denied.
Requested action not taken: file unavailable.
The system cannot find the path specified.
Most frequently, the change required will be the relative root designation. The change will probably involve the main publishing path ("Settings" - "Publishing" - FTP Path) and / or the archives path ("Settings" - "Archiving" - Archive Path).
- If the current value is ".", change it to "/".
- If the current value is "/", change it to ".".
- If the current value is, for instance, "blog", change it to "/blog".
- If the current value is, for instance, "/blog", change it to "blog".
Publishing by FTP, to remote (third party) servers can be a challenge, and one of the unpreventable challenges will be the unpredictability of the third party maintenance policies. Try and be aware of changes being made, and encourage the support staff for the servers to provide you some documentation describing changes, when possible. Barring that, get used to trying these changes, on your own, when things stop working.
And, try to resist the temptation to blame Blogger for every problem. Some problem will require you, or you and the server support staff, to sort.
>> Top
Publishing a Blogger blog by FTP, to a third party server, presents a challenge, may I risk making an understatement. Bloggers choosing to host their blogs externally have traditionally been subject to numerous experiences, not all good. One of the least enjoyed is possibly seeing the adviceYour publish is taking longer than expected. To continue waiting for it to finish, click here.
It appears that a recent server change (some time in the last 3 to 6 months) at GoDaddy may be at least partially responsible for some of the FTP Publishing experiences, such as the latter advice.
GoDaddy appears to have 3 server configurations right now.- Linux, "hosting configuration 1.0", PHP 4.x.
- Linux, "hosting configuration 2.0", PHP 5.x.
- Windows, ASP.Net 1.1, IIS 6.0 .
In at least one case, service moved from Linux configuration 1.0 to configuration 2.0 appears to be related to the symptom discussed above.
According to the Original Poster in the thread linked above, service migrated from Linux V1.0 to Linux V2.0 is not reversible. That's not an unusual restriction for any IT service methodology. Unfortunately, that left him with the sole option of moving to the third configuration, hosting on a Windows platform. People changing from Linux to Windows server hosting (or vice versa) should be aware of some significant technical differences between the two platforms, such as (but probably not only) differences in case sensitivity and in path description.
>> Top
Blogger is constantly fixing problems with FTP publishing, and more problems come up at the same time. Anybody who says that there is one problem, and waits for the one problem to be fixed, is assuring that the one problem won't ever be fixed.
FTP Publishing involves scripted communication with hundreds of different "servers" (with Blogger acting like a "client") all over the world. Each different server, being owned by a different company, will be different from each other server; and each server will have different problems, which make the the Blogger scripts progressively more complex. Sometimes, changes by the server owner to some, though not all servers, may make a difference.
And just because you were able to publish to your blog last week, that doesn't assure that you will be able to publish this week. Nor does it assure that somebody else will be able to publish today.
What all of this means is that anybody who insists that his problem has to be fixed by Blogger, and waits while Blogger fixes it, will possibly be waiting a good long time. Some problems will involve you, and some will involve your server host support team. Each problem really should be attacked by three parties, working together.
When you have problems, checking your settings, and verifying them against updated instructions from your host support team, is a good place to start. Maybe a look at the server access logs is a good idea too.
Just don't post your complaint, go about your daily business, and wait. Get to work, and get involved.
>> Top
I've been discussing FTP Publishing, and comparing it to native BlogSpot and Custom Domain publishing, for many months. Besides the functionality and style differences, there are network issues - several key differences between custom domain and FTP publishing, which cause problems. The problems will come and go, and will randomly affect a different segment of the blogger population each time.
- Authentication. Blogs published by FTP are copied to servers with differing, and not always appropriately maintained, authentication policies.
- Control. Blogs published by FTP are copied to servers that aren't owned or supported by Google.
- Distance. Blogs published by FTP are copied to servers that are distant from Google.
- Dynamics. Blogs published by FTP are published statically. Each time a post is published, the entire blog is copied to the distant server.
- Overall. Looking at these issues, what should we expect?
Authentication
Authentication, the process of establishing your identity, and your right to access a given host server, isn't a simple process. Modern security precautions contribute to problems with establishing an authenticated FTP connection.
When you publish your blog to a Google server, you're already authenticated. This is simply not an issue.
Control
There are hundreds of servers, each with a different owner, that are used for FTP published hosting. Each server, with a different owner, will be setup and maintained differently. Sometimes, a server owner may even change the configuration on some, though not all, servers. Even though any single detail of the setup or maintenance, of any server, can affect the ability of Blogger to communicate with that server, Blogger has no way of knowing what problems it may face at any time. Any given server, that was successfully published to yesterday, may change at any time. Some controls may depend upon documentation by Blogger, which however benevolent the intent, simply won't be 100% reliable.
With blogs published to a Google server, the entire publishing process is controlled and supported by Google. Every detail of each server is predictable. This makes publishing to a Google server much more reliable.
Distance
The hundreds of FTP published host servers are located all over the world. Besides the ownership factor, the distance factor is different for each server. A constantly changing distance (and network speed) between the Blogger servers and the FTP publishing hosts servers makes for a challenge, and ever varying stability.
With blogs published to a Google server, the entire publishing process is local. Both Blogger and BlogSpot / Google servers are on the same network, again owned and supported by Google. This makes publishing through the Google network much more reliable.
Dynamics
When you publish a blog using FTP, you're doing static publishing. The entire blog is copied from the Blogger server to the FTP publishing host server.
Most Blogger blogs have Layouts templates and are published dynamically. Do you remember the Spinner of Death? For most of us, it's but a distant memory, as our publishing process involves each blog post, dynamically. If you publish or update 1 post, that's all that gets published, and that only when the post is initially referenced. If you update the template, each post is, again, published when it is referenced.
This lets you, the blog owner, get on with your life and work on the next post, while your readers initiate the actual publishing of the posts. The older posts don't even get republished at all, if they aren't needed (read by the blog readers). With the majority of bloggers using Layouts templates and dynamic publishing, you'll find that Blogger resources will be allocated for that.
When you publish a blog using FTP, the entire blog gets copied to the FTP publishing host server, each time that you publish a post, or each time that you update the template. Many blogs published by FTP are commercial in nature, making the average blog larger (you have to pay for blog hosting, and larger blogs are generally more profitable), and constantly growing even larger still. FTP publishing may be done from less Blogger servers too, increasing the overall workload on the specific servers used for that task.
Absolute size * ever increasing size * the necessity of copying the entire blog each time you publish * possible resource limitations makes static publishing a significant problem.
The Overall Effect
Taking these issues together, do you not see a problem? Combining authentication issues * lack of control * distance and network issues * static publishing issues, produces inevitable results.
- Speed. You never know how long a blog is going to take to publish, at any time.
- Stability. You never know if a blog is even going to publish successfully, at any time.
But wait - - there's more.
One of the challenges of FTP publishing is the diagnostics (or lack thereof) when publishing. If you can use an FTP client interactively sometime, watch the FTP log as you copy a file. You'll see a command or two when the copying process finishes, and a response from the FTP server when the copying finishes.
What if the FTP server simply stops responding? This will happen, and the client server (or Blogger script) has no way of knowing when this happens. At any time, if the script has not finished a copy, there's no definitive way to tell if the script (the copy process) will ever finish. Combine the speed and stability issues, and how do you know if an FTP copy process will be successful?
The Blogger script can only estimate how long the publishing should take, run a timer, and stop when the time expires. If the timer expires before the copy finishes, the copy is aborted, and your publishing doesn't complete. Or, you watch the Spinner Of Death for an eternity, before giving up.
Watch It Spin.
Small wonder that Blogger Support would prefer that more people publish to Google servers.
>> (Update 9/4): Besides the many details discussed above, there are two newly discovered tweaks, which have provided relief to some.
>> Top
Some time ago, in my comprehensive comparison of Custom Domain vs FTP Publishing, I suggested thatFTP publishing has a limited life span. From an economic and support viewpoint, it makes more sense for Blogger to concentrate its attention on Custom Domain publishing.
This week, we have a new, annoying problem with FTP publishing, which, regardless of what may or may not be stated by Blogger, does not seem to be solved. And we have a possible reliability improvement in custom domain publishing, with the dreaded "404 Not Found" problem, recently, becoming less frequently reported.
It's possible that my prior suspicion may become reality sometime in the near future. Some of you, currently publishing your blogs using FTP Publishing, may do well to consider changing to Custom Domain Publishing. And in doing so, you should consider several key issues.- If you initially published your blog to the FTP server prior to November 2007, it's possible that the original BlogSpot URL isn't associated with the external URL. If the BlogSpot URL is associated with the blog, it's probably through some workarounds that you may have put into place, on your own. With Custom Domain publishing, the BlogSpot URL used to setup the blog is automatically redirected to the Custom Domain URL. You'll need to publish the blog to BlogSpot, to ensure a BlogSpot URL is in place first.
- If you're hosting a domain on an external server, you're probably hosting photos there too. You may want to plan to migrate the photos, and host them on Google servers, unless you want to keep maintaining the FTP server with the existing photos. Unfortunately, migrating the photos will involve manual effort.
- If you're hosting a domain on an external server, you will need to ensure that the registrar for the domain provides DNS servers that support CNAME referral. If not, you'll want to find another registrar, or buy another domain.
- If you're hosting a web site on an external server, when you move to hosting the web site (blog) on a custom domain, the structure of the blog, and some URLs, may change. If the blog is part of a web site, you'll want to update the web site, to reflect the change.
- With an FTP published blog, you have folder and file control. You may have files, installed in the root of the blog, that enable automated processes, such as search engine spiders, to index the blog. You'll have to use meta tag records for similar functions, when your blog is published back to Blogger.
- When the blog is published back to Blogger, the URLs of some files will likely change, to include publishing month, and title hash, uniformly. If you have any external or internal references to individual posts (and most blogs do), be aware of this change. Plan to use a missing files host, to reduce the impact of this issue.
With all of that said, let's plan the actual move.- Carefully consider the relative advantages and disadvantages of FTP and Custom Domain publishing.
- Go through the issues list above, and consider each as it applies to your blog.
- If the move from FTP to custom domain involves a change in URL, let your readers know in advance.
- Publish the blog back to a BlogSpot URL.
- Update the DNS records to reflect the custom domain setup.
- Publish the blog to the custom domain.
We can actually describe steps 5 and 6 in combination, as setup a custom domain. You'll have 2 alternatives, here.- If you can use the existing domain, just update or add a "CNAME" referral for the blog, redirecting it to "ghs.google.com". Here, you'll use the "Advanced Settings" wizard.
- If you need a new domain for the blog, use "Buy A Domain", and you're done.
Either way, this task has been tried and tested by hundreds of bloggers before you, if you start from a BlogSpot published blog.
>> Top
For many years, using "Next Blog" for surfing through the Blogosphere has been a dodgy activity.
No matter when you surfed, you were sure to find something pretty nasty, and frequently hazardous to the health of your computer (and maybe to you).
In January 2008, that changed. Blogger started scanning blogs for undesirable content, and blocked many nasty blogs from being targeted by "Next Blog" surfing. Besides using automated blog scanning, they also provided a voluntary classification of our blogs.
Not all potential readers will be encouraged, when seeing a content warning.
If someone genuinely wants to host possibly offensive content, he can do that - inaccessible from "Next Blog" or casual surfing, and behind a warning page.
In some cases, this is a voluntary classification, accessible from Settings - Other - "Adult Content". In other cases, this warning is applied to your blog by a faceless bot, similar to the much hated anti-spam bots.
The "Content Warning" screen, that your readers are now faced with, every time they surf to your blog, has its downsides.
The warning does not block the spiders - though it does limit indexed content.
One of the problems of the "Content Warning" screen is that the search engine spiders, when they index the blog, pick up the text of the warning, rather than the blog name and description.
When you look at the search hits that include such a blog, that's what you will see. That won't be good for your reader confidence, unless they expect to see objectionable content, anyway.
Even though a blog is behind a "Content Warning", though, it is still being indexed.
You can use Search Console to understand this better. If there is any problem with indexing the web site (blog), a GWT / SC report will help you sort that.
The warning also interferes with crawling redirected blogs.
Another interstitial warning comes with redirected blogs, published to either a custom domain (sometimes), or to an external server by FTP (frequently).
The Content Warning interstitial advice also appears to interfere with private blog access. If you have a restricted access blog, you may want to avoid involvement with the interstitial warning, voluntary or involuntary.
And recently, we've noted that it degrades the quality of information from visitor meters.
One popular feature of better visitor meters is the ability to see what web page your visitors are coming from (the "referer"). When the interstitial warning page is displayed ahead of the blog, it is shown as the referer page, and you lose the ability to tell what actual web site your visitors really come from.
All that aside, remember one detail - just because a blog is indexed, in the search engine of your choice, does not guarantee it good visibility, in a search hit list. A search hit list indexes web pages in order of popularity.
If your blog covers a popular topic, through no fault of yours, other more popular web sites may appear in the list above yours. If the description of your blog, in the search hit list, shows simply the interstitial text, you may not get as many new readers, as you would hope for.
Content Warning Some readers may find the content of this blog objectionable. In general, Google does not review nor do we endorse the content of this or any blog.
That warning doesn't tell people anything useful about your blog. Less readers = less reputation with the search engines - and less readers still.
So, if you have a Content Warning in your blog, you may lose search engine reputation, and you may not see your newer posts listed in the search hit lists as promptly. But check Google Webmaster Tools, to see if there's actual indexing problems. Chances are - there's not.
Blogs published using FTP have always provided a challenge for Blogger Support, as well as for their owners. This week, the complaint level, in general, is a bit lower than immediately previous.
There is a current, new frustration many bloggers are dealing with, when publishing by FTP - publishing with attachments, such as photos and videos.Your publishing is taking longer than expected.
One blogger has done some analysis of the symptoms, and has provided an (apparently necessarily) intricate workaround for the problem.I have figured out that the current failure is *after* the images (& hopefully same for video) are uploaded. The files have been ftp-ed but the names of the files are never added to the blog entry for you.
Meanwhile, back at Google, I have word from the guys who make it all workwe're certain it's something on our end so we are working to fix it
So despite any authoritative forum updates by a Blogger Employee, the problem is known and is being diagnosed.
>> Top
Many different reports are seen in the forums, this month, about problems with FTP publishing. The old "Your publish is taking longer than expected ..." error is reported a lot. Alternatively, some folks report seeing no error, yet their posts simply don't end up on the blog.
Blogger Support will try to help you - really. As long as you report the problem objectively, and wait patiently. And they can help you best, when it's a problem that they can solve.
Some problems they can't help you solve, or at least can't help you as easily as you can help yourself. Problems with FTP Settings are problems that you can solve, on your own, a lot quicker than Blogger can solve for you.
If you have a problem with FTP Publishing, report the problem. And while you're waiting for their attention, spend some time diagnosing the problem on your own.I fished around and discovered that my host, pair.com, using the special additional login username and password that I added for Blogger, was automatically routing posts to my blog directory. So what happened is that instead of files being uploaded to
pair.com/users/me/public_html/blog/
they went topair.com/users/me/public_html/blog/users/me/public_html/blog/
This is an example of good diagnostic work. Maybe Blogger would have eventually figured out the problem, by looking at the settings for the blog. Maybe not. Maybe Blogger changed the way they process the settings. If so, this report will hopefully help them identify their problem. It certainly won't hurt.
>> Top
Publishing a blog to an external server, using FTP, has always presented interesting challenges. I've been writing about those challenges for some time, and occasionally describing their seemingly random nature. This week, we see one example of the randomness, which is being experienced by those publishing to Yahoo Small Business.I got on the phone with Yahoo Small Business, and went through the trouble shooting process. ... One of the things about the Yahoo Small Business accounts is Yahoo teamed up with ATT SBC. With that team up, it created a weird log on user name, with two @@ in the user name to use FTP publishing. For example: you need both the [email address]@user-[email address]
The solution, in this case, and recommended by Yahoo Small Business is tocreate another FTP User ID independent of the main User ID.
In other words, Yahoo Small Business made a change, it wasn't successfully communicated to their customers, and it took a joint session between one customer and one company representative to realise the odditya weird log on user name, with two @@ in the user name
Looking further, we see additional details. Having created a Yahoo FTP User ID, we have to make that User ID usable.once you've added the new FTP user/password in Small Business, be sure to click the link that says "Enable FTP access" in the "FTP Access Point" column. This gives that new username access to publish on your whole site.
I suspect this is simply one example why Google Custom Domains should be the solution of choice for publishing a blog to a non-BlogSpot URL.
Yahoo Small Business is simply one FTP host. How many others might there be, with similar peccadillo's?
>> Top
