# RW Resources folder in site-path when publishing? **URL:** \ **Category:** RapidWeaver Classic\ **Created:** [December 1, 2021, 9:30pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600 "2021-12-01T21:30:03Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Moshe](https://avatars.discourse-cdn.com/v4/letter/m/b9e5f3/32.png) [@Moshe](https://forums.realmacsoftware.com/u/Moshe)\ **Post date:** [December 1, 2021, 9:30pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/1 "2021-12-01T21:30:03Z")
My existing web site and ISP server follow the site-path convention of [https://www.nameofsite.org/names-of-folders](https://www.nameofsite.org/names-of-folders) [such as DOWNLOADS and MEDIA], which then contain the working files. 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](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. ---
**Author:** ![teefers](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/teefers/32/8173_2.png) [@teefers](https://forums.realmacsoftware.com/u/teefers)\ **Post date:** [December 1, 2021, 10:36pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/2 "2021-12-01T22:36:26Z")
Not sure if I understand what the problem you are describing might be. Your hosting company (not your ISPas it’s your Internet Service Provider) shouldn’t care what subdirectories you want to use. `https://example.com/resources/downloads/` Would-be a subdirectory, your hosting company shouldn’t care how many subdirectories you have. It’s also best practice to use only lowercase letters, numbers, and `-` or `_` as separator’s in the the names. No spaces, uppercase letters or any other special characters. ---
**Author:** ![Moshe](https://avatars.discourse-cdn.com/v4/letter/m/b9e5f3/32.png) [@Moshe](https://forums.realmacsoftware.com/u/Moshe)\ **Post date:** [December 1, 2021, 11:09pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/3 "2021-12-01T23:09:54Z")
Thanks for the reply. Right you are—I meant hosting company. 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? ---
**Author:** ![teefers](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/teefers/32/8173_2.png) [@teefers](https://forums.realmacsoftware.com/u/teefers)\ **Post date:** [December 2, 2021, 1:14pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/4 "2021-12-02T13:14:15Z")
As I told you in another post > [@Nubee question about replacing an old site](http://forums.realmacsoftware.com/t/nubee-question-about-replacing-an-old-site/41491/3): > > If you are using Apache for your webserver, RapidWeaver has a built-in editor in the publishing settings for something called the htaccess file. In the Apache htaccess file, you can use something called a redirect. So you can forward any requests for the old URLs to the new URLs. You should put together a spreadsheet “mapping” all the old URLs to what will be the new URLs (including the download links) Then simply create the htaccess rules it’s very simple to do a redirect from an old URL (link) to a new URL address. You can even redirect to an entirely different domain hosted at a different company in another country on the other side of the world. Most redirects are a single line. ```auto Redirect 302 /DOWNLOADS/my-file.pdf /resources/downloads/my-file.pdf ``` Once you have tested the redirects you’re implementing and are sure they work simply change the 302 (temporary) to 301 (permanent). You can even get more creative and use RewriteRule that would redirect all files with the same file name, from an old directory name to a new directory name, with a single RewriteRule. ```auto RewriteRule ^DOWNLOADS/(.*)$ /resources/downloads/$1 [R=301,NC,L] ``` 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. > [@Moshe](#): > > Have you published a site with RW, and did it include /resources/ in the path? 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. ---
**Author:** ![Moshe](https://avatars.discourse-cdn.com/v4/letter/m/b9e5f3/32.png) [@Moshe](https://forums.realmacsoftware.com/u/Moshe)\ **Post date:** [December 2, 2021, 4:37pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/5 "2021-12-02T16:37:56Z")
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? ---
**Author:** ![teefers](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/teefers/32/8173_2.png) [@teefers](https://forums.realmacsoftware.com/u/teefers)\ **Post date:** [December 2, 2021, 7:39pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/6 "2021-12-02T19:39:58Z")
Okay, 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. > **[htaccess tester ♥ madewithlove](https://htaccess.madewithlove.com/)** > > Easily test your htaccess rewrite rules 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. ---
**Author:** ![Moshe](https://avatars.discourse-cdn.com/v4/letter/m/b9e5f3/32.png) [@Moshe](https://forums.realmacsoftware.com/u/Moshe)\ **Post date:** [December 2, 2021, 7:59pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/7 "2021-12-02T19:59:24Z")
Still feels overwhelming, but starting to get it. Thanks for the added explanation. ---
**Author:** ![teefers](https://dub1.discourse-cdn.com/flex005/user_avatar/forums.realmacsoftware.com/teefers/32/8173_2.png) [@teefers](https://forums.realmacsoftware.com/u/teefers)\ **Post date:** [December 2, 2021, 10:07pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/8 "2021-12-02T22:07:26Z")
It can be daunting at first, but it’s really not difficult once you’ve done a few. If you need help with this just post here and someone who understands this stuff will help you out. ---
**Author:** ![Moshe](https://avatars.discourse-cdn.com/v4/letter/m/b9e5f3/32.png) [@Moshe](https://forums.realmacsoftware.com/u/Moshe)\ **Post date:** [December 2, 2021, 10:49pm UTC](https://forums.realmacsoftware.com/t/rw-resources-folder-in-site-path-when-publishing/41600/9 "2021-12-02T22:49:41Z")
Appreciate the encouragement. 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.