Not just you Furry.
As a long time RW user and very much a fan of RW6 I have to say that the FTP stalling and the appalling beach balling (which I don’t get on any application except RW) take the fun out of using what could be a flagship Mac application.
Strange how some users get this problem and others don’t. I run 6 different sites for people on 3 hosts using the built in FTP and not had any problems since 6.0.1, even with daily updates on some sites (running Yosemite on a 2009 MacPro Quad with 12Gb RAM).
I assume it’s file size.
I use RW for our business site which I’m adding to all the time.
I’m now over 150MB with 125 odd pages. (no images - they are all warehoused).
Presumably this is now uncomfortable for RW’s capabilities.
The project I’m running is around 40 pages - the mac has 16 gig of ram and its really, really bad - quite possibly the worst behaved of my current crop of apps being used which includes the full Adobe suite / Xcode dev tools.
Its probably the first time in ages, I’ve considered moving away from RW - which is a royal pain as Foundation on RW is a sheer joy to use.
I have to agree with @DaveFox, and I am using RapidWeaver with some huge sites as well, on 4 different machines and have only ever seen an FTP issue maybe a dozen times, and most were before I set the number of connections lower. Very strange indeed.
Since 6.2.1 and stepping back a notch on the number of connections, I haven’t had any real problems, that were not self induced. My main site must be well over 100 pages and has images included. I am changing it all the time and even trouble with my fibre connection, which turned out to be a noisy telephone line, didn’t confuse it (it did, almost everything else!).
You know, one thing that has perplexed me about the whole performance (and FTP) issue with RW6.x is that when a user comes forward declaring issues RMS ask for a copy of the project - in the hope of reproducing it.
Do RMS ever try remote desktop type support sessions to see exactly what the user is seeing/doing? Would that not vastly increase the likelihood of being able to observe the problem first hand? I worry that I have seen references to having to set up test machines with the same stacks/plugins etc is time consuming etc… too right. Would it not be better to get right onto the client machine, turn on the logging and get what you need immediately?
You would also be able to test that the issue is actually fixed by testing any fixes on the same machine. Is that not a better approach?
@kryten We have done in the past, but our first port of call is to try and re-create the issue locally with the users file.
If we don’t get anywhere with these two files we’ll look at remote desktop.
For the record: The FTP in the latest build of RapidWeaver is by far and away the most solid and reliable FTP engine we’ve ever had (and we’re still working on improving it) — We’re seeing far fewer users reporting issues than ever before, so we’re definitely making progress…
I’ve got a couple of hectic weeks ahead but then it’s my intention to spend some serious time updating and adding product to our site at which point I’ll turn on the logging feature and report back.
I’d be interested in your opinion on site size. Am I now pushing the boundaries of RW6’s capabilities at 150MB (no images)?
Maybe I’m asking too much of the ‘system’. The ftp upload doesn’t actually fail that often it’s just that after the addition of a single page the total time for export and then upload seems to take such a long time that if there is a failure (usually the last couple of files) it’s exaggerated.
My main gripe from my initial post was with the beach balling. My pages are fairly stack heavy but I rarely stray from JW’s Foundation stacks so I assume there’s reasonable compatibility.
As mentioned all my images are warehoused so I assume that doesn’t take up resources.
I don’t get a beachball on any other application I use with my reasonably specced and recent MBP 15. The fact that hovering over the dock stops a particularly bad spin suggests that a solution is possible.