I want to give my users the ability to create Albums of Images but I want the images to be nodes. Since the Albums would be nodes as well, would this mean that I am asking for Nodes within Nodes?
Ideally I want users to be able to create multiple galleries like facebook and then upload Images as nodes so I can apply node related functions on them like paging, favorites, views and block manipulations etc..
I can create Albums with a set number of imagefields but I can't operate on these images because they're not separate nodes.
Gallery2 can create Albums but these images are also not nodes.
Is there a solution that will enable me to create Albums as content types and have multiple image nodes within the Album?
Comments
image module
It sounds like you're looking for the image module for images as nodes, which includes galleries -- see the handbook for more info.
I drubeedoo thanks for the
I drubeedoo thanks for the reply,
While the Image gallery supports the creation of galleries by the Admin, It leaves my high and dry because I'd like my Users to be able to create galleries that they administer.
From what I see in the access control, there just seems to be an Administer Image Gallery option available and no "Edit Own Image Galleries" option.
Do you know of any other solution that can enable my Users to create and manage their own image galleries while keeping the Images as separate Nodes controllable in Drupal? (as opposed to Gallery2).
You might be able to do this
You might be able to do this by creating an "Image Gallery" content type and using imagefield with the multiple option on. With this method, each node would be a gallery with multiple images. Then you could use the "edit own image gallery" permission to control the access.
If you truly want each image to be only one node, then you could use imagefield with multiple option off for users to create individual imagefield nodes, then use imagefield_gallery or views to create galleries for each user (permission would still be controlled by the "edit own" permission for the image content type you create).
EDIT: for a cool video on this method see http://www.theartlab.net/drupal-school-009-maintainable-gallery
and a newer version of that video: http://www.theartlab.net/drupal-school-creating-multiple-maintainable-im...
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Thanks for the reply
Thanks for the reply Wordfallz, but I've identified the heart of my problem: my users need to be able to create MULTIPLE galleries of images.
Creating Single image galleries is easy -- users can continually submit individual image nodes to the gallery defined by the Admin using taxonomy_image module or even Views.. but I want my users to be able to create their own galleries and ideally multiple galleries of image nodes.
It seems like all the suggested solutions I've seen limit me to the following:
- Admins have to create the galleries for the users to submit images to
- Users cannot define their own galleries
- Users cannot create multiple galleries.
- Images cannot be nodes if users are able to create multiple galleries.
- There is no such thing as nodes within nodes.
This is day 4 of my research. I'm going crazy! I'm starting to think Drupal cannot accomplish the challenge of giving users the ABILIITY to create MULTIPLE galleries of Image nodes.
Do you know of a way?
Over the last year that I
Over the last year that I have been using drupal, I'm still pretty new myself, I have found that every time I thought I reached a dead end (something drupal couldn't do) it wasn't really a dead end. what was faulty was not drupal but my thinking-- without fail, I found a solution to every one of these dead ends by changing my thinking and finding the drupal way of doing something.
I have absolutely no doubt that what you want is possible, the question is finding the best/easiest way to do it.
Still being fairly new, i may not be the best person to answer this but, if you truly want images to be single nodes and you wish users to be able to create their own galleries, I can think of a couple of ways to approach this.
First, you can try this with imagefield and one imagefield image per node. Have one content type for images and one for galleries. Have galleries related to images with http://drupal.org/project/relativity or perhaps a smartqueue with http://drupal.org/project/nodequeue.
Second, see Multiple galleries and taxonomy
One other thought, try http://drupal.org/project/acidfree
If none of those work... post back...
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Thanks for the guidance,
Thanks for the guidance, WorldFallz, I, too have been using drupal for about a year now too, and I agree with you about the: "if there's a will there's a way" versatility of drupal.
Here is my progress:
I've decided to bite the bullet and try the dev version of Acidfree. I typically steer clear of dev versions due to bad experiences in the past. However, in this case, things seem to going on the right track.
Here is my work in progress: http://www.stirmagazine.com/user/1
Acidfree allows me to knock off the following of my requirements:
1. Users can create multiple galleries [yes]
2. Images are created as nodes and other users can leave comments on them [yes]
3. Users can manage their own gallery contents [yes]
Initial investigation shows that the idea of "parent albums" might be confusing to my end users. Also, the workflow from album creation to image insertion doesn't seem too intuitive for my end users. Maybe pageroute can help here.
So right I'll continue tweaking things consmetically and functionally.
Again, thanks for your support on this rather stressful issue of mine! If I can be of any help to you in the future, please feel free to ask!
your welcome and I like what
your welcome and I like what you've done so far-- i've not really played with acidfree very much so I can't comment on the workflow but I'm sure they'd appreciate any feedback/patches.
Personally, I think i'm going to pursue the imagefield path some more-- i love the flexibility of the imagefield/imagecache/views modules and they are very well supported/maintained (in general, i agree with your sentiment about dev versions). I'm POSITIVE there must be a relatively elegant way of providing galleries per user-- i'm just not seeing it (my drupal vision is sill new, lol).
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
your welcome and I like what
looks like i missed a promising module.... http://drupal.org/node/213202
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
some more info... yagm looks
some more info... yagm looks like it's supposed to handle this, but i can't figure out how to get the user/gallery/image relationship to work and there's no documentation.
I think I've found a decent method. One image content type, one gallery content type. The image content type has an imagefield that accepts only one image, and a nodereference field that displays a view of the gallery nodes the user created (you have to create a gallery page before you can assign images to it, makes sense). The gallery content type has a description field and a viewfield to display the view of the images that belong to this gallery. I'm still playing with the views, but so far this looks to be a fairly simple way using basic modules (cck/imagefield/views/viewfield, and optionally imagecache which adds some nice functionality).
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Looks like the dev version
Looks like the dev version is just not there yet. It's 90% of what i need, but the pending issues are too much to deal with for it to be on a live site. Here are the notables:
1. Users receive an Access Denied error after submitting galleries (but the images still get uploaded).
2. There is no default parent album that users get, Thus the second album that users submit automatically get submitted under the first one.
Aside from those 2 issues, the module is amazing. worth keeping an eye on.
Sigh, isn't it always the case, that the cool module that you specifically need for your current project always seems to be in dev mode...
Update: I installed Gallery2
Update: I installed Gallery2 as a possible option and here is my review
1. WAY TOO BULKY. Too many options, configurations and adjustments for a simple non-tech savvy end-user. My users will be boggled down and mired by all the options of which 80% of them he or she will not ever use.
2. Installation takes a very long time. again Way too many configurations.
but.. it's ideal for a semi-tech savvy media-savvy demographic. Quite powerful and highly extensible. But not simple.. nor are the interfaces simple.. again too many options.
Acidfree would be perfect, but its only dev.
arghhh.. i guess i'll try YAGM
Yeah---i agree about
Yeah---i agree about gallery2. Actually, I stay away from integrating monolithic 3rd apps in general-- forums, gallery, whatever. It just feels too clunky for me and it's always overkill and bloat-- not to mention another point of failure with a completely separate support system.
I played around some more with yagm-- after reading through the code (there's NO docs), i realized that it doesn't do any of the relativity config. So, after manually playing with relativity it turns out yagm does exactly what you're after. It's basically just a glue module that does the grunt work of setting up the field (you can't have a pre-existing field_image imagefield when you install it btw), content types, imagecache presets , and views which is very nice and time saving. Your user galleries are at user/$arg/gallery-- nice.
Couple of observations:
In the end, i'm not sure how much work it would save me over using the nodereference cck field to establish the relationship between images and galleries. I also plan to check out http://drupal.org/project/nodehierarchy which some people prefer over relativity.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
Great review on
Great review on Yagm.
Unfortunately, I'm stuck on a PHP 4.3.9 host. ImageAPI requires php 5. I've also documented (a long with others') how Imagefield 5.x-2.x doesn't function properly on my 5.7 whereas Imagefield 5.x-1.2 works fine on the same environment. There goes 2 of YAGM's requirements :(
argh!! just out of reach.. Running out of options! I've received similar sentiment on how Drupal is definitely lacking in clean and 'functional' per-user album solutions.
Gallerix promises per-user albums, but it's having problems in its official release.
I took a look at Multiple Image Upload (Imagex module) as an option to just use CCK + Image Module + Views to create per-user single albums, with easy bulk image uploading, but even Imagex is having official realse problems.
So my options are...
1. Find a new host that has php 5 + wait for a solution to my ImageField 5.x-2.1 issue (so i can use YAGM)
2. Wait for the Acidfree 5.x update (but the maintainer suggest he might just forgo the update and work exclusively on a 6.0 release)
3. Wait for the Gallerix update version 1.3 which claims to solve the operational issues.
4. Resign to using a single per-user album with single image uploading at-a-time. (do not want!)
A Minimalistic - Bulk Uploading - Per user - Drupal friendly - Multiple Gallery - Image Album solution remains... just out of reach.
you should be able to use
you should be able to use the nodereference method i briefly outline above--- that means you have to do the work of creating the views manually, but it only requires cck/imagefield/views-- and whatever version of imagecache works for you should be fine since you're doing the views manually. Optionally, you would also need viewfield if you wanted to embed the image views right into the gallery node. Nice, but not required. I like this method because it doesn't rely on anything but the basic modules i've already got installed on just about every site i setup.
===
"Give a man a fish and you feed him for a day.
Teach a man to fish and you feed him for a lifetime." -- Lao Tzu
"God helps those who help themselves." -- Benjamin Franklin
"Search is your best friend." -- Worldfallz
I'll give the nodereference
I'll give the nodereference method a shot after I attempt to assemble the custom module appendage to Acidfree. I have to learn how to assemble the module through the handbook http://drupal.org/node/82926 But at least the community has provided the code.
If that fails i'll try your solution. I'll let you know how things go.
Are you currently building a social networking?
Well a 5th option exists.. I
Well a 5th option exists.. I read about a custom module appendage to Acidfree that makes automatic per-user albums on user-creation. http://drupal.org/node/144636
One of the problems with Acid free was that a user would be forced to submit their second album under their first album because since there was no default album created, the first user album becomes an automatic Parent of all future albums due to the fact that it's the only option that shows up in the drop down menu during album creation. So the proposed solution could solve that issue and magically I'll have a per-user album solution!
So i'll look into that.. maybe Acidfree will work for me with some slight modifications. Possibly can hire a dev to clean up the code after.