You are describing a problem that seems to have cropped up again recently. (There have been rolling reports over the past year of similar behavior.) Here is precisely what is going on. As to how to fix it, that’s less clear.
All of the “Scripty”, “FX”, and “SNW” Actions use the prototype.js and scriptaculous.js libraries for their various effects. In order to improve the performance of your sites, these Actions link to the Google CDN (content delivery network) for these library scripts. During the publish process, each script phones home to Google to see if you are on line at the moment of publishing or not. This test is meant to be very innocuous – a single ping request is sent to the server ajax.googleapis.com, and if a reply comes, the Action knows to publish the public CDN version of the JavaScript library code into your page. This step was taken because there wasn’t any other way to determine if you were working on or off-line, and we wanted to ensure that your effects would still work either way.
The problem with this approach comes when you consider how a ping can fail. In the case of you being off line “for real”, the reply comes instantly – and that was the error state that the Action code was written to comprehend and act upon. But when you have a subtle problem with your network, something that causes “packet loss” but not an outright failure of all connections, then the ping gets sent, and the system waits very patiently for it to time out. This can take many seconds – an eternity for a publish loop in Freeway. Once this particular problem occurs, there’s no way out. The guard code that keeps an Action from hanging Freeway kicks in, and protects your system.
Joe Billings at Softpress and I have been discussing ways around this problem, while preserving the great benefits of using CDN-hosted scripts (high availability, browser caching across sites, unlimited free bandwidth) for Action users. One approach is just to assume everyone is always on line. While this is categorically not always true, it is a reasonable assumption for a Web developer in this day and age. We have not released any code to back up this approach, but we are working on it. I have been bitten by this bug many times, usually at times when my feeble network is busy downloading a big Apple update in the background.
As far as how you can solve your problems right now, there’s a couple of ways to fix this. The first is to turn your network off while publishing. This forces the Actions to publish the static local files for each of the library scripts. This of course disables the CDN code, and your site is a little bit slower to load. (It’s also a hassle to toggle your network while publishing. I feel your pain.)
Another approach is to crack open the Action bundle and change the definition of this function wherever it is found within each file therein:
var connected = function(){
if(fwShellCommand){
return fwShellCommand('ping -c1 -i1 http://ajax.googleapis.com');
}else{
var osa=new FWOSAInterpreter;
osa.fwWrite('do shell script "curl ajax.googleapis.com"');
osa.fwCompile();
return osa.fwRun();
}
}
add this line at the top:
var connected = function(){
return true; // <- add here
if(fwShellCommand){
return fwShellCommand('ping -c1 -i1 http://ajax.googleapis.com');
}else{
var osa=new FWOSAInterpreter;
osa.fwWrite('do shell script "curl ajax.googleapis.com"');
osa.fwCompile();
return osa.fwRun();
}
}
This “short-circuits” the function, causing it to skip everything after that line, and telling Freeway that you are on-line.
Finally, you can look at the bright side, and consider this Action to be a very sensitive test for your network’s health. Raising a support ticket to your ISP, telling them that you are experiencing packet loss, is not a bad idea either. To back this up, open up your Applications/Utilities/Terminal.app and try the following command:
ping -c 100 ajax.googleapis.com
The result should be 100 packets sent and received, 0% packet loss. Anything else, and you have a problem. Copy and paste the entire exchange (request and response) into your trouble ticket. Just showing that to your ISP will alert them that you’re not the usual “how many blinking lights do you see on your modem” customer, and they may escalate the resolution for you.
I don’t have any date to give you for a complete resolution of this issue, but please be aware that we are working on it.
Walter
On Dec 13, 2012, at 7:51 AM, Marco wrote:
Hello,
I have a problem with Javascript error when I try to upload or publish my site. It happened before occasionally, but now all Spawn New Window and Carousel actions are listed in the error window. I can click ‘OK’ to ignore the errors, but then I get another message saying that an action took to much time and will be stopped. When i click ‘OK’, another window appears that I can publish my site because of a JavaScript error.
This will mean I will have to remove all mentioned actions and re-apply them (at least that worked in the past). I’m still building the website so not a big problem for now, but what if I have the website completed with more than 100 pages and hundreds of actions applied? That will take me a full day to delete and re-apply actions.
Marco
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options
freewaytalk mailing list
email@hidden
Update your subscriptions at:
http://freewaytalk.net/person/options