Allow sub galleries

subscribing, is there an option how to do subalbums/subgalleries?
you know, it is useful for something like this: album "our site events", submalbum "event 1", subalbum "event 2" etc, the same for user albums.

thanks
Igorik
http://www.somvprahe.sk

Not really ... or not yet, any way. If you play with the provided Views you might be able to achieve this, but currently it is not a feature. Will add it to the wish list! =)

It might be interesting to try http://drupal.org/project/nodehierarchy , I havent done so yet :(

Again, aimed at 6.x-3.x branch, over from the CCK Gallery queue. I don't know if this is something Node Gallery supports already. If so, close! If not, might be worthy of consideration for Drupal 7.

Tagging...

Ugh, sub galleries/nesting...

Well, it can be done right now, but needs some patience - see #509234: Gallery hierarchy, nesting: Gallery2, Acidfree -like galleries.

While I don't want to write code to do this natively in 3.x -- it will take a *huge* amount of effort to change the code to support this natively, it should be made easier to do with add on modules.

We'll keep this open so that once we get things stabilized in 3.x, we can find a better and easier way to do this. Since we'll be all views, it should be fairly easy to add a nodereference field to the gallery, or use nodehierarchy and it's views support.

subscribe.

This is a key component for my site and I'd love to fully implement Node Gallery when it's easy to achieve!

I don't know why, but I thought about this today.
We don't have a release yet, so the time is now for changes. We are digging deep in the relationships and schema anyway, so why not discuss this while we're at it. I fear that, if we are unlucky, it might be too late to incorporate this when there is a first alpha or beta.

I'd like to start a discussion about this, so we're clear about the pro's and con's.

Possibilities to implement nested galleries

As it's typical for Drupal, there are endless possibilities how this could be implemented. The question is, which is the right one? And is it even desirable?

Here are some crazy ideas, without judging the sensibility of the approach in question. Just to start the discussion.

• Implement this on our own, with an additional table (gallery2gallery) and another embedded view
• Add more built-in support for taxonomies
• Put a node reference in the gallery type to reference other galleries
• Replace our relationship completely with node references (one on each type)
• Replace our relationship and content types with only one type with node reference (referring to itself to build a gallery)
• Use taxonomy instead of gallery type
• Use or build in support for an additional module, like noderelationships (link), reverse node reference (link), referential integrity for cck (link, node hierarchy (link), node referrer link), or any other of the gazillion modules in existance.

Some food for thought to kick off the discussion

So it should already be possible to arrange gallery nodes in a taxonomy tree. You can also generate a view for terms to browse this, can have related terms, and stuff like that. It's just not used from the start.
The question is, are there any problems with this approach, what are the pro's and con's?

• We can't have images and galleries in the same containment, so it's not really nested galleries, but more categorized galleries
• A big pro: We don't have problems with referential integrity. We do not need to traverse tree's for cycles, etc.
• The module is lean and mean at the moment
• It's perhaps not so easy for Drupal newcomers
• The back link to the taxonomy from the Gallery or image is probably not very obvious

What's you opinion on all this?

I think it's easy for new users, we will need some new docs, but it's not difficult stuff,
You(developers) are the ones with the difficult part..
We(users) just need to know what is needed, what is available to use(features/views) and how do I turn it on.
Assuming the module is packaged with smart(works for most folks) defaults to get users up and running easy. Good to go..

nested galleries should be easy now with the awesome views integration. A 'Tags' vocabulary can go a long way for small stuff.
I suppose there could be a (text field/select list/auto complete) for a parent gallery.. actually just a text field(not an image gallery). It could be enhanced ... choose a 'cover image' for the 'parent gallery' from the included 'sub galleries'.
....This is how I would typically use it....

parent gallery: 2010 Colorado Vacation(cover photo only) - 4 albums
sub gallery: In the mountains(full gallery) - 30 photos
sub gallery: At the airport(full gallery) - 22 photos, 1 video
sub gallery: The train trip(full gallery) - 15 photos, 2 videos
sub gallery: Trip videos(full gallery) - 5 video clips

yes, it has videos.. most cameras today take videos and photos.

select list is good idea, when user create/move his photo/album to another location, he can choose from selectlist where to put it on.
I liked this when I used Gallery 2.

