I just thought I would share some information in case it might be useful for any other fellow RW users…
I was trying to upload a site direct to my clients’ host which is 123-Reg here in the UK and every time I try I got an error message saying… “Couldn’t upload to your FTP server: Access denied to remote resource”
So I then tried exporting the files into a folder and then manually uploaded them through Transmit and then I got an error in Transmit telling me that “Sorry, the maximum number of clients (3) for this user are already connected.” So I downloaded the trial and tried using Captain FTP and curiously it worked so I needed to figure out what the issue was with Transmit.
I then posted a support ticket with 123-Reg and they suggested going to the Transmit preferences and changing the number of files that transfer at a time from 5 down to 1 and this did indeed fix the problem! But this was still only the manual method of uploading of the files via Transmit, this didn’t help in uploading the files direct from RapidWeaver.
So I went in to the preferences for RW and changed the Maximum Concurrent Uploads down from 6 to 1 and this finally fixed the problem with direct uploading. I guess I will leave both sets of prefs set to the minimum of 1 in Transmit and RW and it will mean a slightly slower upload of files but if it’s more reliable then that overrides the need for speed.
A simple fix that I’m sure is covered elsewhere but I hope this helps other users experiencing issues with uploading to 123-Reg (and indeed maybe other hosts) from RapidWeaver.
Hey David,
Thanks for sharing this great tip! We included the ability to upload multiple files at a time for speedier uploads. However, some hosts don’t support this so we also included the ability to turn this off.
I was going to give you a “solution of the year award” after several weeks of frustration with this and having to resort to an external ftp program, but I regret to say that it did not work for me. I also use 123-reg hosing. Anyway, thanks for the suggestion and I hope it works for others.
Oh I’m sorry it’s not resolved this for you with your 123-Reg hosting. Prior to my solution the only way I could upload my site for my client was to publish the files into a local folder then manually drag them over on to the server using CaptainFTP as this has the maximum concurrent Uploads set to 1 by default whereas Transmit is set to 5. Is this the FTP program of your choice?
I am a new to both RapidWeaver (so far good experience ) and 123-REG hosting and have an identical issue to that described by PrintDevil, and the same “non fix” result as Bryan. From the logs It looks like the problem might be the refusal by the 123-REG FTP server to accept the Create “public_html” command, but I cannot figure who owns the problem RW or 123-REG! Any thoughts?
i’m having the same issue with direct uploading as the original poster.
Does not matter what site I have, it will not upload. Testing the connection is just fine. It connects and then when i hit publish, I get this nonsense.
OR I will get a cannot connect error.
Had my server tech check it out as I share a VPS with a friend who manages it for us. NOTHING is wrong on the server end. I can connect and stay connected all day with Filezilla but when I want to publish a site, it’s itchy through RW.
I’m having an issue with the site uploading the theme or having it show. It’s there in the files, but not showing. Clearing cache etc did not do the trick so I’m trying to see if there is an issue with the site this belongs to or not by trying to upload on any of the other sites I have but I just can’t upload at all now.
Been at this nonsense for an hour and any insight would be appreciated.
Without a bit more information it’s difficult to say what could be causing the problem.
I’m assuming that you’re using 123-reg and getting the same message as the original two year old post?
You said you you are able to connect with FileZilla, are you able to upload with FileZilla? Just connecting with an ftp client really doesn’t say much more than the RapidWeaver test connect. The ftp protocol doesn’t really “stay connected” other than when in use.
Here’s something’s you can try
Export your site locally to a folder on your Mac
Try to upload that folder using FileZilla
If that works and the changes to the site shows up, then you know your server and the settings in FileZilla are all working.
Many times an access denied message can be caused by a path error. This is especially true if you’re able to do a successful test connection.
Assuming the test above works then I would clear out the path in the RapidWeaver publishing settings, and choose the browse button. Then select the same directory that worked with FileZilla.
I can upload all over the place using filezilla.
I tried all the suggestions you used and I don’t want to take a chance and NOT put the slash at the beginning of the url because i’m testing something out with this rapidsearchpro stack by putting it in a sub folder before putting it on the client’s site.
so what I need to do is /testfolder instead of just the public_html (my server calls it ‘web’)
It was actually working just fine for awhile until I realized the css just wasn’t loading although the files were there.
I’ll give your suggestions a try in the morning and see what happens.
Not sure what the chance would be.
If you’ve been able to publish with FileZilla, what is the path you used on FileZilla?
I don’t use 123-reg but the documentation from there site shows that the Directory (folder) you would want to select would be
For Linux package:
public_html
If you’re using Windows package:
web/content
If you clear out the path and select browse button and choose one of those directories (depending on your plan) RapidWeaver will determine if you need the slash or not at the beginning. Once you’ve chosen the root directory, then just add the /testfolder to the end of the path name field.
If you’re still having issues, you could use FileZilla to complete your test just add the new /testfolder content with it.
You could also have a look at the123-reg knowledge base:
If that doesn’t help, then I think maybe some screenshots of your RapidWeaver and FileZilla publishing settings might help.
OK web/content is NOT a windows based hosting. It is OUR SERVER and my server manager set it up that way. it’s only his choice of wording.
I exported to a folder and uploaded using Filezilla and it still will NOT upload the CSS. I look and the files are there, but they are not rendering in the browser. Yes, I checked with other browsers. Same thing.
This ONLY Happens with RW6. I have RW5 and never had an issue.
OK I’m fiddling around and in the previews on RW6, I see this up at the top of the page. I have no clue what this means but that page7.php IS in there.
So if this error is the problem, where / what do I have to do or go to fix it? and what on earth would cause that?
the file itself does not have 95 lines. It only has 40 (stacks_page_page7.php)
Read the title of the two year old post you brought back to life
My first reply to your first post.
It’s difficult to help with publishing issues without knowing things like settings and host requirements. That’s probably why it would have been better to start with a fresh topic. But no matter it’s clear that you’re using your own host.
I’m not at the Mac right now but will have a look at the URL you posted shortly.
As for the error your having with preview, line 95 refers to the PHP source file that RapidWeaver generates to preview and publish. If you right click on preview and select “inspect element” you will probably find the line 95.
This would indicate that there is a problem (a PHP include is not found) on the page. As a general rule PHP errors don’t show up on browsers as the server traps them and post them to a log. This could be causing the issue with the CSS not working.
Still doesn’t address your problem with publishing with RapidWeaver.
Should be back at the office a bit later and will have a look if you don’t get things worked out by then.
On the link, it is showing a bunch of ‘mixed content’ errors as the URL is an HTTPS url, but some of the files it is requesting are coming from http sources. I see some CSS files in that category, so that might explain why the styles aren’t getting loaded.
I’m not sure if this is a theme edit that needs to happen (it looks like you’re using ‘Mobo’) or something in your project settings
I can understand your confusion about the hosting. My apologies as I should have mentioned the problem was only in regard to the error happening. I don’t think this is a hosting issue then but an RW 6 issue. This is not the first time this has happened.
UGH. This looks like a theme issue then? I JUST bought that theme last August specifically so this stupid wiki is mobile friendly for way too many people who refuse to use anything but their phones for this site.
What would break a theme in such a way? I’ve had no issue on this theme until this week too. I’m so lost here! Seems like two issues going on at the same time.
I did try a different theme just to see if it loads the css but it does not matter. I have a feeling something is corrupted in RW6 and I should fully uninstall it and reinstall the program.
I could be wrong but it’s partly a browser ‘issue’ with browsers now being more stringent on the ‘mixed content’ stuff and the move towards having everything on the web coming from secure sources. It used to be a warning, I think, and now it blocks the content altogether.
As for where the error needs to get corrected: it could be a theme update that is needed; or it could be that your project file needs to be updated to have https in the General Settings, then republish all files.
Edit: I would guess, by the way, that it is probably the latter (that it is a settings change on your end). On occasion, I have come across stacks/themes may have resources that have non-secure resources (such as fonts or icons) that require the developer to issue an update.
But, when I look at the page source, it looks like most of your links are http but your site is set up to force https in the browser when someone vists (hence the mixed content warnings).
Thank you! That should be an easy fix indeed. Not sure if that will fix the uploading issue because this has been a problem with “timing out” and denial of access long before we switched to https
