This project has been going almost as long as Rapidweaver - so it has grown considerably
Poking around in the resources folder, I see that many the resources have lost their icons and become question marks. Not sure how I didn’t find this earlier. A couple of weeks ago (2 or 3 betas ago) all the resource folders lost their names - so I suspect the links were broken at the same time.
It seemed to me that ‘re-linking’ these files would fix the issue - but it appears to make no difference. Linked resources still link only to the folder and not to the file
The bottom line even with a huge project file the resource function should work.
jol (@jbob) I haven’t been able to get the same failure you have, but I still see a bug in the resources.
I took a bit of a break from the beta version so I just downloaded the version from the link above (Version 8.3 (20786b)).
using the existing production version of RW
I was trying to recreate the problem so I started with a brand new project.
@jbob I think they’ve been taking this seriously all along. If they weren’t then you hoping for a solution next week would be reasonable only if they suddenly stayed off the weed.
But I think the situation is different: they have taken the situations seriously. It’s just a very difficult problem to solve.
A solution may come next week or the week after or get broken again a month later. If you like living with that ambiguity and chaos then keep doing what you’re doing.
On the other hand there are at least 2 full-proof alternatives. One is to get a good FTP app (e.g. Transmit) and upload the files yourself to a relevant folder. Apps like Transmit have a copy URL function so it’s fairly painless to do a swap: even with 50+ resources.
But my guess is you may want to invest in a great stack named Repository by @instacks. I write this because it’s more user-friendly for novices. It’s not a full-blown FTP app like Transmit, but it’s incredibly useful in all sorts of ways for websites. You can find more info here:
The cost for this solution is $39. Reasonable given all it does. And of course you may find all sorts of other uses for it.
This stack makes it super easy to upload files to your website, copy a URL, and then put those URLs wherever needed. Works perfectly. No snafus. It’s also great when you have lots of “stuff” as you can divide and conquer by:
putting different “stuff” into different folders (e.g. PDFs, images, audio, and so on)
you can sort within a folder by name, date uploaded, size and more. Easy to find a needle in a haystack. It’s something RW resources won’t be able to do for a long long time. It doesn’t matter if you have 5 items, but with 50 or 100 not being able to sort and find easily is very frustrating.
I use this stack for course websites: it allows students to upload and download various materials. Very nice in a lot of ways.
On the other hand if you like that sound of your head banging against a wall … alcohol is cheaper, and Repository or Transmit are more effective.
As for 75 Mb in size. If you have 100 pages at your site that’s pretty reasonable. If you have 1-2 pages then that size is ginormous. In general you’ll get quicker performance if you keep your RW project file lean and mean: another reason to FTP or use Repository.
BTW, if some of your resource links work fine then there’s no need to change over everything right away. Try changing 1 to 5 links a day. That way you’ll get more practice with Repository/Transmit, experience less frustration, and you can fix the most pressing links first. (I realize you may see everything as important, but surely some links are more important than others.)
ADDENDUM: Some stacks require drag and drop or the use of resources. That’s true for me as well. In those cases I obviously do drag/drop or use resources. But the number of times I need to do that on a website is relatively rare. Still better to get as much off the project file as possible even if some files need to remain due to the demands of a specific stack.
The solution you offer is not a solution at all but a work around.
The intent of this thread is not “design Philosophy“ or “other ways” of getting things done but about reporting bugs folks found beta testing.
If you think that @jbob is in error about having found a bug then by all means point it out. I would bet that most RapidWeaver users don’t “warehouse” any resources and really shouldn’t have to use separate ftp clients and set links manually. They all use Macs because it makes things easy like drag and drop.
With RW8 resources wether you like them or not are ingrained into the app. Social media images, banners and pretty much anything dragged into a page is stored in the resources folder. And the new stacks 4 “site images” (the default for RW8) will use the built in resources folder.
So if there’s any possible problem with resources in a beta release of RapidWeaver I want it addressed long before it makes it to the general release.
Thanks for the feedback guys, it’s really appreciated.
@teefers those steps are perfect - I’ve been able to reproduce this bug and will get it fixed up.
@jbob Glad you got your links working again, it’s quite possible that a previous build caused the problem. I’ve not been able to reproduce the problem you describe using the latest build.
RapidWeaver’s resources system has been debated countless times over the years. There’s no real limits as such - it’s more a case of finding a workflow that works for you. Some of the largest projects I’ve seen are over 800MB.
I’d like to remind everyone that a Final Candidate is a build that will become the production version if no show-stopping bugs are found. It is still BETA software and as such could contain bugs that result in data loss. Please remember to backup your projects before opening them in BETA software. RapidWeaver is a very complex app and we really do try our best to minimise the disruption.