I'm going to start work on creating image galleries with Views, like on 5-2.
Like in 5-2, this is going to be composed of two things:
- a gallery style plugin
- a default view.
Some notes:
- sort in galleries by creation date and sticky (#340523: How to choose the gallery cover image?)
- in 5-2 the child gallery list had to be coded, as views only supported node lists. With Views 2 I reckon we can make the child gallery list with a view too. Trick is just combining the two on the same page.
- need an option to hide empty child galleries (#234845: Image gallery. Add option to hide empty galleries)
- empty text needs to be clever enough to know that if there are child galleries, the empty text doesn't apply.
Some questions:
- should gallery views sit alongside coded ones (as in 5-2), or should we make image_gallery module depend on views?
- I think the gallery style plugin should go in image module, so users can create their own galleries on their own criteria (eg user galleries) without installing image galleries (they might not want the taxonomy approach).
Any other thoughts, questions, ideas?
Comment | File | Size | Author |
---|---|---|---|
#32 | views-image_gallery_405456_32.patch | 61.47 KB | joachim |
#26 | image_gallery_views_405456_26.patch | 59.22 KB | joachim |
#19 | image_gallery_views_3_B_reroll_unix.patch | 58.44 KB | joachim |
#18 | image_gallery_views_3_B_reroll.patch | 60.03 KB | joachim |
#14 | image_gallery_views_3_B.patch | 60.03 KB | joachim |
Comments
Comment #1
Jean-Philippe Fleury CreditAttribution: Jean-Philippe Fleury commentedsubscribing
Comment #2
joachim CreditAttribution: joachim commentedHere'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
Comment #3
sunBoy, what's that? ;)
I've created a stub file and the directory for you.
Comment #4
joachim CreditAttribution: joachim commentedHeh 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.
Comment #5
joachim CreditAttribution: joachim commentedJust 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.
Comment #6
joachim CreditAttribution: joachim commentedI'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.
Comment #7
scroogie CreditAttribution: scroogie commentedJust to understand the problem a bit better. Why can't it retrieve nodes of child terms with the relationship? If you use taxonomy_select_nodes I think it also retrieves nodes of child terms if you change the depth parameter.
Another thing, if you show the number of nodes in that term, taxonomy_term_count_nodes doesn't count nodes of child terms afaik.
Comment #8
joachim CreditAttribution: joachim commentedThe 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.
Comment #9
joachim CreditAttribution: joachim commentedHere'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.
Suppose our sort criterion for the cover is the node title in alphabetical order. What cover image will gallery 1 have?
The first node by name is D.
The first node by name is A.
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.
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.
Comment #10
NancyDruHere's my two cents worth: #426696-5: Replace "Posted by"
Comment #11
joachim CreditAttribution: joachim commentedViews 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.
Comment #12
sunimage_gallery_legacy it would be. If at all. Views is the future; custom code not.
Comment #13
joachim CreditAttribution: joachim commentedHere'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.
Comment #14
joachim CreditAttribution: joachim commentedSlight 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.
Comment #15
Flying Drupalist CreditAttribution: Flying Drupalist commentedAny chance the features in #9 can be generalized for other things aside from image gallery?
Comment #16
joachim CreditAttribution: joachim commentedSure.
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.
Comment #17
asb CreditAttribution: asb commentedHi,
thank you, Joachim, for starting this initiative!
I tried the patch from #14 from within the image module's folder against the latest 6.x-1.x-dev (that's what the "Version" tag of this issue says) and against CVS HEAD (that's what #13 says), and the patch fails in both cases:
OK, CVS HEAD might have evolved in the past few weeks, but please give us something to test if we are supposed to test ;) Or maybe you could branch into 6.x-2.x-dev and roll the patch against 2.x-dev?
A few general & personal comments:
Greetings, -asb
Comment #18
joachim CreditAttribution: joachim commentedPatches 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?
Comment #19
joachim CreditAttribution: joachim commentedArgh, yeah line endings are Windows. Netbeans fail.
Here's the same patch unixified.
Comment #20
joachim CreditAttribution: joachim commented#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 :)
Comment #21
sunAwesome! Can you also re-roll from the proper base/root directory? :)
Comment #22
sunAdditionally, #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.
Comment #23
joachim CreditAttribution: joachim commented> 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?
Comment #24
sunThe base path should be
contributions/modules/image/
already :)Otherwise, people have to use
patch -p3
(or similar; to strip 3 leading components from the path) to correctly apply it.Also, it seems that this patch only adds to the game...? If so, let's quickly agree on
a) whether this should be part of image.module or image_gallery.module ?
b) whether to commit this to 6.x-1.x or a new 6.x-3.x (the latter would mean image.module for a)) ?
Looking at the views handlers contained in this patch, it probably makes more sense to tie it to image_gallery.module for now. For 3.x, we'd be able to re-consider what to do with that.
So, if you agree, do you want to commit it? :) (Reminder: do not forget CHANGELOG.txt ;) )
Comment #25
joachim CreditAttribution: joachim commentedI'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.
Comment #26
joachim CreditAttribution: joachim commented> 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.
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.
Comment #27
sunYeah. And even the remaining taxonomy handling in image_gallery is questionable then. :)
Comment #28
joachim CreditAttribution: joachim commentedYou 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.
Comment #29
vronkdaut CreditAttribution: vronkdaut commentedI have Drupal 6.13, Views 6.x-2.6, Image 6.x-1.0-alpha5 installed.
I miss (and would very much like to use) the default views promised to be provided by the Image module (as in 5-2) now integrating with Views 2.
All I could find confused me a bit more:
1. the CHANGELOG.txt says:
Image 6.x-1.0-ALPHA5, 2009-07-11
... #220295 by joachim: Added Views 2 support.
as does
2. http://drupal.org/node/220295 >> closed
But
3. I don't see any respective entry on http://drupal.org/node/516630
4. I can't find anything like: views_defaults.inc
as I found it in one older patch: http://drupal.org/files/issues/image_gallery_295293.patch
image_gallery.default_views.patch.txt
5. the image_gallery.views.inc in modules:image/contrib/image_gallery/views ist quite empty
6. http://drupal.org/node/207216 says this works only for 5-2 and there is basic patch for 6 but...
These is all just hints (peaces of a puzzle) I could find, I don't really know how important they are...
So the problem restated as question:
How can I get the default views ('image_gallery' & co) the image module suggests to provide to allow configuring the galleries with Views?
Thank you for any clarification.
regards
matej
Comment #30
joachim CreditAttribution: joachim commented@vronkdaut: we have views support in image but not yet in image gallery.
Comment #31
Hetta CreditAttribution: Hetta commentedIs that marked as "absolutely necessary" in the upgrade path for image 1?
Comment #32
joachim CreditAttribution: joachim commentedOn 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.