Collaboration with CCK Gallery for Drupal 7?

Wow, that's scary. Not only was I browsing your issue queue just yesterday... not only was I going to use your CCK implementation as a reference for resolving #422878: Node Gallery Support for CCK ImageField, but I was going to ask kmonty (the lead maintainer) if I could try to recruit you to help us out and merge the CCK extendability of your module into the custom features of ours.

In the end of this month, I was going to branch a DRUPAL-6--3 branch in CVS and start trying to get our custom image storage replaced with CCK. Once that's complete, the next most-requested feature for our module has to be #477472: Integrate with SWFupload/Image Fupload.

Since CCK will become fields in D7 core, the thought was that this 3.x branch will be a step towards D7 compatibility.

In the last couple of months, we've lost our maintainer wilson98, but he hadn't committed any code for months before that anyway. It was all kmonty up until then. I came on (my first module experience) around Christmas, and we just recently picked up another co-maintainer, DesignWork (who appears to be quite the JQuery/UI rockstar). My specialty is more in backend code, while kmonty seems to be pretty well balanced in both (feel free to correct me anyone).

As for a list of what CCKG does that NG doesn't, I haven't tried out your module yet. If I was asked to give a 40,000 foot view description of the two, I would say that Node Gallery does more and has more features, but has more bugs and is less configurable. It looks to me that CCK Gallery aims to be more of a "glue" module, and gives the end user all the power they need to tweak it.

How would you feel about helping out with that 3.x branch? You've done the core of it once already ;-) Once we're done with a stable 3.x branch, we could start a DRUPAL-7--1 branch from there.

From http://drupal.org/project/usage, it looks like your module has a decent following - I don't see why we couldn't make everyone happy with one ubermodule.

I for one, am very excited to be a Node Gallery developer right now. We have some super helpful users, and a very specific direction to go in. Your post just made my day!

Eek! you guys should check out the media project. We're building media as a fieldable entity. It's very rough right now, but will be for real very soon. I feel quite strongly this will be the ideal platform to build a gallery app on top of (or port an existing one to).

I will be happy to help get you started here and give CVS access to anyone who is serious about doing work in this area.

All the best,
Jacob

Jacob - I get aaron's RSS feed, so I'm a little familiar with the media module but haven't used it. The use of streams would absolutely rock - our module wouldn't care if an image lived on a local filesystem, an Amazon S3 bucket, Flickr, or whatever. Am I right in assuming that's going to be D7 only?

If so, we can D6 version 3 out with CCK imagefield, and look into media for the D7 branch.

Hi guys,

this looks like a big game now.

If I got it right we first go to Imagefield upload, than finish the bulk-upload. And in a D7 branch we integrate media. OK I will help. Just untill monday I'm not able because I'm swamped with work.

PS. Justintime I stoped working on the bulk-upload because I have some problems with the image node image.file creation. But I will return next week.

@greg.harvey - perhaps you can build a list of features that your module provides them that current Node Gallery doesn't (save for the CCK implementation which will be addressed RSN)?

We have views integration, it just sucks ;-) Seriously - #625528: Views completely broken: Using views field "Cover Image" etc. breaks your view, GID returns wrong data etc. was created by kmonty.

It's actually the first thing I was going to set out to do, but as you already know, views integration gets so much easier with CCK, it didn't make much sense to refactor the views integration twice so close together. So, I've put it off until I take a crack at CCK. If for some reason that should fail, then I'll rework the views into the existing 2.x code.

I definitely support combining efforts into one module. Both modules have a decent user base, which is a strong indicator that a great gallery solution is needed for Drupal. That said, since both modules attempt to do the same thing and since we are moving towards a similar strategy for implementation CCK/Fields, it makes sense that we focus together.

As has been previously mentioned, I am very busy with work right now so my time for this module is limited for the next month or so but I am not walking away from it... just taking a break.

I also believe that once 3.x is ready for a dev release (or potentially alpha), we should close out all the 2.x and 1.x bugs and support questions from the queue, as, hopefully, most of those will have been answered.

Hi everyone.

I might be a bit "offline" this week, my 2yr old son has RSV and is at the hospital with his mom - I don't get to stay the night at the hospital due to my bad snoring. I knew it would come in handy someday ;-) Before anyone asks, he'll be just fine -- just needs some O2 and monitoring, he'll likely be out Tues or Wed.

Also, we need to figure out how to map out our TODO's for 3.x - see #687848: Status of Node Gallery 3.x

@greg.harvey - I granted you cvs access

Hi guys

This is great newws about your cooperation.
I just want to let you know about views gallery
It is using views, cck, imagecache... so maybe you can reuse some of it's code or to inspire yourself there
http://drupal.org/project/views_gallery

have a nice day!
Igor

@Igor - ironically enough, I was using eaton's article posted on the front page of Views Gallery to try and build my own before I happened upon this module. Node Gallery Access was what sold me on coming over to Node Gallery. I'll definitely browse through KarenS's module and see what goodies are in there. OG support is kinda interesting...

Hi Greg, Hi Justin,

