Frequent publishing/connecting problems in RW6.4


(Cris Baker) #1

Hi,

Now I’ve got my site working properly in Yosemite and RW6, I’m ignoring the file proliferation problem (my site has ballooned from a few hundred files in RW5 to several thousand in RW6.)

But RW6.4 seems very reluctant to publish my http://www.DiscourageCriminals.net site. It just sits there doing nothing once it get to checking the connection the same as Test Connection.

So I now first go Publishing setup… > Test Connection in the RW6 publishing setup pane, and only when that says it’s fine then do I try and publish. But much if not most of the time, when I Test Connection, it doesn’t respond so I cancel, wait a bit and try again. Then, after several attempts, it usually works.

For example, it’s just refused to test the connection several times again, see:

47%20PM

RW6 won’t Test Connection at 8.08.47 PM.png

and I had the same refusal one and two minutes later…

Any idea why this is happening and how to resolve it. Note logging into my site to publish with Transmit has no holdup like this, so it would seem to be a RW6 issue…

Why do so many people use CyberDuck or Transmit to publish instead of RW6? Is publishing in RW6 a recognized problem?

warm regards, Cris
Wednesday, 2018/06/06


(Jason Bostick) #2

RW Publishing has mostly always worked well for me. The odd time that I’ve needed to use an FTP client, the ‘export to local folder’ is super fast, which would be appealing to some, and then Transmit and the like are fully FTP apps, so they likely have features that some prefer in their workflow.

For me, it’s an extra step and the built-in publishing works well.

If you’re not being able to complete a test, it suggests that something in your setup isn’t working. My first thought is to doublecheck your path. A user in a recent post had mentioned that their host had changed their publishing setup and neglected to notify them…

You could also try a different mode (active vs passive), and lower the number of concurrent connections but I’d double check the path first.


(Cris Baker) #3

Thanks Jason, RW6 stores the publishing parameters for my site, and I don’t reenter them when I next try to publish. RW seems to do a bit of processing, and then goes to the site and just sits there doing nothing. I’ve already checked with Greg at Chillidoghosting.com

These publishing parameters also work immediately in Transmit, so it seems unlikely they are the cause of the problem.

Where do I change the number of concurrent connections in RW6?

But why do people use an FTP client instead of RW to publish. It’s several steps and a bit of a pain, so what are the reasons for preferring not to use the inbuilt RW publishing facilities?

warm regards, Cris
Thursday, 2018/06/07 1006


(scott williams) #4

Chris, the connections are set from the RW preferences menu. click publishing


(Doug Bennett) #5

You might try switching to SFTP from FTP. Chilidog does support that. You do have to add a port number(I think it’s 23261 for chilidog) to the server address.

ftp.lifestrategies.com:23261

SFTP is a lot more secure (FTP has no security login info including passwords are sent in the clear) and usually more reliable.

That answer would vary for each user. Many people find products like Transmit, Forklift, or YummyFTP to be more reliable. Some users prefer to test their sites locally with servers like MAMP prior to publishing. Many users have to publish other assets like Images(warehoused) and files that are not part of the RapidWeaver project file.
Also RW7 the publishing engine was redone, not sure if it’s any more reliable but:

https://rapidweavercommunity.com/tutorials/new-features-in-rapidweaver-7/new-publishing-engine


(Cris Baker) #6

Thanks Scott, thanks Doug.

After some initial hassles, SFTP is now working and has published three times (more slowly) on the bounce. I’m hoping it’ll keep publishing reliably rather than complaining.

So I’m hoping this has now resolved this issue.

much appreciate all your help, warm regards,
Cris
Friday, 2018/06/08 1747


(system) #7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.