Galleries made with views

Here's a first step patch, which adds the fields we need to create image gallery lists.

Because I can't figure out how to get a whole new folder into a patch, it's in two parts :(
- the patch on image_gallery module
- the views folder.
- 3rd file is a demo view showing an image gallery list.

Before we can create an actual list of image galleries that works like the current one, we need this patch on views: http://drupal.org/node/408180 so we can list top-level galleries.

There's also a question to be resolved for how to build galleries:
a) page callback embeds 2 views
b) node view + hook_views_pre_view

Next steps:
1. row style plugin for gallery lists
2. style plugin for gallery image lists
3. default views

Heh I said it was step 1 ;)
It's because I'm working on this patch for a development site, which is on the latest alpha rather than CVS, so was marking my sections to move them to a CVS checkout...

Here's a complete patch.

Note that the demo view in #2 above will need altering for your image gallery vid.

Just noticed http://drupal.org/node/357488.
There's a case to be made for the cover image to be the first in the gallery list. That shouldn't be too hard to do once we have a built-in view for the gallery images -- just get that view's query, add a limit to get only one node, remove all fields bar the image.

I've done a lot more work, but need tidying up before I can roll a patch.
Here's a bit of a progress report for people to consider use cases:

First, we need to distinguish between a gallery, which shows images (ie a node view) and the gallery *list*, which is a list of galleries (ie a term view). A complete gallery page shows a gallery list above a gallery. (If anyone can come up with better unambiguous terms, I am all ears!)
So ultimately I am working towards two views that will work together to produce the complete gallery page.

A gallery list shows terms with a cover image for the gallery, and it's this that I've been concentrating on the moment as it's by far the most complex thing (and also where people seem to want customization).

There are two possible approaches:

Relationships: I've defined relationships from the term base to nodes. These give us a node for the term. So, for example, we can say "for this gallery, give me the most recent node". Once we have that relationship, we can add any node field. So the image field from the patch here http://drupal.org/node/220295, for example, or the node title, or the node author, or anything else. This is very powerful. But there is also a limitation: the node only comes from that gallery, not from subgalleries (which is what has been requested here http://drupal.org/node/237284 by the way).
I've defined three relationships so far: most recent node, oldest node, and first node by title order.
This is a fairly complex thing to do, as the relationship join requires a subquery. It's technically possible to do things like filename, but that makes the subquery considerably more complex.

Regular fields: this is simpler, but less powerful. Fake fields can run whatever code they like in their handlers, so we can ask taxonomy module for all the child terms of the gallery, then run our own separate query to get most recent image, oldest image, image by filename, and so on.

I am currently thinking we should bundle both of these approaches, and with good documentation users who want complete control over this can choose. The default view we provide should continue the current behaviour, so that would be a simple field.
Coding the handlers to inherit common behaviour will make it relatively easy for users to add further handlers if they want their own sort orders we haven't thought of.