Someday in the future, it could be done by javascript too - when you catch photo/album and you will move it and release it over another album, it will be moved into it.

My $.02:

I really wanted to do this in 3.x, and while I'd certainly take patches, I personally think 3.x has had enough feature creep. I'm really itching to get a alpha release out the door.

That being said, this is worth going over, because the minute 3.x stabilises, we need to start thinking about 4.x with D7 support. If you think 3.x is a big change, wait for D7+media module.

I really wanted to use nodereference, but the biggest problem is that nodereference is great for one way relationships (what gallery is this image a part of?), but not for the other direction (what images are in this gallery?). Sure, you can do SQL to get around it, but what's the point of using nodereference then? Plus, by using our own tables, we can use indexes to make sure our queries stay fast.

If I were to do this in 3.x, I'd simply add a column 'parent_gid' to the node_gallery_galleries table, and that's all we'd need as far as storage needs. Every gallery could then have an optional parent gallery.

But, this is a game-changing feature. There's code all over the place that assumes that the contents of a gallery are all images, and it would take some time to fix all that.

I *really* like the nodehierarchy module - it is essentially a replacement for the book module when you boil it down enough. I was pretty close to looking at making that a dependency, but decided I had bitten off more than I could chew with 3.x development anyway. I thought we were going to have a team of devs cranking on it, but everyone got busy with paying jobs (no hard feelings btw, I'd do the same).

One thing that we haven't really discussed: we had a difficult, but possible way of doing this with 2.x as described in the link above. 3.x plays much better with other contrib modules than 2.x ever did, so there's a very real possibility that we can create a simple recipe of modules+config that will do this with 3.x. If this is possible, I'd like to just document it (maybe even ship a view that does the work if the right modules are enabled) and try to get 3.x out the door ASAP.

D7+media will likely be a complete rewrite I have a feeling, so it would be a great place to natively support nested galleries.

Of course, this is all just one man's opinion. I'd love for someone with a bit more free time than I to see what they could cook up with 3.x and nodehierarchy. I'm very open to discussion. I'm even more open to patches :)

Mhm, justin, are you sure with the media integration for 7? As far as I know, Media already contains an integrated gallery. I'm not sure about the role of NG then.

I agree with the thing about nodereference. That's what I meant with referential integrity. I only wanted to list some possibilities.

There's code all over the place that assumes that the contents of a gallery are all images, and it would take some time to fix all that.

Well, galleries would be completely out of the View, because they are gallery nodes. I think we'd display them seperately on our own (it could be a view for the node type "gallery" that we embed on top of the gallery output). I don't think it would change any of the current code.