I would propse that we use views for listings etc. But I would prefer if we have a module that dosen`t depends on views. As I know there are a lot of users that do not have the time or skills to use views. So if we want to have a module that is only for "advanced" Drupal users, we use views.

But a lot of user just want a easy to use gallery module. Just install it and maybe some other modules and start using it.

Cheers

Dirk

Dirk, I think you are wrong.

To enable views module is not harder as enable cck/imagefield module. Using views will be done on the backend side of node gallery, you will probably don't need to set any views manually. (only if you will be want to customize it)
3.x version will be based on combination views and image fields (in views) so it will be really easy to show images in gallery, etc.
This is IMHO the point of this new branch.

If you want to have node gallery without views, you can use version 2.x. where views is not dependency. However, views + cck is the future.

Yeah, views is the future. I think it makes more sense to leave the views in code and people, if they want, can override the views in the UI.

Just a note, I have created the DRUPAL-6--3 just now. If you're a user, please don't start using that branch, as the odds are 100% that things will break quite horribly for awhile before things get a little stable. When things are stable enough to have people start testing, we'll put up a release on the project page.

Sounds great! I'd be willing to help out a bit as well. But where to start?

This is a useful component to use for any kind of Views gallery: http://drupal.org/project/views_fluid_grid

Also, if you've got a hierarchy, this is a generalized version of the child gallery stuff from Image module: http://drupal.org/project/views_catalog, though needs reworking for Views 3.

I lose track of all the different gallery implementations they are and how they work (a thought: do we have a module comparison page for these yet? We really should!).

I guess this is a design question. I would really like it, though.

joachim: Does views_catalog allow for arbitrary nesting (a real tree structure)?

@scroogie - NG3 is there in CVS now, but it's very bleeding edge and outright broken in quite a few places. I wouldn't recommend even checking it out unless you're super-curious and have a spare Drupal instance sitting around that you can break horribly ;-) Once it's ready for some end-user alpha testing, we'll put a dev release up on the project page (2.x will still be the recommended version). We'll update this post and create a new thread announcing the release.

justintime: I think you misunderstood me. I meant that I'd be willing to help developing, not end-user testing. ;)

Yipe, I just love breaking things.. @ scroogie, looks like your right on time.

@scroogie Views catalog tries to do the same thing as image_gallery, which is a full tree. A few more things need to be done -- see the project page, the issue queue, and comments in the code as a last resort.

subscribing

I know it's very early to ask, but will there be an upgrade path to ver 3.0? I'm really keen to see Node Gallery use ImageField, but I need a gallery solution ASAP. If I start using Node Gallery now, will all my Image Nodes automatically be converted to use ImageFields when I upgrade?

Thanks to all the maintainers for their hard word, btw.

@H3x: most of the core features are in place in 3.x now, and I'm actually working on the upgrade path right now. I'm a bit stumped on one thing - how to add an imagefield to an already existing content type. However, even if I don't figure out how to do that via upgrade code, we can have the site admin do that part for us, and then upgrade the images after that's done. Right now, I don't see any reason why we couldn't accommodate everyone there. I created #715874: Upgrade path from 2.x to 3.x to track the progress of the upgrade path - subscribe over there if you'd like to stay updated.

As noted in the issue you posted in the Views Gallery queue, Views Gallery is specifically designed to be a simple solution that builds on existing modules and just adds a bit of glue. I think there is room for both a solution like this and a more robust solution specifically designed to do complex image gallery handling. I also am getting ready to create a feature for this, using the Features module. Since Views Gallery is mostly glue, it is an excellent candidate for a feature. Almost everything in it is something that Features does -- creating a couple content types and views and setting up some variables and permissions.

The difference is that Views Gallery is 14KB vs Node Gallery which is 42KB, the difference between a lightweight feature that builds on a number of other modules that many sites would already be using vs a robust solution designed to solve a specific task.

subscribing

hi guys :) I'm over from Fast Gallery (http://drupal.org/project/fast_gallery)
greg.harvey was contacting me via twitter just today.

Well, Fast Gallery uses a completely different approach, but maybe we can put some concepts into this. Oky, let me summarize some of my ideas and plans for fast gallery:

State/Concept as of now:
- Build galleries based upon folder hierarchy. You can setup multiple galleries.
- Folders are synced with the gallery.
- Swapable storage. there is one storagemanager and there can be different storages. Right now there is only a default storage implemented (two tables in the db)
- Support for Lightbox (i'm actually looking into a more portable front-end -> some swapable version, based on interfaces, would be best).

Ideas and Future:
- Some public API over REST, that makes integration anywhere else easy. Kinda like Flickr and YouTube.
- Plugable Front end
- Better plugability of the backend

Here's a quick introduction of fast gallery I just wrote: http://www.rapsli.ch/fast-gallery-introduction-developers

Right now I don't really see how Fast Gallery would fit into the whole node concept, except for the whole plugability concepts. I mean, I was actually planing on having a node storage, that would save the images as nodes... but not work has been done sofar.

So these few new ideas probably need some time.... ;)

Last but not least: In my opinion the gallery must just be easy to use and fast to setup. No big dependencies in the core version. ... but a lot of integration with other modules that just make it more and more powerful.

What about http://drupal.org/project/storage_api ?

looks really cool. Somehow I got caried away today in the train and started on writing a plugable frontend for fast gallery. In the next release it will be really easy to have any kind of front end. This kind of architecture should definetly be in some bigger gallery solution.
I'm not going to take lead with this gallery, but I'm willing to help with concepts.

If you're already talking about pluggable frontend / backend, you should perhaps have a look at GalleryAPI: http://drupal.org/project/galleryapi
It sounds like their goals. I never had the time to look at the project, though.

well, I guess I should... but having a plugable architecture makes the system much more maintainable, that's actually the reason I built it plugable.

Let us look into the future... ;)

Cleaning up this issue. It doesn't seem like this is going to happen, and the D7 version is already in production.