Creating a portfolio site

I am researching the best way of creating a portfolio site for a family archive of photographs.

I have recently upgraded to RW8, so this would be the first project using this iteration. I have Stacks 4 and am considering adding Gallery Stack 3 to the collection, along with Remote Stack Image Integration from the same developer to allow me to warehouse the images on my webspace (which is Dreamhost).

From reading up on the various options, this seems to be the simplest way forward. I don’t want to use a third party host for the images (I’ve learned my lesson from using Flickr!), and since this is an archive it’s very unlikely that the core material will change or need much updating. The images are not enormous - most of them around 1-1.5mb, and the total archive comprises 1750 or so images. I’m expecting the warehouse file to be about 2.5GB in total. There aren’t any restrictions on my webspace (within reason) and I don’t expect this website to generate a lot of traffic; it’s really so that the family of the photographer has access.

One of the things I anticipate needing to do is create several folders covering different topics, and I am sure that a lot of photographs will have at least two or three attributes (such as location, people, year, architectural style) which will mean that they appear multiple times. I am presuming that using the same image in multiple folders won’t cause problems.

The other desirable functionalities would be thumbnail/lightbox (which I’m confident most image stacks would offer) and some way of limiting the download size so that visitors are not able (easily) to download the full sized image if possible. (The archive is actually fairly low resolution in any case; anyone who wants to use them commercially would have to order images produced from the original negatives)

Before I shell out even more cash, does this sound like a good plan? Are there more efficient ways of warehousing and serving the images?

Many thanks for any help/observations/criticisms/steers!

1 Like

I think it’s a good approach. Jannis (@instacks) the developer is always helpful if you have questions.

Sounds like organizing is going to be most of the work.

As for limiting the download size that probably not doable. If a user can view the full resolution image they can save it. Any of the “protection stuff” just makes it a little more difficult for a causal user. The thief’s know easy ways to get right by that stuff.

Either watermark or show what resolution you don’t mind being taken.


Cheers @Ben1 sounds good.

As @teefers said.

Let me know if you need additional help.

1 Like

Yes, I think you’re right about organising! I’m going to see if I can get a family member to help me sort/tag the images so that we have a solid foundation before I put the site together.

Thanks Jannis! Sold!

1 Like

When having so many images in folders, check the folder integration:

This might be interesting to you:

It uses @instacks Gallery 3 and Poster.

Hi @Ben1,
Here is our designer/photographer website, using our soon to be released RapidWeaver UIkit Project. This particular project uses UIKit3 from @Lucas, Gallery3 from @instacks, and Instagram_Vista from @weavium. The project will have other options as well.




Another option for a portfolio site (this time based on Source) is now available. Check it out here. The project pages could easily be switched to being different galleries.

More details in this post: [Source] New project file - Freelancer!

1 Like

A related question, this time specifically about Stacks 4, and warehousing images. I’ve just been viewing the new features included in Stacks 4, and Isaiah talks about “warehousing” images and “externals”. It’s not completely clear where these images are stored; I’m sort of presuming that if they’re accessible to different projects then they’re being stored outside the main project file. I know it’s good practice to keep the project file as lean as possible so images should be stored separately; I’m wondering if this does that or whether I need to create a root folder as normal?

Thanks everyone: much food for thought here!

These are two different things. Externals are stored in a separate library and are shareable between projects. They’re like Partials but can be shared across different project files. They won’t impact the size of the project file.

“warehousing” is RapidWeaver Slang for an externally stored resource, mainly images. That’s not new to stacks 4, so I don’t remember where he talks about it. Older versions of RapidWeaver had a lot of problems with the internal resources. Part of RW8 was a complete rework of resources management.

There is a new feature(stack) in stacks-4 called “site Image,” that uses the new RW8 resources.

Honestly, I’ve done quite a bit of testing using both the new site image stack vs warehouse image stack, What I found is that the site image stack way outperforms storing images remotely as far as editing a project. That makes sense as the images being rendered in RW edit and preview come from the local drive.

So as for this conception that a “large” project file slows down RapidWeaver, simply isn’t true. Now if a project file is very complicated with lots of complex stacks and pages than RW slows down. The raw size of the project file doesn’t really impact the performance and using the RW8/Stacks 4 “site image” actually improves edit and preview speed over remotely stored (Warehoused) images.

Gallery Stack fully support these new site images also, beside the well known folder integration or the Remote Image Stack, to be found in Repository Stack.

Also image source like shared Apple iCloud Albums or Behance projects are easy to be integrated.

Full set of warehoused images at your fingertips.

1 Like

Thanks so much, @instacks and @teefers.

I’ve been using RW since version 4 (at least), and one of the things I learned early on was that including very big files within the project itself was bad practice. If I’ve understood you correctly, this problem is now solved, and it would be fine to include all 1750 of my images (admittedly not huge individually but there are a lot of them) in the project file itself? So in that case, I don’t need to store the images as a separate folder and link each separately? That will speed up building the site considerably, because I can add them as I go. The plan was to upload a root folder with the images and link them: I don’t have to do this?

And using Instacks’ Gallery3 stack will manage the resources if I do go ahead and build it this way? I would very much like to avoid having to store the images on a third party server, since this is an archive which will not be added to.

Sorry for being dumb!

All documented here inStacks Software | Gallery Stack 3 - The most versatile and kick-ass Photo Gallery

Not anymore from what I can tell from testing. If you click on a resource in RW8 and reveal in finder, you will see it’s a simple copy of the resource and a small contents.pList file. So from stability and performance I haven’t found a downside.

Now from a “management” side having 1750 images it’s probably going to be worth looking at uploading them separately into folders that match up to what’s going to be displayed with the Gallery stack. It has the option of showing all images inside a single directory.

You don’t have to use a 3rd party server. Just create a directory (folder) on the server you are going to be using. Then use a stand-alone FTP program like Transmit (paid) or FileZilla(free) to upload the images.


Thanks so much. I didn’t understand how much had changed under the hood since my early days with RW.

Jannis has pointed me in the direction of Gallery3’s solutions to the warehousing challenge, so I think I’m probably good to go now. I’ll start putting it together tomorrow. (And post something once it’s up and running!)


I think that for good portfolio website you need Depth… by @nickcates it will make a good picture book very professional and rersponsive. worth every penny.

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.