Oops, I have to amend my last post. I always use the HTML for images (I just put inside a markdown stack). I’m using this generic code:
<img src="fullURLhere" alt="text wording" width="100%" />
So the key with Foundry likely is to use the basic coding version combined with the Container stack (this “contains” the width). The Container stack is almost exactly the same as Will’s Useful Stack (which I use all the time in a regular theme)
Yes, well I’m with you. I would prefer a warehousing option. I completely understand.
… I’m just saying you can still use this product very nicely. In some cases you might want/need to drag/drop but I can think of plenty of cases where I can use my old warehousing techniques just fine.
@lastronger BTW, you are correct: it IS a quite pretty product! Very lightweight and clean to use. I’m going to really enjoy exploring Foundry!
I love using it! It can only get better!
I also like Foundry a lot and will for sure use it for a client project in the near future. But one last personal comment from my side regarding the warehousing feature:
I’m sure that if a user can type in the URL of his website (and others) in the browser and can even configure the FTP-upload dialog of RapidWeaver correctly he for certainly is capable of typing in the URL of a warehoused image (what even wouldn’t be necessary with Total/Easy CMS) and wouldn’t be overstrained with this at all. Not even a bit.
And I’m quite sure that in return this feature would convince many more customers to buy Foundry. The price of Foundry (and also its competitors) for sure is reasonable, but nevertheless not for “everyone” or the casual user who sometimes buys a theme here and there. It’s a price which mainly professionals among us are willing to pay without batting an eye. But if then professional features are missing, there’s kind of a discrepancy in my eyes (or at least it leaves a slightly bitter aftertaste).
Moreover this feature would be optional, a simple popup to choose drag and drop or warehouse, so that people who don’t want to use this feature simply don’t need to. I’m sure that once the code for this has been made it could simply be added to other stacks without big effort. But I’m no coder and that’s only my humble opinion. 
Nevertheless I’m really looking forward to use Foundry! Hey, even if I’ll have to use some 3rd party stacks with it… 
Hey everyone!
There’s some passionate people in this thread for sure. Let me put my perspective on it out there and what I am aiming for with Foundry. Maybe you’ll see my point of view, or maybe you’ll disagree with me wholeheartedly. But at least you’ll know where I’m coming from on this topic.
Foundry is meant to be a framework that people of all levels of experience can use and still create great looking sites. I want it to be approachable for even the brand-new RapidWeaver user. Someone mentioned that frameworks aren’t for everyone. I think this insinuates that mostly the higher level, more experienced users are the ones that would use something like Foundry. I don’t see it that way. I think people of all levels want to be able to use something that allows them to layout their pages as they wish.
When I built Foundry I tried to look at things that might intimidate users. Code intimidates users. FTP intimidates users. Databases intimidate users. These are just a few of the higher level things that some of us take for granted when we’re building sites because we’ve been doing it for a long time and are seasoned in these areas. But we’re not the majority when it comes to RapidWeaver users. Really. We’re a vocal minority.
So let me address some of the points so far in the thread –
###I think most here do completely disregard that many, many (maybe most?) of us are doing client work / client sites with RapidWeaver.
(A) I do not disregard that people use RapidWeaver for client work. I think that is something that a lot of people do. Personally I would find it dangerous to allow clients to replace images on the server using FTP myself and wouldn’t allow them to do so. That is just my personality though.
While I think a lot of users are using RapidWeaver to developer for clients, I think a great deal of users pick up RapidWeaver to design sites for themselves or friends and family. Then like myself, or you all they start looking at RW as a way to expand. Foundry is a great way for them to make that transition to build more complex sites, but with the same sort of ease they’ve had with themes.
###Perhaps a “third way” would be to create an add-on pack (even if free) that provided warehousing-only equivalents to relevant image stacks in Foundry. Then the disclaimer to downloading and using the warehoused stacks would be that support for how to warehouse, etc. would be minimal or non-existent.
(A) I would feel horrible having any product out there that I don’t stand behind 100% and support. If I did any less I would feel really bad. I totally understand the sentiment here, but I would have this horrible inner struggle to not support something like that fully.
###Adam wants this to be a dead simple drag and drop solution for Rapidweaver. Warehoused images just does not fit that model at this time.
(A) Steve knows this not because he’s an employee, but because he was a beta tester. He was even one of the many that brought up “warehoused” images as an option during the early days of testing. I explained my viewpoint to the testers and after using Foundry for a while I feel like they saw where I was coming from. What I saw in Foundry. I feel like they got the user experience I was aiming for eventually.
###RapidWeaver’s drag-and-drop currently does not allow SVGs.
(A) This is correct. I think Realmac is working on this. It has been brought up in developer forums I believe as well. But you know what greases the squeaky wheel the most? Emails from users, asking politely for a feature. Realmac is intent on making RapidWeaver an even better platform than it already is. Dan is actively asking for suggestions and feature requests. So email him with them. He is very open to these sorts of requests. If you need his email address, please just ask and I will furnish it for you.
###How though is Warehousing using code???
(A) I don’t think Steve was suggesting that “warehousing” images is using code. I think he simply was mentioning the Foundry was meant to have the ease of drag-and-drop. Just a misunderstanding.
###You are limiting your user base…
(A) I might be. Really. I don’t doubt this. I’m not saying your opinion about “warehoused” images is wrong, just that it isn’t the choice I’ve made for Foundry at this time.
I want a product that is approachable for everyone. This is something I am really passionate about. Bringing new people to this method and style of site design. Bringing new RapidWeaver users deeper into developing amazing sites where they can devote a little time and get a great looking site. Not all tools are to everyone’s liking, but I want Foundry to be that tool that anyone can pick up and start building a gorgeous site within hours, no matter their level of experience.
###Could Foundry have a “warehoused” feature for image placement?
(A) It could. There’s not anything stopping that from happening. That feature is just not one I’m looking to implement at this time. Foundry is still young.
Is Foundry wrong or a bad piece of software because it doesn’t have a specific feature? I don’t think so, but I’m biased. I think it is a good tool for developing really versatile sites in RapidWeaver.
One last thing – I want to ask that everyone be kind and courteous to one another on this forum. It is one of the main rules of the forum in fact. We all have differing points of view. That is what makes us all so different and interesting. Otherwise we’d all just be boring, carbon copies of one another. Blah. Who wants that, right? But we can all try and respect each others view points, I hope and have open discussions.
Hopefully I’ve answered everyone’s questions on “warehousing” images, as it currently stands in Foundry. If I haven’t, post here and I’ll answer them for you specifically. I probably overlooked some as the thread was really long before I even got to sit down and read through it.
Thanks for taking the time to write such a thorough response.
I fully understand the arguments against warehousing images. But the thing I fail to understand is how it would made Foundry LESS approachable, surely it could be a feature that someone could turn on to expose the feature, and by default it would be off so the average user would not be impeded by its presence. But the person that does care and understand can expose it and leverage it.
I love Foundry and think it is a great piece of software. But I’m one of those people who likes to use all of the provided stacks and minimize the use of 3rd party stacks.
Currently, I never use the Foundry Image stack, I replace it with one that supports warehousing. While this works with no problems, it annoys me as I would like to use the stacks provided by Foundry!
I think adding support for something like this to Foundry can only enhance the value of the framework.
It could even be as simple as starting with a warehoused image stack, that can be used in place of the standard image stack!
I know I for one would like to see support for this Foundry as I feel it would only enhance it’s use!
I know this is an old thread, but I came across it while looking for a solution to “warehouse” some images in Foundry.
After reading all the posts, I fully understand why Adam isn’t keen on adding warehoused images as an option to Foundry, but I really wanted to warehouse some images on one project I’m working on and after a bit of searching, I found the Remote Image stack by @instacks which does the job nicely.
I’m using Foundry and yes indeed it’s a limitation… no warehousing. Also missing a 2nd child-level navigation at Foundry.
Hope that Adam will consider it for a future update somewhere…
Would be interested in your thoughts on this Adam. Thanks!
I have been wondering about warehousing for a while and this (remote image) may be a solution. Who better to ask that the guy who created the tool I am using to build my web site (Foundry)! I tend not to jump into something (with the exception of Poster which I immediately bought). Interested in your evaluation as I’m at the point where I need to decide on how to handle images. Thanks!
@Psalm66 – My thoughts on “warehousing” as a whole are outlined further up in this thread, and haven’t really changed.
“Warehoused” images – images that you’ve uploaded to your server manually and then link to using a typed URL in RW – aren’t something I’m looking to add to Foundry. The drag-and-drop method I employ in Foundry, where images are used, allows me the ability to process the image(s), sizing them, cropping them, and more, allowing me to provide features in stacks that I might not be able to otherwise.
It also keeps the user from having to remotely manage the images separately from their project file and having to supply the correct URL for their image. While those things aren’t hard for many users, some novice users may have problems with it.
I’ve provided more detail earlier in the thread though, so go back and have a look there if you’re interested in more.
One thing to consider is that by not offering warehousing, it is easy for others to knock Foundry. I have read and heard criticism that Foundry lacks warehousing and is therefore not complete or as good as other frameworks. I happen to think that Foundry is by far the most complete RW Framework available, and you don’t need to go outside of Foundry to do most things - except when you want to take advantage of warehoused images.
I generally don’t use any image stacks unless they take advantage of warehousing, but in the case of Foundry, it is just as easy to use one of the many 3rd party warehouse image or image BG stacks. It’s just a shame you have to go outside of Foundry to do this.
Also, I just can’t see how adding a warehouse image check box, would make life more complicated for beginners as this is standard in so many stacks today. If the warehouse option is unchecked by default it won’t confuse or complicate and some instructions that get displayed when checking the warehouse box, could go a long way to explaining the process with an example…
There is definitely a RapidWeaver culture that doesn’t see the huge advantages of warehousing.
Not sure what else I can elaborate upon that I haven’t already mentioned in the thread. Adding a checkbox to a stack to enable “warehoused” images isn’t quite that easy. Some of the stacks within Foundry make use of the Stacks API in that they crop and resize images for specific purposes within the stack. This is not available to an image placed via “warehousing” so those stacks that make use of the API in that fashion would not get those benefits.
There is absolutely nothing wrong with using an outside stack if you deem it a priority to use “warehousing” for an image for whatever the reason. Foundry should work nicely with just about any outside stack. That is a strength of the framework.
Boy, do I wish I found this thread before jumping into Foundry.
Totally respect Adams viewpoint, don’t get it or agree with it, but respect it. But looking at the way I build sites, which are image heavy, often with the same image on multiple pages for header and footer backgrounds, having no option to warehouse images, especially on the Potion Pack stacks, renders Foundry, for me, little more than a beautifully curated and well thought out virtual paperweight.
As the rest of the RW community slowly but surely moves towards warehousing, I’d perhaps suggest this decision to not add the functionality to Foundry be highlighted somehow in the pre-purchase information. Perhaps it is, perhaps I didn’t look, perhaps I’m guilty; no, I’m sure I’m guilty of assuming a product like Foundry would support warehousing where possible. So lesson learnt.
To my mind though, having a cutting edge product such as Foundry (cutting edge, as in framework opposed to off the shelf theme, which is I feel still the norm for the novice/basic user) is a bit like a modern car not having ABS. You don’t check the literature to ensure your new car has it, all the others do, so you assume. A bad analogy I suspect, but you get my point.
Out of interest, which ones? Obviously, I’m no expert, but I can see a couple at most. But I’m curious to know the actual number if your willing to divulge such information.
Does this not go against the concept of Foundry: An all in one, self-contained easy to use framework for the masses?
Finally, to anyone who cares to respond and supports the “no warehousing” approach, a scenario that I’d like your views on, and this is a real world scenario.
I have a site, with a hero header on the hompage, and banner header on all other pages. They all use the same image as a background. The same image also appears as a back ground to the footer. The site consists of 13 pages. The image (massively optimised) is 156kb. This site would be a perfect candidate for a Foundry conversion.
Using warehousing, the total download size for all the header and footer backgrounds across the entire site is 156kb. Not using warehousing it’s just over 4mb, or 26 times the size of the actual image, because, as we all know, when an image isn’t warehoused every instance of it on a site requires a separate download, in this case, 26 times.
This goes against everything that is considered good practice in web design.
Now I understand this might be considered an unusual example, but really, is it? Clever web design encourages repetition of images across a site; it sits well with the whole “mobile first” methodology, which isn’t just about content layout but keeping your site slim and streamlined.
To finish, I’m not attempting to apply pressure for a change of direction, as said at the top, this is Adams baby and I entirely respect his decision. I’m just trying to better understand the logic.
@SteveB - I hear you and it has all been said many times. It is no coincidence that this is the most viewed topic on the Foundry forum by a massive amount. This topic is the most interesting topic for Foundry users and prospective buyers and therefore, there must be a good reason why Foundry Forum viewers are reading this thread more that any other. 1.6k views for this thread and 1.2k for the next most popular.
Sorry to say this, but all I can say is for you to abandon the Foundry image stacks and use warehousing image solutions from BWD, S4S, inStacks, JW, etc. Pretty much every other developer in fact.
@elixirgraphics - Adam, I really hope you will reconsider your thinking on warehousing.
Someone recently made a comment about RapidWeaver as a web building solution and commented that overall it was a bit unprofessional and lacked vital things that mattered for professional web builders. They pointed out that still there are pieces of the puzzle that are missing. No warehouse support in Foundry is one of those missing pieces.
Warehousing images is at the core of web design and is at the core of Bootstrap.
I am in a unique position because as I create Projects for Foundry and the other one, I frequently get asked the question which is better or which should I invest in. I always give a fair unbiased opinion of the advantages and disadvantages of both. My reply is that the only thing single thing that goes against Foundry is the lack of warehousing, and unfortunately that remains an instant show stopper for many.
I don’t believe that adding warehousing would over complicate the Foundry graphic stacks, as it would only require 1 single visible tick box. When ticked, the image well could be replaced with a link URL in the exact same way that the majority of stacks developers do it. This technique I well know to many RW users and understood.
Life has moved on and whereas it was not a basic required feature to provide image warehousing 5 years ago, it certainly is now.
What do others think?
Gary: Yes, I’m certainly with you on this one. I’ve learned to work around the drag/drop quirk of Foundry.
I’d like to provide another example where warehousing would be very useful: the case of SVGs.
Someone like Steve (@SteveB) mainly uses photo images so it’s perhaps irrelevant to him and others. But … SVGs are, by far, the best way to display illustration-based images. Much superior to JPGs or PNGs. I use them a lot for things like visual models, concept maps, specialized tables, and other illustrations on my course websites. SVGs are not only lightweight, but they look fantastic at large sizes because there’s no loss of clarity or sharpness.
… when one can warehouse with any relevant image stack then I can also include SVGs. However, drag/drop excludes this usage. Thus there are certainly times where I need to come up with an alternative design because my first choice for a stack might be a Foundry image-based stack but I can’t use an SVG with it.
Yes very good point. I completely forgot to mention SVG’s which cannot be used with the standard Foundry stacks.