When RW is used to publish a site, does it place the folder “Resources” first in the URL site-path, then followed by other sub-folders? In other words, would our RW site-path be https://www.nameofsite.org/Resources/DOWNLOADS [or whatever]?
If that’s the case, I’m wondering how to fix it, because my ISP server isn’t going to change their protocol.
Even if hosting company doesn’t care about what sub-directories we use, wouldn’t all the existing links to our former site from other sites around the Internet no longer work because they would not have the /resources/ folder in their address?
Have you published a site with RW, and did it include /resources/ in the path?
That rule would take every file request from an old directory named downloads and redirect it to the new directory resources/downloads, and return the 301 return code.
Almost every website that’s ever been published with RW8 has a resource folder. So that’s a yes by tens of thousands of sites.
It’s only for resources not in the general URL folks use to find and browse a site with. It’s no different than your current structure of having /DOWNLOADS/ in the pathname. In fact, it could be considered better practice and less confusing than using mixed case paths.
Thanks for taking the time to explain the possible solutions again.
If I understand it, given that my host is using Apache web servers, somewhere there’s a line of code that can be placed redirect requests from anywhere on the Internet sent to the old address to the new address—the path with resources in it [^Downloads/(.*)$ /resources/downloads/$1 [R=301,NC,L].
What I don’t understand is where and how to place the code.
I assume that since all the old files on our host’s web server will be taken off-line, I have to install them in the RW resources folder and sub-folders for “downloads” and “media”. (Seemingly, the resources folder is contained within the RW app until the site is published, because that folder doesn’t exist on my HD, although it already has contents.) At this point I have no idea what RW does with “pages” which currently reside on our host’s site directly following the URL. In other words, the path I see on the server now is direct to Downloads, Media, Pages.
FWIW, GreenGeeks says "you can remove the old website files from cPanel and upload new website files and then the new website will work. I could probably manage to do that once the new RW site is in some published form (so the sub-folders are viewable), but would that deal with the issue of someone requesting one of our files or pages from an old link on another web site?
Inside of RapidWeaver’s publishing settings, you will see at the bottom of publishing settings a button marked edit htaccess file. It only shows up if you choose to publish to a host and not a folder.
That’s where you place the redirects, in Apache, the htaccess file will be read first and executed prior to displaying anything.
Now as I told you in your prior post, that’s the easy part. The time-consuming part is for you to map out every URL for the old site and determine what the new URLs would be. Not just for downloads and linked files but for every page.
A spreadsheet is usually the best approach for this. A column for the old URL and a column for the new. You can also add columns for comments etc, etc.
Rapidweaver deletes nothing, so when you are ready to switch to the new site you’ll need to delete the old stuff manually with the file manager in your host control panel or an FTP application like Transmit (paid) or Filezilla (free).
The reason I suggest a spreadsheet is there is a testing tool for redirects with htaccess files.
With the spreadsheet, you can paste your htaccess file into the tester and simply go through one at a time with every old URL and make sure it redirects to the expected new URL.
As I always mention when dealing with redirects it’s simply best practice to use 302’s (temporary) until you are absolutely sure everything is working correctly. Then and only then come back and change the 302’s to the 301’s (permanent) and then restart everything again. 301’s are what search engines want, but they are truly permanent and have no expiry date. They can and are often cached.
Talked for several minutes this afternoon with my hosting tech support, and I think my next steps are clear. They suggested setting up a sub-domain for testing—they’ll walk me through the process—to determine what other steps are necessary to avoid losing traffic from the path changes.
Right now I’m installing and renaming all the files to show “resources” in the path before the Media or Downloads folders and file names. RW sees them and now loads the files from those I’ve installed rather than from the hosting server.