Images in Stacks named wrong

since RW 7 I have the problem, that RW exports the stacks images with capitals, but in the html-file the image-names are shown with small letters. The result is, that the site is shown without the images or I have to correct it in an editor.

file-name: stacks-image-Header-.png
in the html-page it is named: stacks-image-header-.png

Stacks and RW are the newest releases.
Example online ist here:

The header image is missing.

Any ideas?

Thanky you for your help!

Long post coming. The short answer is: Stacks like to use lowercase. Your Stacks pages should all work fine that way. It’s a good thing. If you rely on those names being upper case from elsewhere (like custom code that links to them) I’d recommend just going with lowercase as a workaround – as there is no way to get stacks to do anything else currently.

OK, here’s the “why” for that… this is a bit long and kind me thinking out loud. feel free to skip it. :slight_smile:

What’s supposed to happen:

Stacks is supposed to make all file-names lowercase. The goal here is to ensure that novice users don’t get caught off guard by case-sensitive vs. case-insensitive differences between their own Mac and the machine hosting their site. This was done to correct problems where naming conflicts would be resolved one way on your Mac and differently on the website host machine. By always forcing lower-case all filename collisions and typos are guaranteed to behave the same in preview and the published site.

An very simple example: If you had two images on a page called “Flower.jpg” and “flower.jpg” these would not conflict on macOS. However move to some other systems that are case insensitive and one of these files will overwrite the other. So the site would look different in Preview than it would after being published.

We made this change (I just checked my logs) at the end of July in Stacks v3.2.0 – this was the result of a bug report by a user and rash of support issues where this was specifically causing problems on a popular hosting company’s site.

This is a tough nut to crack…

You might think that Stacks should simply honor the name you type in. On the surface, that seems like the expected behavior.

However, that’s not the case. Web servers are very diverse and have myriad rules for file names: disallowed characters, symbols, length, etc. And Stacks users are mostly unaware of these rules – and happy to stay unaware. :wink:

Stacks (and RapidWeaver in general) does many things with file names, page names, etc. to ensure that the exported content fits these rules. Users are free to enter (nearly) anything they like in the name fields and RapidWeaver and Stacks take care of the details.

I think probably the best way forward would be to allow for a specific preference that expert users could enable that turns off some of the nanny-hand-holding features and allows the user more direct bare-metal control over their filenames. I will try to work this into a future release.

I’ve filed a bug for this on our bug tracker – you can follow along there to see when we add this in – and add any detail that I might have missed.



Isaiah… that is very interesting information and it is exactly the type of info that I wish was more “typical” in ALL documentation be it Realmac/Rapidweaver docs or 3rd party. Thanks for the detail.

Since this is a casing issue, I assume you’ve never had any problems or issues with underscores or hyphens in file name?

oh boy. underscores. that’s a whole other can of worms. :wink:

similar: underscores are allowed in some places and not in others.
different: it’s not a problem with filenames. it’s an issue with URLs.

and just to make matters extra strange, officially the RFC on allowed characters in URI’s is much more limited than is generally accepted by the internet today.

in other words, officially, you shouldn’t have a URL with an _. those should be mapped to another character, like -.

but the reality is that no real world web servers behave this way. both dashes and underscores are accepted file types on all platforms that really matter.

the one big caveat here is in dealing with other API that might throw errors if you try to build out-of-spec URI’s.

lots of APIs for popular services are more pedantic in what they accept as a URI – so they’ll kick out something that doesn’t meet all the rules.

this is NOT an issue for users, but is for 3rd party stack developers (or like me, plugin developers). for devs like us RapidWeaver has a set of internal API methods that can clean up any string/identifier/whatever to a variety of different specifications. so if you need to URL encode the string you can do that and it will map the dashes away. The Stacks API in turn passes these methods on (and adds a few more) to the 3rd party stack developers so they can also use them.

It’s documented in the Stacks API docs here:


1 Like

Hi Isaiah,

thank you for your replys. I don´t understand where the names came from. I named the pics with clear words in the finder (schlottportraet.png). But in the files folder the images are renamed very strange after exporting the site, like "F5gfhsZHG.png).

Do you know why this happens?


Yes. Stacks does not pick up the file names used in the Finder. Often these names are not suitable for use on the web. It generates filenames for you that are guaranteed to work on a wide range of servers.

If you would like to set a specific filename you can: in Stacks double-click on an image to open up the edit view. Then show the Info sidebar. The top setting is the filename. (see pic below).

There are, of course, times when it would be appropriate to honor the filename. That is what we did in Stacks 2. However there are SO MANY conditions where the filename has to be modified it quickly becomes confusing trying to predict how a filename will turn out – even for me and our support folks.

In Stacks 3 our goal was to simplify this whole process. Make it “just work” for novices. Make it more customizable for experts. And make it simple and predictable for our support folks.

This took a huge burden of worry away from novices, but has made Stacks slightly more complex for more savvy users that do want name their files specifically.

Do you sense a pattern here to all these answers?

We strive to make things easier for novices even if that means making them a bit harder for experts. This is because experts can bare that burden and novices cannot.

I think there’s room for improvement here, such as the issue I linked to in the post above.


Use care when copy/pasting stacks. If I copy and paste a stack with an image the old image appears in the new pasted in stack (of course). When I drop in new image the new image shows. But the image filename does not change! When I publish the page the new stack has the old image. I look at the copy/pasted stack in RW it has the new image but the old name.

So… be sure to ALWAYS check image name on copied and pasted stacks. If the stack exists with a pic, the pic name will be retained, even if dropping in new pic. At least… that my experience.

that is confusing.

let’s call that a bug. filed…

i’m not sure what the correct behavior there should be:

  • clearing the name when you drop in a new image is probably the right thing most of the time. but will definitely be annoying sometimes too.
  • clearing the name when copy a stack is definitely wrong – when an image appears on the page multiple times you WANT it to only publish one file.

really what we want is some sort of complex behavior: when another image exists on the same page with the same name AND the image gets changed THEN clear the name.

and, of course, when you throw partials – and their ability to reuse content from other parts of the site – yeah. naming files gets so complicated in a hurry. kind of makes my head spin. :wink:


1 Like

Could just ask, pop up a entry box with the current name already in place. A quick [return] if you want to keep the name, a way to change it on the spot if not.

The stack has to react to the user dropping in the new image where one already exists, so at that point just present a warning: “Possible new/duplicate image. Verify name and alt text.” A reminder only would be fine in my estimation.

@swilliam - no. that wouldn’t work. sorry, to be so blunt. but that’s circular reasoning. and a pet peeve of mine.
the problem here is that novice users don’t know (and don’t want to know) how to name files. asking them to solve their own problem is asking for trouble.

we would be asking people a question – when we know those very people – are (blissfully!!!) ignorant of the answer.

I see and fully understand your point. My view is much narrower than yours. I truly appreciate your explanations and comments here! Thanks!