Hi
However, if nested albums will be done only in D7, probably it could be done partially in d6 because user's album - when each user will be have his own album, other albums will be inside this.
But maybe you can do it (user's album) another way, so it will be not actually album, and no nested albums will be needed...

Mhm, justin, are you sure with the media integration for 7? As far as I know, Media already contains an integrated gallery. I'm not sure about the role of NG then.

To me, the quick and dirty way to do an image gallery is to attach a bunch of images as fields to a node. The right way is to do it the way NG does, where Galleries are nodes, and each image is a node. It just opens up a whole new world of possibilities. The included gallery feature in Media is (if I understand correctly, I haven't actually looked) the former. One of the Media devs actually posted to an issue recommending that we look at Media module.

That said, it's certainly not set in stone. It just looks really cool :)

Well, galleries would be completely out of the View, because they are gallery nodes. I think we'd display them seperately on our own (it could be a view for the node type "gallery" that we embed on top of the gallery output). I don't think it would change any of the current code.

Ahh - I see. Sounds like a perfect use of a Views Attachment to me. So, we've handled the output and the storage, how would we handle the UI to allow users to add a gallery to another gallery?

A dropdown on the Gallery form could be a start. I'd imagine a foldable list tree in the end, which is quite easy to do with jquery.

Oh man, i'm dazzled this isnt currently possible with Node Gallery, such a powerful module.

+1 for this!

So, I'll have a look at this again. Node Relationships needs jQuery_Update and jQuery UI 1.7.x., and Reverse Node Reference needs mysql 5.1 which are both dealbreakers for me. Nodehierarchy 2.x looks interesting, but doesn't have a release yet. This leaves NodeReferrer, Taxonomy on Gallery type and a completely custom solution. I'll start with the custom solution, because the others don't seem like a perfect fit. Let's see.

Well, here is a patch of hell that enables tree structures of galleries.

This needs thorough review and discussion. I really hope we can get this in, though, as some of my sites urgently need hierarchies (not my fault).

What should work:
- optional selection of parent gallery on create and edit forms
- above respecting hierarchy
- above respecting potential loops
- tree to select gallery in manage images form
- display of subgalleries on gallery full node view reusing existing summary displays
- deletion of a gallery triggers deletion of all children galleries
- filter & argument implementation for parent gallery

What definitely needs work:
- Proper styling of subgalleries
- Proper breadcrumbs for gallery hierarchy

What would be nice:
- support devel generate for testing (this is just a matter of setting a random parent gallery)
- support hierarchical select for choosing the gallery (module integration like others)

I want reviews in this stage, so I don't spend too much time on something that will never be included in the module.

Greetings
scroogie

Reroll after last quick fix.

@scroogie - thanks for the patch. Yikes that's big. Let's talk about the big picture.

I really want this feature, and so do a fair amount of other people. However, more important to me and to the majority of people is the progression of NG3 - we've been working on it for close to a year now, and it's almost ready to start alpha/beta testing.

I'm worried that the inclusion of such a large patch this late in the game would introduce new bugs that would delay things by weeks or months.

Now, I haven't even looked at any of the code, so I don't know how feasible this is, but have you thought about making this feature it's own module? We could include it as part of NG if we had to, but ideally, it would be it's own module just like node_gallery_access.

If you need help with your CVS application, I'd be more than happy to help with that.

Again, I haven't even looked at the content of the patch yet so this may not even be possible. However, from a design and release point of view, a separate module makes a lot of sense here.

Thoughts?

Phew, that's a good question. At this point, I don't know if it's possible. It should theoratically, as I tried to make it as unobtrusive as possible. But I think it will make some things a bit harder to do. I'm worried that it get's completely lost then.

In places where you had to modify existing functions, I'd be completely open to exposing hooks in NG so that you can easily get to the data you want.

I'm worried that it get's completely lost then.

What do you mean?

Well, I'd have to refactor the code first to get it into an external module. And if I'm not fast enough, a lot of changes will render the patch useless. I'd also basically loose the support of you and the other maintainers, so noone would notice breaking the hierarchy module.

On the other hand, it would allow me to do some more fancy stuff like an interface to move images between the hierarchy levels, using panels instead of embedding, a gallery navigation block and so on, because I don't have to worry about overloading NG3.

It's a tough decision. I'll think about it.

So for now we postpone this. The feasibility of a submodule that provides this without weird code constructs is yet to be proven. Perhaps this will find a way into NG3 during the next release cycle, or perhaps the contributed module will be reanimated. We will see.

subscribe

subscribe

Here is a reroll as a submodule, based on our work done last year on Git. It only needs a small patch to node gallery, which actually just solves a bug in our default views (overridden argument options). It only provides very basic functionality, but it works for me.

wau, I can't wait to test it, probably next week, nice job, scroogie!

I'd especially like feature requests with a description of eventual UI, so I can plan the further evolution of the module. I'll most probably create a project for this, but as long as it lives in this thread, we can collect it here.

didn't test it yet, but one thing why I would like to use this, is that I would like to have 2 global galleries "site event" and "user albums" and by default user created albums will be in user albums (galleries/user-albums/username/name of his created album), but they can move it (if these are photos from site event and they have permissons to move it from his user album) into site events album.

If someone could review just the patch, I would create the project for the submodule.

I tried your last patch, I looks really good but...the subgallery I created, displays also among the other galleries on the main Gallery list page.

In that case the View modifications don't get picked up. Which version of Views are you using? I developed this on Views 2. Did the patch to Node Gallery apply without errors?

There are no errors, and I am using Views 6x-2.12. I will have a look at the views, probably I have made some modifications.

I hope that justintime and me will have some time this or next week so we can coordinate the next release. I'll move the code to a proper module then, and start investigating Views 3 compatability and customization issues. I already found an obvious bug in the above code. It uses the wrong dropdown (not the hierarchical but a flat list) because of a typo. But for now the release has higher priority.

What is up with this issue? Does this still needs testing?
Instructions?

FYI: Stumbled upon a forum issue asking for this feature. Seems to be quite popular...

@dddave - I just committed the patch to NG3 in #27. You just need to get the latest dev, and then download the tar.gz @scroogie posted in #27, which will give you a new module to enable.

@scroogie and I never got a chance to hook up, but since the great migration, this would make an excellent sandbox project.

Ok, this is basically working but definitely needs some work.

What works well: Assigning a parent gallery from the edit screen of a given gallery. So the basic process works.

What needs work: The views integration
1. I don't think subgalleries should appear in in the general galleries overview. They should only be visible within the parent gallery (at least as a default).
2. How the subgalleries are displayed within the parent gallery. I attached a screen shot. In this screenshot "G1" is the parent gallery and "Subgaltest" and "Unnamed Gallery" are subgalleries. (Note that you can see the problem described in1. also in this pic as "Unnamed Gallery also appears just above "G1")
Directly under the two subgalleries are the normal pictures of G1. How to tell the difference? Shouldn't there be a visual difference between subgalleries and normal pictures?

I think i am using an untouched NG3 dev version here where the views are left untouched. I am using Views 6x-2.12

Hi ddave,

thanks for testing this out.

1. This is a bug. They should not be displayed in the overview. We are dynamically adding an argument to the View that should default to not displaying subgalleries, which is a great idea that justin came up with. The modification of the view most probably failed. If this is a Dev instance, can you try uninstalling Node Gallery and installing it again (*with* the patch)? There were some errors with the default views, namely some displays were overriding the default arguments although they did not need them.

2. The theming is completely untouched! I hoped that we could start a discussion and someone would step up with a nice design mockup. ;)

re #39

I set up a fresh install with the latest NG3 dev and the problem persists (or did I misunderstand you?).

Other thoughts:
1. How do we control who is allowed to create such subgalleries? Permissions?

2. don't we need to modify the image count for galleries containing subgalleries? E.g. something like "contains 20 images in three subgalleries"

3. Is the term subgallery a good choice?

Good questions.

1. We can either use the "Upload to gallery" permission or introduce two new permissions: 'Create subgalleries of own galleries' and 'Create subgalleries of all galleries'.

2. Probably true. This will be quite complex though. I'll have to take a closer look at the views field.

3. I don't know. I'm not a native speaker either. If there are other propositions I'm open to change.

I will maintain the module seperately, once we reach stable ground with NG.

my 5cents

there could be some permission if user can move albums into global (offcial page) galleries and it's subgalleries (out of his personal gallery)

Justin, is it possible that the commit was incomplete? If I compare the patch in http://drupal.org/files/issues/ng3-hierarchies.patch to the commit in http://drupalcode.org/project/node_gallery.git/commitdiff/f012041ccd6039... I see a lot of changes that weren't applied.

I hope its okay that I commited the rest to the repo already. I'll create a project on d.o for the submodule, I hope everyone from this thread will help with feedback there!

How does one assign a gallery as a subgallery? I see nothing on the gallery edit form... Using 6.x-3.x-dev (2011-Mar-26).

Thank you (sorry for re-opening, please close again when applicable)

There is a typo in the patch, which makes it call the wrong function to render the galleries dropdown. I want to create this as a seperate module when NG 3.0 is finished. I hope for some more feedback on the latest NG alpha.

Could you specify what needs to be corrected in order to make it work for the time being?

The module now lives here: http://drupal.org/project/node_gallery_hierarchy

It is still far away from being ready, but it's a start. I will need help from other volunteers to finish it, so please step up. :)

What is currently working:
- a widget on gallery creation and editing to choose a parent gallery
- the overview and gallery views show resp. hide the subgalleries
- the breadcrumb is hierarchical
- a page on /admin/content/node_gallery_hierarchy to reorder the hierarchy just like menus or taxonomy terms

What is missing:
- it does not yet cope with different gallery types correctly
- the styling / theming! here I will need most of the help. Please submit your ideas.
- a navigational block for the hierarchy

Are top level galleries selectable via views?

Yes, top level galleries have the parent property set to 0, so you can select all top level galleries with a filter in Views. Or what are you asking?

Yes, that was my question, thanks! :-)