Copy link to clipboard
Copied
We noticed that the files appear to go through, when we published to an FTP site. The GUI shows progress, and but when we later checked the server, the files were not there. As a test we deleted all files and directories off the server and started again. After it looked completed no files were on the server. We had to publish to the server using a batch file. Is this a bug? We selected Republish All on the Publish settings.
Copy link to clipboard
Copied
To rule out any issue with firewalls, etc. have you tried manually FTPing the contents of the local SSL folder to the server?
Copy link to clipboard
Copied
I checked with the programmer, and he says yes. He used Winscp, and tried both FTP and SCP protocols. It worked. However, Robohelp did NOT work. Any thoughts?
Thanks,
Maureen
Copy link to clipboard
Copied
And the manual FTP was done on the same machine (same user profile) that is trying to upload it via RH?
Copy link to clipboard
Copied
The programmer did it remotely on my machine, using my login. He deleted the entire directory, and tried multiple times to publish with
the FTP option. It never worked. He was able to do it with winSCP every time. He thinks it's a bug, and wants me to report it. How do I do that?
Copy link to clipboard
Copied
Hmm, nobody else seems to be reporting this. Here's a link from Rick Stone's signature line to use - http://www.Adobe.com/cfusion/mmform/index.cfm?name=wishform&product=38 but you're probably not going to see any action to help you out in the immediate future.
Has this ever worked for you? If so, what's changed? If not, then maybe it's worth having a look at what sort of settings you've selected in your SSL layout. Use the camera icon (in the web interface) to post images of your settings.
Copy link to clipboard
Copied
This is the first time this company has ever used Robohelp. I've used it in the past, but always used the file upload option - which works fine when I publish to the local test drive. However, we've had to jerry-rig a batch file to upload to two remote servers, and it's taking way too long. Hours. He's checking on the HTTP option, but would rather do FTP, if he could get it to work. We tried any number of tests and it never works, uploading one not the other, etc. Uploading child projects only and everything else we could think of. We both studied the path character by character and matched it exacly to the destination path, so it wasn't a typo. See what you think...and thanks for your help!
Copy link to clipboard
Copied
Everything looks ok to me; but then again, I don't publish my help to a webserver. Maybe Colum can chime in?
I wonder if using an IP address rather than a name might be any different? I'd be tempted to try a freebie FTP client like Filezilla and use the same settings in it to see if files got transferred. The RH FTP client is pretty simple (some have had complaints about it being too simple).
Copy link to clipboard
Copied
Hi, Maureen
It's been a long time since I've done this, but as I recall, the WebHelp Publisher chokes on FTP sites that are directed to "virtual directories". In other words if you have a primary FTP Server, it is quite common to create virtual directories with their own names. The odd thing is, if you use a garden variety FTP client (like filezilla, WSFTP, etc.) this may work just fine.
But, unless something has changed in the past year or so, the WebHelp publishing wizard does not honor virtual directories. I just tested this with my IIS web server. When I tried to publish to my regular FTP site that points to a virtual directory, it did not work.
However, I then created a clean new FTP site. Now, this arrangement works like a charm!
So ask your IT folks if they can make sure they are not publishing to a virtual directory.
Thanks
john
John Daigle
Adobe Certified RoboHelp and Captivate Instructor
Evergreen, Colorado
www.showmethedemo.com
Copy link to clipboard
Copied
Thank you so much! I passed along the suggestions to the programmer. We'll test them next week and let you know.
Maureen
Copy link to clipboard
Copied
Here is what we learned in further testing. The programmer says it is NOT a virtual directory, and that it also didn't work when he tried to use an IP address. What apparently happens is that Robohelp doesn't recognize the leading slash (/) as indication that the files should load to the root. Instead, it loads the files to the home/mgilliland directory, and we can't publish from there. We also can't hard code the path (I asked) to load to the root any other way.
It's been a very long time, and I'm not a programmer, but it seems to me that the relative paths I always dealt with had two slashes (or more? I can't recall) to indicate the root directory. We're working on a UNIX server, which the programmer says is different - that one slash is the correct command. I'm wondering if Robohelp is reading it for another kind of server, and only going down one step instead of to the root, when it encounters a single slash.
The programmer insists this is a bug. Our work around - obviously not the best solution - is to give me my own directory. It's either that or the very slow batch file.
Who do I report this to? Does someone have any ideas on what works with a UNIX server?
Thanks!
Copy link to clipboard
Copied
Hi, sorry you're still having problems.
My IT network knowledge is very limited but I wonder if the UNIX case sensitivity issue is at play here?
I notice in message #6 that you have not checked the "Use Lowercase file names (Recommended for UNIX)" box.
Because UNIX is case sensitive I wonder if this is causing a problem somewhere in the mix?
This is a wild guess. The reason I am skeptical that this is a problem, is that your non-RoboHelp FTP clients seem to work.
Meanwhile, I will check with some other sources who may know more about this, but wanted to pass this along just in case.
john
Copy link to clipboard
Copied
This will seem like an odd question because you already mention that this is the first time the company has used RoboHelp.
However, with regard to the possiblity that there is a "bug" involved here, is it remotely possible that you would have access to RoboHelp *8* somewhere in the company?
The idea would be to have a small sample project that you could use to test the Publishing wizard using the same parameters you've used in the RH 9 version. If you publish successfully with RH 8, it would support the idea that there is an issue with RH 9.
Thanks
john
Copy link to clipboard
Copied
Unfortunately, I have no access to RH8. However, the programmer insists something is wrong.
I have a question. We tried clicking the option for lower case file names on the Unix server, and it didn't work - everything went to the wrong folder again. However, I watched the files transfer to the server, and they still had upper case letters in them. What is that option supposed to do, exactly? Do I have to go through every project and change the file names to lower case in order for this to work?
Furthermore, why does Robohelp deliver the files to the wrong folder on the server? Why does it insist on placing all the files in the home/mgilliland/ folder instead of at the root of the directory?
Is there a developer line the programmer can call?
Thanks!
Copy link to clipboard
Copied
Hi Maureen
The fact that you say the files are going to the wrong place certainly tells us something is munged and incorrectly configured somewhere. You need to re-investigate your configuration of Publishing Options. RoboHelp only does what you tell it to.
As for the lower case bit, that should cause all your output files to be converted to lower case naming. Including all internal links inside topics that point to these files.
Cheers... Rick
Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7, 8 or 9 within the day! |
Copy link to clipboard
Copied
Well, I called and got through to someone who read this thread and discussed it with someone at Adobe. Apparently this is a known issue, and they don't have a resolution yet. At least we can stop messing around with it, and move forward with the temporary fix until they figure it out.
Thanks for your help everyone!
Maureen
Copy link to clipboard
Copied
I am seeing the same issue, even though I've specified a diretory to publish to RH9 can't seem to escape my unix home directory. Perhaps the Robohelp team needs to go have a chat with the dreamweaver team, they seem to have sorted this out years ago.
Copy link to clipboard
Copied
We went for months back and forth with Adobe about this, with conference calls to India and a number of emails. The team never addressed the issue, and closed the case by stating it was "resolved." The resolution was to simply close the case after three months without fixing anything. Because they were done.
Our programmers created batch files to upload the files to the server. You can't do it from Robohelp because the application doesn't understand "root directory" and always forces the upload into a sub-folder (your home directory), where it doesn't work. We also had to explain the concept of "root directory" to their "head engineer" who couldn't seem to wrap his head around it. That may be part of their problem.
My recommendation is to get a programmer to write an upload script for you because Adobe isn't going to help you.
Copy link to clipboard
Copied
When I publish the RoboHelp Tour on my site from RoboHelp I enter the path in the Server Directory field as
/grainge.org/foldername/foldername/foldername/rh_tour
RoboHelp adds the prefix ftp:// in the same way you used to have to prefix web addresses with http://
Note though that the URL string displays as ftp://grainge.org/foldername/foldername/foldername/rh_tour rather than having three forward slashes as you would get if you simply concatenated those strings. If I don't enter the slash in the Server Directory field, it doesn't work. Don't ask me to explain, I am telling you what works.
When I use Dreamweaver I only have to enter grainge.org/foldername/, no slash at the start.
MAUREEN I very much doubt you really were talking to the Head Engineer no matter what you were told. I have met him and suspect he knew about root directories before he started school.
See www.grainge.org for RoboHelp and Authoring tips
Copy link to clipboard
Copied
Ahh so I need to specify the entire ftp url in the directory box!
What's fustrating about this is the url alread appears to be correct when I set things up as I would in Dreamweaver or any number of FTP clients, the URL in the Publish section of the WebHelp layout porperty card looks correct:
ftp://dev.health.state.ny.us/hpnpages...
But publishes to
ftp://dev.health.state.ny.us/export/home/userid/hpnpages...
When I set things up as you suggest putting in the full path including a leading slash when specifying the directory the url on the property card looks wrong:
ftp://dev.health.state.ny.us/dev.h...
Yet publishes correctly to
ftp://dev.health.state.ny.us/hpnpages...
Well at least now I know how to get it to work now. Thank you sir!
@Maureen I think Adobe owes you a few beers, several pounds of chocolate, or both!
Copy link to clipboard
Copied
I'll take the beers.
Copy link to clipboard
Copied
I thought this was fixed and even had it working last time I posted.
Then today with absolutely no change to the publish server settings I am right back to publishing in the export/home/userID directory.
Sigh...
Copy link to clipboard
Copied
I talked to my unix experts and they came up with two work arounds:
As of today, both methods are working and files are publishing to the correct directories. I'll post another update if anything stops working.
Copy link to clipboard
Copied
That was our opinion as well. Who doesn't know what a root directory is? The Adobe tech who set up the conference call said he was the "head engineer" and he identified himself as such. That alone says something, if he wasn't really the "head engineer" ("Let me transfer you to my supervisor..." cupping hand over receiver, "Hey Ed, do me a favor and pretend to be a supervisor on Line 2.") At any rate, they couldn't help - didn't know how, couldn't figure it out after three months and some increasingly impatient followups from my programmer. Then they simply closed the case - so we came up with our own solution, which works fine.