I’ve always stored images locally so have no experience with warehousing. I understand the basic concept of warehouse images but what is the best way to do this? Some stacks offer different features if you ‘warehouse’ an image (such as Joe Workman’s Total CMS I think).
I don’t even understand what the warehousing options/requirements might be? Do I just need a path to ftp storage? Do I need a separate stack toto help set up ‘warehouse storage’. All insights and guidance would be most appreciated.
So I create a folder say where my site is housed. I name the folder ‘warehouse images’ or such and I copy the path for each image to the appropriate spot in Rapidweaver Correct?
I warehouse 99.9% of all my images, let me see if I can explain my process.
1st off warehousing is simply the term thats come about for the storing of your images (and pdf etc) on a server, be it the one your site is on or another one, there’s nothing complex or clever about it.
I use Transmit to access my hosts servers, its just an FTP programme and there are others out there.
Here’s a screenshot of this site viewed in Transmit: https://infinit.io/_/37g45dT
The highlighted files are the site as exported/Published by Rapidweaver.
Now for the warehousing bit:
I create a folder called Assets and then in there I create (if needed) subfolders which contain the images/pdfs/whatever, here’s a screenshot of the Assets folder expanded https://infinit.io/_/SyaFVcU
I then right click on one of the files and select ‘Copy URL’ and I can then paste the link straight into whatever stack I’m using that supports warehousing images (99% of them)
The path will look like this: http://www.nqca.eu/assets/flags/Flag-UK.svg
And that is it.
I use the name Assets because it starts with an ‘A’ and will be at the top of the list, others use a folder starting with ‘Z’ so that it will be at the bottom, other than that we all do it essentially the same.
Once you have your folder and images uploaded, you may want to take a look at this stack. Basically just add a relative path to your folder and it creates thumbnail images, and a lightbox viewer all in one stack:
I’ve been doing this for a while (warehousing images in an “Assets” folder on my server), however there’s still some issues with this approach. You must enter an absolute path to the files. This is not ideal for two reasons:
it’s painful to enter it endless times if you write css or use html code (HTML stack) and is prone to errors
If you use another folder to develop you site (besides the public one), you have to update all the paths in the html/css code you use every time you move the site from the development folder to the public folder
Using relative paths circumvent those limitations however the images will not appear in Preview mode inside RapidWeaver. The only solution i’m seeing (not tested yet) is to move the assets folder to a subdomain and use absolute paths in the code so the images can be previewed inside Rapidweaver. Is there anyone using this solution? Any issues?
I cannot imagine building a site without using warehoused images unless I wanted to:
Enlarge the size of my RW file and slow down loading, saving and Publish times
Slow down the loading of sites with duplicate images or icons by not taking advantage of browser caching
Lose track of the name of images loaded into RW
Prohibit me from using minuscule sized razor sharp SVG images
Prohibit me from live editing multiple SVG images using only a text editor
Making quick backups of all images used in a site
Edit multiple similar images in RW or live by making one change
Make quick changes in published sites (preview or edit also) by swapping out one image and not needing to Preview again.
Speed up development and prototyping time.
Improve SEO by naming images
The list goes on and on. If none of that is interesting, then avoid warehousing.
In about 18 months of using warehoused images with RW I have never found a draw back or problem and all you need is an FTP program and can even use the free CyberDuck FTP App. Further, I avoid any stack that doesn’t support warehousing.
Just an update on this following on from the release of the V3 of Forklift FTP. Forklift has a cool server preview mode that allows a preview in a preview pane - exactly like Finder preview, that enables you to see your warehoused images. This allows a visual navigation to the image you want and right clicking calls up the image URL to then paste into your warehouse enabled stacks image. This will really aide some users who don’t like dealing with filenames.
I recall hearing in a Podcast about 9 months ago, that warehousing will be implemented in RW7.1. Still looking forward to that.
I’d think the main one would be project file size. If you have a bunch of images, and get to a very large project size, it could probably/potentially impact RW performance
I use Dropbox for all my files, RW in v6 (and I assume v7) would break the links to resourced files when moving between my 2 Mac’s.
Whilst the RW resourced files are warehoused when published they are buried in a sub sub sub folder on the server, I like to have a folder called Assets with sub folders (fonts, images, pdfs etc) which I control in the root of the site or preferably in its own subdomain such as www.assets.mywebsite.com.
Removing a file from the projects resources DOESNT remove it from the server folder if the project has been previously published, I like to only have what’s being used on the site in the assets folder.
If I accidentally delete or rename a resourced file then there is no indication (I think) within the project that it is missing. Manually warehousing means that there are 2 copies of a file (local and server)
Yes, as a photographer, my RW file was over 600 mb with resourced images. Now, all warehoused with links to my server folder, my file is 71mb. Big difference.
There is almost every reason not to do it through Resources. A big part of the benefit of using warehoused images is to be independent of RW and edit or rename file names without having to open up RW. If you make a change on the server it could be overwritten by the Resources during the next Publish.
The way that RW could really (absolutely bloody should) implement this properly and bring a big advantage to RW, is to implement a server media browser in RW. I.e. so you would add the address of your warehouse folder into the RW Setup, so you might enter www.mydomain.com/warehouse and then, from inside RW, use the media browser to browse visually the contents of the warehouse folder and sub folders. Then by implementing a way to select an image (visually) and add to an image setting in RW would complete a great new RW feature. By dropping images into the media browser in RW, you could use the “Fast as hell” FTP function to upload images to your server.
This approach would have benefit in implementing CMS solutions.
It makes no sense whatsoever to use Resources IMHO.
Dropbox public folder is going bye bye for everyone, no public sharing of any kind.
If you are storing stuff in there that’s then being linked as a URL within a site you MUST change NOW or your going to wake up to a very broken site on the day they close public folder access.
I think RM should bite the bullet and declare a favourite FTP client, be it Transmit, Forklift, Yummy and then make use of the api’s those developers offer to intergrate whichever one is chosen into RW’s work flow.
Let the current publishing stay as legacy but persuade people to move to the new method with some sort of discount for the chosen FTP client.
@PaulRussam I absolutely agree as a minimum requirement that RM should work with an FTP developer and would suggest Yummy who are also part of the monthly subscription App model that RM are too (can’t remember the name of it). Then the months of effort spent fixing the FTP could be directed toward a new feature.
smile:
