Removing Resources has no impact on project file size


(John Blanchard) #1

My project file is 170MB and I thought I should take the plunge and ‘warehouse’ some files which I had as resources. These totalled over 30MB. I then deleted these files from resources but there has been no effect on my project file size ie it is still 170MB.

Any thoughts (I have tried the ‘show package contents’ route but I am none the wiser). Grateful for any thoughts on this matter.


(Paul Dennison) #2

If I remember correctly contents added to the Resources folder by default aren’t copied in to your project file, they reference where to find them on your Mac so they can be published.

If you’re looking to warehouse images to shrink your project file you need to look in to images that are dragged and dropped into image stacks. They are better targets for warehousing.


(Mathew Mitchell) #3

Check your settings under Advanced.


(Mathew Mitchell) #4

I think you posted before about the same issue. You never told us how many pages are in your project. If you have 1,000 pages then your project size is probably not a surprise. If you have 10 pages then something is amiss!


(Doug Bennett) #5

Might be helpful if you told us a little more information.

  • what exact version of RapidWeaver are you using? The way resources are handled has changed.
  • what kind of page are the images on? Assuming you are using stacks if so what version?
  • how did you place the images on the page to begin with?
    • Did you drag and drop to the directly to the page from resources?
    • Did you drag the image to an image stacks sidebar drop zone?
    • Did you use a resource macro to place the image on the page?

(John Blanchard) #6

Hi Doug, thank you for your interest in this.
I am using RW 8.2.1
I spent a bit of time on this at the weekend and have realised the ‘Resources’ I am talking about here are not actually image files but PDFs (they are scans of old newspapers).
These PDFs were loaded to Resources using normal RW functionality
More recently I loaded them to a ‘warehouse area’ and removed them from Resources but there was no reduction in the size of my project file.
Sorry for the bum steer in saying these were image files.


(John Blanchard) #7

Hey Paul, thank you for your interest in this.

These files on reflection are actually PDFs which I added using regular RW functionality to the project resources ie no drag & drop.

Are you saying they were never part of my project file anyway and therefore I should not be surprised that removing them from Resources does not result in a reduction in size of my project file?


(John Blanchard) #8

Hi Matthew, thank you for your interest in this. Over the weekend I realised that these aren’t actually images that I have warehoused but PDFs which I loaded into my project resources via normal TW functionality. From other responses on this topic I am sensing that these were never actually part of my project file and this explains that when I removed them from resources there was no apparent reduction in my project file size.

I have 82 pages in my site.

In Advanced Settings I have the ‘Leave in place’ option checked


(Mathew Mitchell) #9

Okay, the “leave in place” option explains why there was no reduction in project file size. Makes complete sense.

With 82 pages a project file size of 170 Mb does seem a bit large.

My guess is that you used drag-and-drop to include images (JPGs, PNGs). Those are the things you’d want to try warehousing.


(Doug Bennett) #10

My next question is why are you concerned with the project file size?

I did a bunch of “stress” testing with RapidWeaver 8 while beta testing stacks 4. Stacks 4 introduced the “site image” stack that’s only available with RW8 as it uses the revamped RapidWeaver resources.

I intentionally Made projects where the files sizes got over a gigabyte each for a single page site using the new site image stack and having the Site Resources option set at Copy into Document.

I then made exact copies of the projects and changed them over to use “warehouse” images instead.

Here’s what I found, the projects that used the revitalize RW8 resources open much faster than the warehoused projects. They also preview (or simulator) almost instantaneously.

What really was impressive to me was how much more smoothly the editing is when using the new site image stack (uses the internal RW8 resources), in comparison to the same warehoused page that gets more and more “jerky” and “bouncy” as the page get larger.

So if the reason you’re concerned about your project file size is performance of RW8, it’s not being caused by using the built-in resources in RW8. I didn’t run a test yet comparing the older stacks image stack (the default for RW7 and/or stacks 3) or a test with an image stack that has a well in the inspector.

If you think about it makes sense, images loading from your local hard drive will be much faster than loading from over the internet.

Should you be using the Revamped resources in RW8?

  • If RW performance is a concern then yes, the built-in resources seem to effect RapidWeavers edit and preview in a very positive way.
  • If local disk space is an issue than you might want to shy away from the built-in resources. The only way I would recommend using built-in resources is to have the Site Resources option set to Copy into the document. Having it set to Leave in plce is just asking for trouble. Sometime in the future, you’re going to do some housekeeping, move files delete old files rename stuff. If any of the resources in any rapidweaver project are affected by that housekeeping you’ll break your project.
  • if Managing the publishing of individual or groups of resources is a concern then warehousing might be a better option. Although RW seems to do a good job keeping track of what needs to be published in resources, there’s no way currently to re-publish individual, folders or even all resources. If for whatever reason any resources need to republished the only option is to publish all files.

How to manage images with RW?
(John Blanchard) #11

Hi Doug, I appreciate your reply and feel I have learned a few things from the responses to my original question. I am a ‘hobbyist’ who needed to build a website to support a local history interest. I’m very impressed with RapidWeaver and have no concerns about performance or disk space. I just sensed from some other posts that ‘warehousing’ was the way to go and that at some point my project file size would become an issue. I am now much more comfortable and feel I have a greater understanding of the ins and outs. Again thank you for your responses. JB


(Clay Luther) #12

This must be a bug.

I recently started an entirely new project. After setting up my initial page and thinking I was going to be leveraging a lot of FontAwesome Pro in this project, I copied the entire latest FA Pro folder structure into my Resources (/resources/fa). I immediately regretted this since FAPro is HUGE and Rapidweaver 8 simply choked and became non-performant trying to manage/save/upload 7K+ resource files (about 60mb) (I had Copy Into set on resource management).

Backing up a step, I just uploaded the FA Pro install directly to my server and deleted the resources from my RW project.

However, the project remains bloated (over 80mb) and non-performant. Saves takes minutes (and RW wants to save every time I publish a test). The project itself is currently trivial (2 or 3 pages with no content to speak of, they are just scaffolding).

I’ve been trying to figure out a way to “compress” the project (I could have sworn there was an option in RW to do this, but, alas, not).

Fortunately, I am not too far along and the project is just for funsies anyway. It’s easy enough for me to just make an entirely new project and start over, a bit warier and wiser now.

However, I am positive this is a bug, or at least an unexpected behavior. Using DaisyDisk to inspect the project, I can see the several FontAwesome Pro resources (SVGs, CSSs, javascript) left behind after the resource delete (even though they no longer appear in the project resources window). Literally, thousands of undeleted “dead” resources left in the project.