@dan – Looks like a long time user is having some difficulties with publishing and is going to certainly switch to WordPress without some assistance. Wonder if there’s anything you could do to help this user out.
1 Like
Yeah, I wonder what’s going on, hopefully it’s just bad luck (and not RW at fault) 
Am certainly keeping an eye on it and will chime in when needed…
Thanks for the heads-up!
Have a good weekend.
Cheers
Dan
Sounds like a plan.
Another one cropped up today that sounds similar, too:
You as well. 
This is happening more and more.
Are you ever going to fix the publishing log issue?
It really can help figure out what is happening.
These folks are able to publish with Transmit or FileZilla without issue.
Definitely seems to be occurring more and more…
Could it be that maybe users are migrating to M1 machines and/or Big Sur and losing permission to the password in the keychain?
Maybe it’s an error condition like that sort of thing that doesn’t come up often.
Does anyone know of one of these that the user managed to get working again?
Something like deleting the password, then re-adding it again? I’m not interested in telling everyone to use the workaround – just hunting for more data as to the root cause. If fiddling with the password gets it working again, then there’s a good chance the issue is associated with the password.
And knowing that would probably help isolate the bug and create a repeatable test-case.
Isaiah
tl;dr: is there a quick way to tell if this is my fault? 
I noticed that one user was able to work around their problems by removing some specific pages. I don’t know that it’s a general solution here – but it made me wonder…
@dan – is there any way to know with near 100% certainty:
- this is an FTP connection issue
- this is an app exception
- this is a plug-in exception
i.e. if a plug-in throws an exception during the export methods for the Publish, does RW report that error differently than the errors coming from the app, or coming from the FTP process?
RW 8.6 really killed a bunch of my janky older plug-ins. If the user doesn’t interact with those pages often, the pages will never load and so the user won’t ever have problems… until they try to publish the page. The page will be loaded, asked to export, and if it’s a janky old plug-in tripped up by RW 8.6+ then 
I still think just asking the user to re-type their password probably fixes most FTP issues – but if a user has been stuck on it for 3 months it’s got to be something a lot weirder than that, right?
1 Like
I don’t have any answers yet, but we’re going to take a look at the publishing issues and publishing error reporting on Monday. Looks like there may be an 8.8.2 in the near future…
@Isaiah you (or anyone else) don’t happen to have a project with a busted old page in it do you? Would sure be handy.
If anyone has more input on the publishing issues please let us know, it seems like this is going to be one of those bugs/issues that’s a nightmare to track down 
No. I was just hoping on and trying to help brainstorm some ideas. I haven’t had an FTP question come to my inbox for well over a month – probably more.
I think they mostly go directly to you or to the forum.
it seems like this is going to be one of those bugs/issues that’s a nightmare to track down
right now the largest problem seems to be lack of information. both for the user and for devs.
And… OK… I’m just brainstorming here – feel free to replace this with any other data collection mechanism…
users mostly seem to report “it failed” and then that’s about it. most of these forum threads don’t even know if it’s a login/password failure or they chose FTPS when they needed SFTP. but those things are all knowable to the software stack.
the info buttons look nice – but if users don’t click them then dismiss the box, then there’s no way to get it back without re-running things. and a lot of these failures are coming from long FTPs on big sites. so users are going to be reluctant to re-run – and re-running isn’t guaranteed to have the same results.
we need a way to get info from past failures – and maybe successes too.
it might be worth putting some more detailed logging somewhere. so we could direct the user to "click the left bottom corner of the FTP window while holding down the control key. something that pulls up a log that provides more detailed info about exactly where/how the FTP process shut down.
and make it something that’s sticky – maybe just store the last 5 failures with dates and times.
i mean i know a HUGE percentage of these are going to just be login/password failures. but that’s something the ftp-stack should be able to identify 100% of the time: if a host really was contacted and there really was an FTP server there. but that FTP server doesn’t like the credentials that should be flagged in big letters in the log – so we can just straight away ignore those users.
1 Like
Okay, well that’s one problem fixed. PEBCAK 
In other news. We’re working on RapidWeaver 8.8.2 right now. It will have better and more visible FTP error logging…
1 Like
RapidWeaver 8.8.2 is now available for download 
Here’s what’s new:
- Fixed an issue where Upload Logging would not be recorded
- Added “Send Upload Logging” button to the publishing window
- Added preference to automatically close publishing window
If you see any users run in publishing issues, direct them to this page:
https://help.realmacsoftware.com/kb/guide/en/how-to-fix-publishing-issues-Z9eDEW9hUH/Steps/233393