I have a RW7 file that won’t open (when I try to open it, the source list appears, but the home page is bank, and the beachball spins for eternity, forcing a “Force Quit”). I opened a ticket with RapidWeaver support a few days ago but I can’t get them to respond. Has anyone out there ever been able to diagnose why I file won’t open (or fix it so it can open again)?
Can you try sending your message in to support again? I think that they were in the middle of changing Helpdesk platforms earlier this week, so perhaps your message got caught up in that.
I’ve sent them a message to double check it, but to save time you’re welcome to try and re-send it. If you could attach your project, or a link to where we can download it, we’ll be able to figure out what’s going on here.
Thanks for the info Simon…the helpdesk platform they’ve moved to (I’m assuming, since another thread from a couple of days ago pointed a customer to it) is ZenDesk, and the issue has been created and currently sits as an OPEN issue in that system. As soon as they log in they will see it and all other open issues, so I don’t see a point in creating a new issue…if RealMac wants to service their customers they have the means. I use ZenDesk myself, and it’s great. I also respond to EVERY support ticket within 24 hours (usually within 4).
Did you try duplicating the file on the desktop and opening the copy? Sometimes that works.
Thanks Lisa…yes tried that
Do you have a backup file uploaded to your host page - ie the automatic backup file that you might be able to download and try? Just a thought.
I once had this problem (quite a while ago) when RW couldn’t locate the local copy of a resource file. The file was on an external drive and since then I’ve always made sure that the resource files remain on the host computer’s HDD. Presumably the problem could also occur if the local file has been relocated manually and RW has lost track of it. Just a thought!
Although it may not help you solve your problem, a good place to start is checking if it’s one of the installed addons.
If you hold down the Option key when starting up RapidWeaver it will show a window that allows you to (just for this launch) disable your themes and plugins.
If the file opens up fine with all of those removed – then the problem is at least related to one of those things. If that does not fix the problem – then you should probably continue on the path of RapidWeaver support.
If that does solve your problem, read on!
You can do a bit of detective work to find out which add-on and then send your support message direct to that developer (there’s a fair chance that will be me!).
Start by re-enabling your themes. They’re far less likely to be the problem, so we might as well get them turned back on. Just Quit and Re-Launch RapidWeaver – again with the Option Key held down. Leave themes enabled, but disable the Plugins this time.
If that worked (and the file still refuses to open with them enabled) then the problem is on one of the plugin pages.
Open up your addons folder: Cmd-Opt-7
- Remove ALL your plugins. (You can just drag them to the desktop for now).
- Add one plugin back to the addons folder. Choose one that you’re actually using in this file.
- Quit and Re-Launch RapidWeaver and try to open your file. If the file opens then you know that plugins is OK.
Repeat the process until all the plugins are added back. Don’t bother with plugins that aren’t being used in this file. Eventually you’ll bump into one that brings the failure back. You can’t know for certain that plugin is the real culprit – but you at least know it’s involved.
With this info – you could potentially continue work on other pages in your site that don’t involve that plugin (by uninstalling it again). Or even deleting that page from the file (not usually an option – but maybe worth mentioning).
And, of course, you can report the problem to the right developer (in case that’s me, YourHead/Stacks send to http://yourhead.com/support ).
Make sure to include the file, any add-ons they’ll need to open it. And any crash-reports or error messages you have. Plus as much info about your working enviornment as you can find: macOS version, RapidWeaver version, plugin versions, and anything else you think might make your system interesting.
Good luck with the triage,
Thanks for the idea, good tip…the file is over 200MB, so I definitely don’t back it up on the web server each time I publish, but again thanks for the tip.
Thanks Robert–that’s a really good tip. After spending about 8 hours I have actually found a workaround to the issue…I’m not sure yet whether the bug is in Stacks or RW but now I’m just curious to see how long it will take RealMac to respond to my support ticket (5 days so far) and whether they will attempt to diagnose it or just deny responsibility. I won’t say at this point if your idea helped me find my workaround, just that it is a really good idea and hopefully it will help others out who have this same issue (because I know RealMac sure won’t!)
First, your RW project file is WAY WAY too big. It tells me you are putting “stuff” into it that almost guarantees problems in the long run. The most likely source of such a big project file is either dragging images from your Mac, or audio from your Mac, or video from you Mac.
Put simply, while RW claims it can handle importing media files just fine it’s not an optimal way to go. There are too many things that can go wrong. Perhaps most common is the issue that @Kilburnlad described. But it’s not the only possible problem.
So what’s the long term solution? Warehouse your media so you link to it directly at your web server. Essentially this means first putting the media in a folder at your hosting site by FTP. Then getting a link to it. Then using that link within RW. You’ll probably end up with a RW file of about 12 Mb instead of 255! And you won’t run into the problem Robert describes.
At 200+ Mb you probably many images in that file, or a smaller number of images that are big in size. If you have big images then compress and optimize them first. Then warehouse. If you have a large number of images then it may take awhile to move them all over to a warehousing approach. But you can do this in bits, no need to do all at once.
Check out this handy guide by Will Woodgate:
Hi Mathew, thanks for the feedback. I won’t disagree that my file size is too large to do things like back up to the server while publishing. Is it a big website? Yes, (it’s here–about 120 pages). But am I using the software in a way that it was not intended? Definitely not. Have I embedded anywhere close to 200MB in images? No, more like 10MB. All my images are optimized (no audio or video directly embedded) and about a third are already warehoused. Why not warehouse all of them? Because RW doesn’t know how to properly deal with warehoused images (when warehoused, I can’t see the image while designing or editing the page–that’s generally a dealbreaker for me. Again, I’ve nowhere close to 200MB of images, so RW files ballooning to enormous sizes for no good reason I see as a design flaw in the software and shouldn’t force me to do things in ways that compromise my efficiency (like warehousing images does) in order to avoid bugs in the software (like what I’m experiencing).
Incidentally, I already thought to try warehousing all images (I did about 80% of the images, which did take a long time) but that did not resolve my issue.
Eric - You absolutely can see your warehoused images when designing and editing. You see them instantly as soon as you enter the link in all of the many stacks the support image warehousing.
For some unknown reason RM won’t add native support for warehoused images but don’t let that put you off.
Isaiah…thank you so much. This is fantastic, I wish I had this years ago. I’d love to have this pinned at the top of the forum to help others in the future. This is exactly the sort of info that I would expect RealMac to provide me when I contact them for support (as opposed to, you know, completely ignoring the request for support), and just further demonstrates why you should own RapidWeaver (or perhaps create your own client that works with Stacks). Essentially, as everyone knows, RapidWeaver is NOTHING without stacks. And the company behind that product is a bunch of incompetent boobs. But I digress. You’re awesome, and thanks again.
Hey Gary, I’ve love to know how you accomplish that, as that has NEVER been my experience. For example:
Eric: I can only ditto what Gary wrote. It looks like your links are not direct links (i.e. starting with http or https) and that’s likely the problem.
On the other hand I have no idea what stack you’re using so maybe it has something to do with how that specific stack works.
Don’t use Resources for images. It is a half arsed part baked solution that puts people off and requires that RW publishes the Resources before it works.
Instead, add you images directly to a folder on your server called something like warehouse using an FTP app. Or in your case just move everything uploaded from RW in resources into a folder called warehouse (or whatever you want to call it).
Then use http://yoururl.com/warehouse/image1.jpg for an image called image1.jpg and you will see it instantly.
Also because you are using Resources for your images, they are all stored in the project file and you defeat one of the big benefits of warehousing images when using RW. Remove them from Resources and you file will decrease in size and loading will speed up.
I usually back mine up once a week - just in case…
I don’t actually add my images as RW resources, the folder name “/resources” is just something I still use, a leftover from my early days of learning RW (about 7 years ago). But I still use the %resource()% macro–an absolute reference doesn’t work for me because I may publish on to the production domain or to a staging domain while I’m testing, and sometimes I’ll upgrade a site to HTTPS…I don’t want to have to change every absolute URL each time. True I could use “/resources/image.jpg” but some stacks don’t like this convention specified for an image link.
Hi Eric, I’m far from being an expert, but vaguely remember that this problem was discussed in the old forum.
If my memory does not fail me, the problem was solved by right clicking on the project, -> Show Package Contents-> Pages and exploring each folder for a corrupt file. In that occasion it was an image …
I understand that in your case there are a large number of pages, but I think it would be worth a try