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
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
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
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
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
