All images are exported as PNG?

I just realized that all Images (I am using only Foundry Image Stacks) are exported as PNG, even the JPG. Is this an Issue with Foundry, Stacks or Rapid Weaver?

Any Ideas to solve this?

(All images are located inside project in the ressources window, they are even places in the export (/ressources) as the original format, so it looks like some “optimizing” changes everything to PNG?

Another thing: as it looks like, all images from partials are exported everytime the partial is used (I have a CTA as a partial with a modal for the download buttons). Is this the expected behavior?

(Update: when I import the images via drag & drop from the finder - not the ressources -, the images are exported as JPG and PNG but the JPG is used.)

I also realized that RW setting “scale down to xxx pixels” is not applied. I assume I must do something fundamentally wrong.

Foundry has no control of how images are saved. That is controlled by Stacks. I just did a small test with a simple project file and the used JPG was exported just as it should be as a JPG and not a PNG. My suggestion would be to contact YourHead Software and provide them with your project file and detail your problem for them.

That feature of RW is only applied to the page types that come as a part of RW I believe. You’d need to talk to Realmac Software about that.

Thanks, I’ll pass over my questions then :slight_smile:
Have to start somewhere and the only difference between the other (older) projects was Foundry (but also the Stacks 4 update)

Understandable. Hopefully @Isaiah will be able to help you out.

It’s tough for me to say 100% why these things are happening without a bit more info about the project and which stacks are being used, and what project settings are configured. But I can probably make some educated guesses…


The Quick Answer

I’ll guess that you’re using the Foundry image stack. If so, you might try using the built-in Site Image stack when you can. Although it will not have all Foundry functionality, it does have very efficient publishing.

Much Longer Explanation and More Suggestions


Since you went into a lot of detail (thanks – it really makes answering easier :smiley:), I’ll give you the “why” behind this behavior.

I’m also giving this long answer so that @elixirgraphics has a post that he can direct other users to when they have similar questions.

The best way to use RapidWeaver Resources

The publish-once-for-everything behavior that you’d like is in the Site Image stack. This is the default in Stacks 4 in RapidWeaver 8. Just drag an image from the Finder into Stacks…

  • A Site Image is created
  • The image is automatically added to the RW Resources window
  • If you drag the image in again it will just link to the existing resource
  • It will be publish once, in the /resources folder, and as-is without file-type changes
  • All advanced compression and meta-data will be maintained

The only downside is Site Images can’t be modified (scale/optimize/crop/etc). You need to do those modifications in another app before importing. However many users are doing advanced compression with tools like Squash, so as-is exporting has quickly become the best practice.

What if you use some other type of image?

There are three main types of images: the Site Image stack, the (old) Image stack, and Sidebar Images. I mentioned Site Images above, let’s talk about the other two: the built-in (old) Image stack, and Sidebar Images.
These two types are closely related. Both have the same publishing behavior, the only difference is the user interface. Image stacks are dropped directly into the layout and can be edited in-place with a double-click – Sidebar Images are dropped into a small image well in the sidebar along with other stack properties, they can’t be edited at all.

Image Stacks

This was the default image type prior to Stacks 4, and the only image type prior to Stacks 3, and is still the default in RW7. Image stacks allow the user to double-click and edit: scaling, cropping, rotation, file name, alt text, etc. Their default behavior is very conservative so that non-technical users get reasonable output with zero setup, but allow more technical users to edit and tweak their settings.
Since the Image stack is available in both RW7 and RW8, it must use the older RW7 mechanism for publishing: once per page, no exceptions. Prior to RW8 there wasn’t any other way to do things.

For a number of reasons, in Stacks v4.1 we may drop RW7 support (or at least limit it). This has allowed us to change the publishing behavior. In the Stacks v4.1 beta (being tested right now!), ALL IMAGES inside of partials will FINALLY get published ONLY ONCE for the WHOLE site. :tada: Yeah!

Sidebar Images

My guess is that you’re using Foundry. Foundry uses the Sidebar Images. These let users drag-and-drop images right into the sidebar with other settings. Sidebar images are very easy to use and take up very little space in the UI, which is nice – but this minimalism comes with a cost: no settings, no controls. Sidebar Images get default publishing behavior: (scaled to reasonable size, published to each page, PNG format, etc.).


I want to issue a bit of a mia-culpa – this strange limited behavior is my fault – the limitations to the Sidebar Image were completely intentional – I made them like this on purpose. What on earth was I thinking??? :thinking:

I didn’t think sidebar images would be used as a default image type for large images in the layout. I imagined they would be used for small images like bullets and drop-caps – the sorts of images that most people really don’t care enough to fuss with their details – reasonable publishing with minimum user effort. The limitations of Sidebar Images are the main feature for that imagined use-case.

The way I envision the API will be used and the way it actually gets used are totally different. :upside_down_face:

This is just the nature of the business. Sometimes small details can change things in unexpected ways. As soon as I added sidebar images most stack developers gravitated to them immediately – using them as the default image type for everything.
The reason is simple: they have one “tiny” benefit (which is actually a huge benefit that I didn’t notice when I added it) – they give complete control over the HTML – so developers can avoid any extra superfluous wrappers and craft the exact <img> tag that they need.
Unfortunately this situation painted me into a corner – the sidebar is very space constrained – adding extra options for editing or resource picking just doesn’t fit. :scream:

Sidebar Image Evolution (soon)

Sidebar images are evolving. A little at first, then a lot later on.

In the Stacks v4.1 beta Sidebar Images also get the publish-once behavior when inside of partials. But this tiny step forward is not nearly enough – they still need more features to reach parity with Site Images and/or Image stacks.

Moving Ahead (not so soon)

The next big change will add Site Image behavior to sidebar images. However this requires more from the RW API. RapidWeaver 9 (not yet public, so I can’t say too much) has a new and totally different resources API. This is great because it will allow us to add a lot more Resource compatibility everywhere, but also not-so-good because it requires a total rewrite of many parts of Stacks. It will be many months before we get Stacks working with this new API.

Stacks v4.1 – Beta Testing

I’ve mentioned the Stacks v4.1 beta a few times. If you’re reading this in fall 2020, then you can help us test the beta and see these changes in action by joining the Slack channel and downloading the beta. If you’re reading this later on, then there are probably other betas that need testing too. Please come join the Slack channel, say Hi, don’t be shy.
I always post links to the beta in the main chat channel, with details on how to install and how to report bugs.

If you stuck with me this far, thanks for reading. :smiley: And happy Stacking!



Thanks for your phantastic summary, my developer heart melted! :heart:

Yes, you’re right. I am using the Foundry Image Stack. The whole project Foundry only except the Agent Stack by @joeworkman.

I never used Sidebar images intentionally (I think I even deactivated the tab). I placed the images from the Finder into the Ressource window (which made them to sidebar images?), organized them in folders and placed them into the drop targets of the Foundry image stack

For me a natural behavior - I wasn’t aware that images are treated so many different ways, I was thinking of sort of a image pipeline provided by RapidWeaver and used by all plugins / stacks automatically (except warehouse images, of course)

So one last thing:

  • I downscaled all images to the final size (for mobile and desktop) and
  • removed all images from the Foundry image stacks (but kept them, for reasons) and
  • placed them again, but this time via the Finder (not the Ressource window)

Now the behavior has changed: the PNGs are still getting generated, but also JPGs with the same name!

Lucky me, these JPGs are used by the img tag, so I am no longer delivering huge PNGs, which was my original problem.

Technically I am fine now, except that I am publishing an huge overhead which increases publishing time a bit, but the final project delivered to the visitor is okay - Google Lighthouse is happy :slight_smile:

I believe when Isaiah refers to sidebar images, he’s referring to images dropped into image wells (drop targets) in the stack’s settings. He’s not referring to the sidebar feature of RW.

You definitely seem advanced enough to use remote images. A lot of us create our own resource_files folder on the server with an FTP client and use an FTP client to manage the images (and other resources like videos) outside of RW. You can use the Remote Image feature of Foundry stacks to then use those images in your site.

The benefits of this approach are that it keeps your project file much smaller, as the image files are not copied into the project file (RW default). The images never have to be published through RW, so that makes publishing changes quicker in the event you need to republish al files in it. The images work like the new “site images” do in Stacks, so that if they are used in multiple pages, they are cached by web browsers and do not get re-downloaded. You’re also assured that all the work you’ve down to optimize the images is maintained.

Right, it’s my day job :smiley:

(The main reason I use RW is for smaller (plain HTML) projects and mockups, I want to put things together without spending to much time and effort)

1 Like

There are only a few users who are aware of these things. They are mostly “implementation details” hidden from users. But a few users like to dig down and see how the content is actually published. Since only a handful of people dig this deeply I try to take the time to explain when people ask. :smiley:

Oh how I wish that existed. :relieved:

I’ve lobbied for years that RW take over publishing content global to the project – not only images, but color-schemes, icons, Javascript libraries, etc. Or provide an API that made it easier for Stacks.

RW9 is still private, but signs are that the next resource-window API will make a significant step forward. Not as much as I’d like, but it’s a start. :+1:

But the current state of affairs is that RW8 makes global content difficult and in RW7 it was nearly impossible. But Stacks has been delivering the impossible within the bounds of RapidWeaver for 12 years now… LOL :yum:

I have no good guesses as to why this is happening. I just don’t have enough detailed information about the project to say why. If you’re interested in digging into it, then with more details, of course, I can provide more info – and would be happy to do it. :smiley:

That was my understanding of RW, I think it was the case in the early days, before Stacks took over the majority of use cases (I remember the days you released “Blocks” and the PlusKit - Finally, some organzied work with RW!)

I am happy to share, just got it working (it’s a small single pager, so nothing special). Will DM you later or contact you via Slack and stop spamming the Elixier discussions :slight_smile: (Sorry @elixirgraphics)


1 Like