You have to try and understand that Finder is not a web server. It will commonly just open files in new tabs or windows, as it is designed to do.
As @DaveFox says, you need to install MAMP on your computer if you want to simulate how a completed website will look and behave. Or publish your site to a real web server.
Any single web page makes calls to other files and software so it can be displayed as intended. Further, it may actually run php scripts also. In short, a web page is not something that can be run apart from a server which is also running php, perhaps database software, security software, etc etc etc.
So WIID (what it is doing) when running under Mac Finder is working exactly as it should. Your expectations are in error. By the way, I think I am one of the very few people left alive who find your 3 digit âwhat theâ phrase offensive. When I see that my mind still reads the full words.
I might not know what Iâm talking about, but my old RapidWeaver 4 sites behave as I described - no need to install MAMP. I mostly use RapidWeaver to make documentation for my apps or for work, and when I export a project from RapidWeaver then that folder works as expected: you open the index file in the default browser (either programmatically from my app or by double-clicking) to start and can follow all the links to their local pages.
That behaviour makes sense and is incredibly useful.
The changed behaviour in RW 8 makes no sense at all.
Or do you expect me to tell all users they need to install MAMP? What would you think of an app that requires you to install MAMP?
Itâs not running under Mac Finder, it is opening and running in the web browser. And the web browser knows how to display all the pages.
It makes perfect sense if you understand anything how modern websites work. Webpages are designed to be served by a web server. The server can perform a lot of work like resolving address, rendering PHP and more.
RapidWeaver 4 is over 12 years old. Hasnât been updated in more than 10 years. OS-X 10.5 leopard was the operating system.
Things have changed a lot with the Internet since then. Things like mobile smartphones, responsive design and PHP have become the norm.
Although you can use RapidWeaver for making documentation itâs not itâs primary use. It made to make websites using the latest technology.
If you are sure you arenât using any PHP then under advanced settings uncheck the tidy links option.
Do you not have a web server to which you can upload your RW files?
(s)ftp from your local machine to a server is built in. Itâs usually literally a single click⌠âPublishâ.
Your clients would then have the advantage of seeing how the sites which you create for them will work in situ.
Respectfully, it does seem a little unfair to criticize software for having introduced so many new features and having moved on so dramatically in 12 years - as Doug says - especially when there is an easy solution to making, in this case, RW 8 work just as you need it to. Good luck!
Iâm not a web designer but a Molecular Biologist. Years ago when iWeb disappeared I made a few simple websites for my motherâs B&B and relief project and our lab (nothing fancy required, kept it clean and simple) with RW 4, but then discovered that HTML files make for very good cross-platform help files that you can incorporate into your app. I even used it to make a local help system for my 86 year old father as he was beginning to always ask the same questions (âHow do I do that again âŚ?â).
People here seem to assume that everyone else here is a web designer (which is kind of weird because RapidWeaver started out as âMaking webpage creation simple for the rest of us - away from DreamWeaverâs complexity and priceâ), and that their users clients have fast flat-rate internet access.
Thatâs nice if it is the case but the real world is more complex - you might have intermittent and/or slow internet, a computer might not be allowed onto the network (eg some of our work computers that control specialist microscopes are not allowed on the network but need to run our own specialised software, including the help files), app users (on computers that are connected to the internet) stay on older versions of the software and need the help files for that particular version, internet traffic might have to be paid for so you better reduce it to what is essential (not everyone has flat rate internet), etc.
In short: local html files are essential.
I also know several cases of long-term âcustomersâ (customers in the sense that I make their websites for free - my mother is one of them) that use a free web address and webspace provided by their ISP as part of their original contract. Those original sites have no php, no control panels to change settings, only (s?)ftp access to upload the website and manage it - but they would have to pay for the move and a yearly fee for their internet presence as a web address and space are no longer included by their ISP (but as long as they donât agree to change the original contract they still have it).
Yup, works fine. To be honest most of the time I just need StyledText pages âŚ
Contacts page of course doesnât as it requires php but that I can easily work around with an email link in my usage scenarios.
I know a few - but Apple Help is atrocious (very slow) while HTML files in my apps are instant AND cross-platform (I write scientific apps for Mac/Windows/Linux). There are free help file systems but I find the good ones expensive and prone to fail after a system upgrade (which would require buying an update). The huge advantage of HTML files is that they are cross-platform and always work, and most of the time they give you more options than help systems (those can be rather rigid).
What I never understood is that âFolderâ and âFilenameâ are not Meta Data at all but part of the directory structure (file path). The fact that itâs in a âmeta Dataâ section is very misleading for new users. Especially those who want to define their own paths.