The reason we can't get descendant terms with a relationship is because it can't be done in SQL, as far as I can tell.
taxonomy_select_nodes() builds a fairly complicated query, which we could do in a handler. But to build that query, it needs a list of descendant terms to filter on, which it gets from taxonomy_get_tree() (http://api.drupal.org/api/function/taxonomy_get_tree/6). This has to recursively call itself until it's gone all the way down the tree.
The relationship uses a subquery to get us a node ID to join onto the term base table. All we have is the current term for that row of the query. We can't pop out of SQL and use PHP because the entire Views query has to produce all rows for the entire view.
This is why it works with a regular field -- because the handler is free to call taxonomy_get_tree, get its list of term IDs, run its own query, for each row of the view.

Here's a monster patch of fun. Still work in progress, but the majority of work on fields is done so I'm uploading this in case anyone wants to test while I carry on working.

Here's is the general strategy for the work:
The gallery view will be a view of image nodes. This will be shown with a display plugin which puts the list of subgalleries above the view.
The list of subgalleries is, of course, a view itself, but a view of terms.
These will be default views.

For now, this patch has the fields that are required for these views -- to test this out you'll need to create some views yourself.

To make this happen, we have:
- a taxonomy parent argument. This allows us to filter the gallery view by term, so /image/tid/4 gives us gallery 4. This is missing in Views (see http://drupal.org/node/408180 -- but basically with Views core, /image/tid won't get us what we want, which is the top-level terms.
- a gallery count field. This is super-simple.
- A great heap of ways to make a cover image for a gallery term. More on this below.

Still to do:
- a display plugin to make the gallery + terms display
- clean up the view order handler, as the code is messy (did it on the train...)
- default views (though this depends on the patch on image module http://drupal.org/node/220295)

Cover images:
This needs a fair amount of explanation. Documentation is already partly written. When everything is ready, this will come with default views, so this is only for people wanting to customize.

A cover image is an image for a gallery, selected according to particular criterion, eg 'newest', 'oldest', 'first by node title'.
Our issue queue is FULL of requests for complex ways to select a cover image. With these all in mind, here's what I've come up with.
There are TWO methods to get a cover image:
1. A relationship from term->node. This allows you to add ANY field from the gallery's cover node (title, author, date, body, etc). The limitation however is that you can either consider just the gallery itself, or descendant galleries as a single pool to select from.
2. A field on the term. This just gets you an image: you can't get other data from the node (unless you write your own handlers). However, you can select the cover by recusring into galleries.

There are relationships and fields for a variety of sort criteria. Adding further criteria is relatively easy by adding fields -- the handlers are fairly generic.

Selecting a cover.
What do I mean by flat pool and recursing into galleries?
There are three ways of selecting a cover image:
1. Just look in the gallery itself.
2. Take all images from the gallery plus its descendants, and pick the best one from that pool of images.
3. If the gallery is empty, go into each child gallery one by one, optionally drilling further down in each gallery. (This is fairly heavy work, but has been requested...)

Example of selecting a cover:

Consider the following tree of galleries: the numbers are the term IDs that make the galleries and the letters are the titles of the image nodes.

  - 1: empty
    - 2: empty
      - 6: nodes G, H
    - 3: nodes M, N
    - 4: nodes D, E, F
    - 5: nodes X, Y, Z
      - 7: nodes A, B

Suppose our sort criterion for the cover is the node title in alphabetical order. What cover image will gallery 1 have?

Plain

Term 1 has no nodes: there is no cover image.

Flat depth 0; Recursion depth 0

Depth 0 means we don't go into child galleries: so this is the same as flat and there is no cover image.

Flat depth 1

We consider all nodes in the galleries 1, 2, 3, 4, 5.
The first node by name is D.

Flat depth 2

We consider all nodes in the galleries 1, 2, 3, 4, 5, 6, 7.
The first node by name is A.

Recursion depth 1

We find the gallery itself empty, so look in gallery 2.
That's empty too, so we look in gallery 3.
Here we find nodes, and M is the first by name: so the cover is M.

Recursion depth 2

We find the gallery itself empty, so look in gallery 2.
That's empty too, and so we go one level deeper to gallery 6.
Here we find nodes, and G is the first by name: so the cover is G.
Node A is a better fit at this depth, but we consider child galleries one by one, by weight, and we found something in gallery 6.

Views can override an existing path, the way that the taxonomy view replaces the core taxonomy list at taxonomy/term. We can do the same with image/tid.
So it's perfectly possible to provide a hardcoded gallery and also a view gallery, and if views module is present, the view takes over.

Keeping both means 6--1 stays in line with 5--2, which is the general plan.
However for 6--3 I would consider removing the old galleries, or at least stripping them down to basic options. Having two sets of code that produce the same output is no fun to maintain. Another possibility would be forking the old code into a module image_gallery_classic or something.

Here's the patch!
It's on image module root and against the current CVS HEAD.

We have:
- some fields to use in views of descendant galleries, as described in #9 above.
- a gallery display type, which embeds the descendant terms view
- some theme templates that put in the CSS classes we need.
- two default views: one for gallery terms, and one for the gallery (which embeds the gallery terms). These recreate and override the build-in galleries at the path 'image', with 'image/tid/$tid' for descendant galleries. The override is clean: if you want the built-in galleries and you have views installed, just disable these two default views.

An important warning: You will get a 'broken handler' error for the actual image field in the gallery view! This is because I'm using the field from http://drupal.org/node/220295. You DON'T need that patch to test this one! Just look at the node titles and imagine the images are there ;)

Postponed:
- using the image gallery sort order to get the cover image, requested here: http://drupal.org/node/357488. I have rough code for this, but I am running into problems with getting a query from the gallery view when it's already been built. I will file this as a new issue once this patch is in, as it will need someone with good knowledge of the view object to figure it out.
- filter to hide empty galleries, requested here: http://drupal.org/node/234845. The count of gallery items is a fake field, as it has to call taxonomy_term_count_nodes() which is a recursive function. I don't see a clean way of getting that into a views filter: some messy count subquery would be involved, probably with recursive joins. Doable, but a lot of work, and I think that a general filter for terms with no nodes would best be implemented in views, for all term views to use.

Slight tweak to the above patch -- found this broke the 'Disable lightbox for gallery lists' option in lightbox 2. Added the CSS class lighbox expects in the template.

Sure.
The handler image_gallery_handler_field_gallery_cover is just a way of getting a representative node for a term -- I did consider calling it 'representative node' instead of 'cover node' which is more generic, but it's less meaningful for this module and too wordy!
So you could subclass that to use other rules to get a representative nid, and do something else with the render function to get different date from the representative node.

The relationships you can use straight away -- though if you want other rules for getting the representative, again, subclass.

It might be worth asking merlinofchaos whether he thinks portions of this belong in views module itself.

Patches are always against CVS HEAD.

Not sure what's wrong with that patch: as far as I can tell not much has changed in CVS since then.

Here's a reroll anyway... which appears to be near-identical.
Made with NetBeans on Windows -- are the line endings ok?

Argh, yeah line endings are Windows. Netbeans fail.
Here's the same patch unixified.

#408180: 'Parent term' field needed, as parent term relationship + term ID argument can't get you terms with no parent has been committed and is in the latest Views release (2.6).
So at the very least, the ['term_hierarchy']['image_gallery_parent'] declaration can be removed from this patch as this is now in Views core; the default views in this patch will need changing too.

Also, I had a brainwave this morning about using another view to return a query for the relationship subquery... will ponder it some more, as it could make everything more generic and reusable.

Expect a new patch :)

> Can you also re-roll from the proper base/root directory?

Ermmmmm I thought my previous patches were. What did I do wrong on them?

I'd actually like to see this #470258: Groupwise maximum ('representative') relationships get into views, and then a whole load of code from the current patch can be dropped.

As for my patch creation skills.... done on Netbeans, which seems to mess up fairly consistently :(
I'm tied up with work for the next 2 weeks I'm afraid, so can't do any of the necessary work on it just now.

> Additionally, #357488: Front image must respect the sort order made me aware of the fact that this code should ideally be tied to image, not image_gallery module.

Could you explain more?
Do you mean that all the views fields, arguments, sorts, display plugins, etc that let you make gallery views should go in image, so users can make their own galleries based on their own criteria (eg, user name, whatever)?
In which case, all that would stay in image_gallery itself would be the two default views.
Let's change the patch and get it right first time around :)

As for #470258: Groupwise maximum ('representative') relationships, I reckon we should leave that for now. When that gets committed, the underlying implementation of what we have here can be changed without it affecting any views. Worst case scenario is image_gallery_handler_relationship_gallery_cover ends up being an empty child class of the new views implementation.

Attaching the latest patch anyway so I can work on it while away.

Changes from previous patch:
- Removed stuff that is now covered by #408180: 'Parent term' field needed, as parent term relationship + term ID argument can't get you terms with no parent -- the [image_gallery_parent] argument and changed the default view to use the argument now supplied by views
- uncommented a call to theme advanced help.

Index: contributions/modules/image/contrib/image_gallery/help/descendants.html
--- contributions/modules/image/contrib/image_gallery/help/descendants.html No Base Revision
+++ contributions/modules/image/contrib/image_gallery/help/descendants.html Locally New

This is a netbeans thing I'm afraid. Just made the new patch standing in the image folder.
Like you say, it'll need -p3, but as Drupal patches need a -p0 to work anyway it's no great shakes.

You mean that at that point, image_gallery merely consists of: a provided vocab, and a means of editing it with a special permission? Yeah, at that point we could say that users can just as easily create the vocab themselves and install something like taxonomy_delegate module.
Hmmmm.
Though it's not uncommon for modules to put views support into a submodule.
Not sure what best to do here.

@vronkdaut: we have views support in image but not yet in image gallery.

On reflection, not much of this makes sense moved up to image.module -- most of it is dependent on taxonomy. Sure, you can tag images without image_gallery, but it seems to me jsut as easy to install IG, and at worst get a taxonomy you don't use.

So I've moved up just the image gallery display style.
That allows the creation of galleries based on author, and so on.

Attaching the patch I committed.