I am attempting to return to Drupal after being disillusioned with Drupal 5 and migrating to another CMS. I am starting to feel that I just have terribly bad timing here, coming in so soon after Drupal 7 is released. I don't feel it's right to deploy a site right now on Drupal 6; 7 was released for a reason after all.

So I'm finding it extremely hard to deploy a simple image gallery on D7. I do not want to install someone else's product and hook it into Drupal (for my needs, that would remove the motivation to use Drupal). The Media module was suggested to me in #drupal, but it is broken and has warnings on its page that it contains bugs that can destroy your site database. I tried it in a sandbox just to make sure and it couldn't even show thumbnails of the images I uploaded. The audio and video portions are already classified non-working by the developer.

Instead I created my own "image" Content Type and created a gallery Taxonomy with one term for each gallery I wanted. Using Views, I am able to create a View page that shows the images in a gallery with thumbnails in a grid. Colorbox integrates and works as expected.

Now I need to have a front page for the gallery that, like any other gallery, shows a thumbnail from each Taxonomy Term and the name of the gallery. Views seems to be unable to do this, showing only a simple summary list of links to the Terms, which works as expected but it's not what I need.

Someone in #drupal suggested the Gallery View module, which is for D6 only. After some more conversation, this person pointed me to a patch for Drupal 7. But as I understand it, every time an update occurs on the module, I have to manually uninstall it, install the update, search out the patch again, and patch it again. I am also naturally suspicious of modules whose migration to D7 hasn't even begun. Relying on something that might be abandoned code doesn't make good business sense to me.

They then sent me to a great tutorial on Lullabot that shows how to create an image gallery with Drupal 6, using Views Attach - again, only available for D6.

I get to thinking at times like this that if I hand-coded my own gallery I'd be done by now, and that would be all well and good if I wasn't seeing people build out amazing sites on platforms like Drupal. Which begs my question: How come it's so hard in 2011 to put in a stupid image gallery? Maybe I've been spoiled by sites like Facebook, but the bigger issue is, my clients have been spoiled by sites like Facebook, and they don't understand why I can't just snap my fingers and make an image gallery. I get the desire for core to be lean, but these days, this seems as much of an oversight as if you had to install a module to post articles, and it wasn't ready until months after a core release.

I understand that some people will see this post as flamebait and take out their own issues on me, but it's not - I hope you can understand my frustration, and hopefully my words will be taken the way they're intended - as an outside voice providing some perspective on how we have the power to make these things easy without sacrificing flexibility, and we don't.

To some specific questions:

1. Should I be deploying on Drupal 6 right now?
2. What's going to be more difficult - rolling all my own solutions or upgrading to Drupal 7 when it's (really) ready? (I seem to recall I didn't upgrade to D6 back in the day because it was prohibitively complicated.)
3. My problem with Views may be because I'm trying to make one view that does everything. If I can do it with two views, how do I set them up so that mysite.com/gallery goes to the separate summary view and mysite.com/gallery/1 ... n go to the galleries?

Please excuse the frankness of my post and the frustration in it. "Pleasing, Non-Threatening Internet Forum" is not my first language :-).

Comments

Kirk’s picture

1. Should I be deploying on Drupal 6 right now?

If you want to build something RIGHT NOW and don't want to wait for module availability, build on Drupal 6, not 7. Alternately, if the module selection isn't up to your standards, submit patches to help the module maintainers get their modules to 7 or write your own and contribute them.

2. What's going to be more difficult - rolling all my own solutions or upgrading to Drupal 7 when it's (really) ready? (I seem to recall I didn't upgrade to D6 back in the day because it was prohibitively complicated.)

Upgrading is never fun, but it is do-able. Again, if you have to launch something RIGHT NOW 6 is probably the better solution.

Unless you need functionality specific to Drupal 7, there is no reason why you shouldn't develop on 6.

Kirk from Fantombox
http://fantombox.com

fuzzplugjones’s picture

Please don't take this as directed only toward you, but I absolutely HATE it when I go to a place offering software I need, for which millions of lines of code have been written, and I need the software because I can't do what you've done (otherwise y'all would be using *my* CMS) and I'm told to go in and fix the problems I'm experiencing. I know a little PHP, and I need to deploy a few sites this month and focus on their content development. I can't drop all my clients, my wife, and my other projects and learn how to program well enough to either contribute to a project as old as Drupal or create my own CMS, especially when thousands of people are already working on this one and I would be sole developer, maintainer, and beta tester.

I get it - people complain on the Internet. But yeah, if I were a programmer, I wouldn't be here complaining that the people who ARE programmers haven't finished what they're working on.

Like I said, not directed at you, this happens constantly in the open source community and it sends the wrong message - "we're going to get you 98% of the way there and then you have to learn everything we know to get yourself the other 2% of the way." And it also sends the message that the wheel must constantly be reinvented by people who just need a car.

All that being said, thank you for the confirmation that I should be developing on D6. Maybe I'll give it a spin. The worst that could happen is I get stuck the same way and sell my car for an Expression Engine license.

Kirk’s picture

I can't drop all my clients, my wife, and my other projects and learn how to program well enough to either contribute to a project as old as Drupal or create my own CMS, especially when thousands of people are already working on this one and I would be sole developer, maintainer, and beta tester.

Do you see what you're saying? You can't dedicate the time, but others should to make you happy?

It's not like module developers just build modules because they are bored and have nothing else to do. They do it because they are also site builders, designers and programmers who need specific functionality. So they take out extra time to write code and contribute it back to the community.

But now that the code isn't ready for the brand new release version of Drupal, they are somehow the bad guys. Not the guy complaining that they aren't donating enough of their time immediately.

This is how FOSS stuff works. Unless you are contributing back to the community, it is my opinion that you have no right to complain about how other volunteers spend their time.

Kirk from Fantombox
http://fantombox.com

fuzzplugjones’s picture

I was afraid you'd take it personally. No, they're offering this for free, they've worked it into their schedules, and they should expect, right or wrong, that people expect their stuff to work. Especially when it's marketed as the CMS of choice for the President of the United States, et al. For FOSS to work it needs to be usable by people who aren't hackers and don't have the ability to learn the first 98% to get the author the other 2% of the way.

Let me defuse this - it seems what you're saying is that the developers are doing what they can to get their modules ready to go with D7, and I respect that, and you've already answered the question, for immediate deployment needs, D6 is still the way to go.

I appreciate the info and I apologize for any bad feelings caused by my frustration.

Kirk’s picture

I don't take it personally, I just think you made several selfish statements.

The fact is, FOSS software is just like all other software.

If you work in an IT department, you don't upgrade your computers to a new operating system the day it is released. You first have to do testing and you also probably have to wait or at least verify that the software your company uses is compatible with the new OS.

Drupal is essentially an OS. This is exactly why 2 versions of Drupal are 'supported' at any given time. The latest version has the newest feature set but might not be ready for wide-spread use. The previous version is well tested, solid and has the most 3rd party support.

Kirk from Fantombox
http://fantombox.com

WorldFallz’s picture

I don't think kirk was taking it personally-- just explaining how foss works.

No, they're offering this for free, they've worked it into their schedules, and they should expect, right or wrong, that people expect their stuff to work.

Then you're likely to be very frustrated by foss-- quite simply that's not the way it works and it's not likely to change. Paid and volunteer work involve very different paradigms (regardless of the industry) and your statements demonstrate a fundamental lack of understanding of that. FOSS is free in terms of money (usually)-- but that does not mean completely free. It often involves a cost in terms of effort.

If this is truly how you feel, then you should look at commercial alternatives where there are teams of people paid to cater to customer needs-- foss just simply isn't it.

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

fuzzplugjones’s picture

Thanks guys, I will be abandoning this particular subthread to work out the original problem. I tend to ruffle feathers, but I mean you no harm. And your OS analogy does hold water.

WorldFallz’s picture

i can certainly appreciate your frustration. At least part of the reason 'galleries' are so complicated is that there's probably a dozen, or more, different ways to do it.

Personally, I use the lullabot method and simply embed the view (the part normally done with views_attach) into the appropriate gallery's node.tpl.php file (using views_embed_view) for the time being.

However, it sounds like you are already on a good track with the method you describe in the 3rd paragraph-- but I'm not understanding what type of view you're trying to create that's not working for you. Could you post (or link to) an export of your existing view and provide more specifics about what exactly you're trying to create?

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

fuzzplugjones’s picture

Thanks. I don't think it'll be helpful to post the view, because the view works, it's just that I'm also trying to do a "Summary" with it if an argument (Taxonomy Term ID) is not specified.

Here's what I have:

When you go to mysite.com/gallery/x, where x=the Tax Term ID of a term in the Gallery Taxonomy, it displays a grid of thumbnails. A visitor can click one and it comes up in Colorbox. All of this works out of the box with D7 and Views.

When you go to mysite.com/gallery, it shows an unordered list of Tax Term Names, and you can click on any of them and get the gallery described above.

I've done this by creating a View, creating a Page for that view, setting the path to "gallery," setting up Taxonomy Term ID as an argument, and setting it to create a "Summary, Sorted Ascending" if no argument is provided.

I should also mention that I installed the available dev version of Gallery Summary for D7 and even when I specify it in the Arguments, it does nothing.

Here's what I need:

When you go to mysite.com/gallery, it should display a grid similar to the galleries, but each item being a link to each gallery (each Tax Term ID) and show an image from each gallery.

I have not yet attempted to create a separate View that shows all the term names with images, primarily because I don't think it can be done - there doesn't seem to be a way to tell Views to pull a random or particular single node out of each Tax Term and display it along with the Tax Term name - but secondly, because they'd both have to be set to the same path, which can't be done, as far as I know. They'd need to be set to the same path in order to handle visits to mysite.com/gallery (showing one View) and mysite.com/gallery/1 or gallery/2 or gallery/3 (showing the View I've already created).

WorldFallz’s picture

i'm 99% it can be done with views-- it likely involves using a term view (not a node view) with a relationship to the nodes that have that term (to pull in the image). The reason I asked for an export, is it would have save me time recreating what you already have so I could figure out what type of view you needed. I'm curious to do it this way myself, but I probably won't get to it until later today.

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

fuzzplugjones’s picture

Okay, so here's the exported view. It's been through all the hacking to make it work, so I imagine it shows signs of wear. I'll let you have a look at it before I make the final decision on whether it's just better to go back to D6 because this is a new site.

$view = new view;
$view->name = 'web_gallery_view';
$view->description = '';
$view->tag = '';
$view->base_table = 'node';
$view->human_name = 'Web Gallery View';
$view->core = 7;
$view->api_version = '3.0-alpha1';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */

/* Display: Defaults */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->display->display_options['access']['type'] = 'none';
$handler->display->display_options['cache']['type'] = 'none';
$handler->display->display_options['query']['type'] = 'views_query';
$handler->display->display_options['exposed_form']['type'] = 'basic';
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['style_plugin'] = 'grid';
$handler->display->display_options['style_options']['fill_single_line'] = 1;
$handler->display->display_options['row_plugin'] = 'fields';
/* Field: Node: Nid */
$handler->display->display_options['fields']['nid']['id'] = 'nid';
$handler->display->display_options['fields']['nid']['table'] = 'node';
$handler->display->display_options['fields']['nid']['field'] = 'nid';
/* Field: Fields: field_web_gallery_image */
$handler->display->display_options['fields']['entity_id']['id'] = 'entity_id';
$handler->display->display_options['fields']['entity_id']['table'] = 'field_data_field_web_gallery_image';
$handler->display->display_options['fields']['entity_id']['field'] = 'entity_id';
$handler->display->display_options['fields']['entity_id']['label'] = '';
$handler->display->display_options['fields']['entity_id']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['trim'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['entity_id']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['entity_id']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['html'] = 0;
$handler->display->display_options['fields']['entity_id']['element_label_colon'] = 1;
$handler->display->display_options['fields']['entity_id']['element_default_classes'] = 1;
$handler->display->display_options['fields']['entity_id']['hide_empty'] = 0;
$handler->display->display_options['fields']['entity_id']['empty_zero'] = 0;
$handler->display->display_options['fields']['entity_id']['click_sort_column'] = 'fid';
$handler->display->display_options['fields']['entity_id']['type'] = 'colorbox';
$handler->display->display_options['fields']['entity_id']['settings'] = array(
  'colorbox_node_style' => 'thumbnail',
  'colorbox_image_style' => '',
);
/* Argument: Taxonomy: Term ID */
$handler->display->display_options['arguments']['tid']['id'] = 'tid';
$handler->display->display_options['arguments']['tid']['table'] = 'taxonomy_index';
$handler->display->display_options['arguments']['tid']['field'] = 'tid';
$handler->display->display_options['arguments']['tid']['default_action'] = 'summary asc';
$handler->display->display_options['arguments']['tid']['style_plugin'] = 'unformatted_summary';
$handler->display->display_options['arguments']['tid']['style_options']['items_per_page'] = '25';
$handler->display->display_options['arguments']['tid']['style_options']['inline'] = 0;
$handler->display->display_options['arguments']['tid']['default_argument_type'] = 'fixed';
$handler->display->display_options['arguments']['tid']['validate_type'] = 'taxonomy_term';
$handler->display->display_options['arguments']['tid']['validate_options']['vocabularies'] = array(
  'web_gallery' => 'web_gallery',
);
$handler->display->display_options['arguments']['tid']['validate_options']['transform'] = 0;
$handler->display->display_options['arguments']['tid']['break_phrase'] = 0;
$handler->display->display_options['arguments']['tid']['add_table'] = 0;
$handler->display->display_options['arguments']['tid']['require_value'] = 0;
$handler->display->display_options['arguments']['tid']['reduce_duplicates'] = 1;
$handler->display->display_options['arguments']['tid']['set_breadcrumb'] = 0;

/* Display: Page */
$handler = $view->new_display('page', 'Page', 'web_gallery_page');
$handler->display->display_options['defaults']['pager'] = FALSE;
$handler->display->display_options['pager']['type'] = 'full';
$handler->display->display_options['defaults']['style_plugin'] = FALSE;
$handler->display->display_options['style_plugin'] = 'grid';
$handler->display->display_options['style_options']['fill_single_line'] = 1;
$handler->display->display_options['defaults']['style_options'] = FALSE;
$handler->display->display_options['defaults']['row_plugin'] = FALSE;
$handler->display->display_options['row_plugin'] = 'fields';
$handler->display->display_options['defaults']['row_options'] = FALSE;
$handler->display->display_options['defaults']['fields'] = FALSE;
/* Field: Node: Nid */
$handler->display->display_options['fields']['nid']['id'] = 'nid';
$handler->display->display_options['fields']['nid']['table'] = 'node';
$handler->display->display_options['fields']['nid']['field'] = 'nid';
$handler->display->display_options['fields']['nid']['exclude'] = TRUE;
$handler->display->display_options['fields']['nid']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['nid']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['nid']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['nid']['alter']['trim'] = 0;
$handler->display->display_options['fields']['nid']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['nid']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['nid']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['nid']['alter']['html'] = 0;
$handler->display->display_options['fields']['nid']['element_label_colon'] = 1;
$handler->display->display_options['fields']['nid']['element_default_classes'] = 1;
$handler->display->display_options['fields']['nid']['hide_empty'] = 0;
$handler->display->display_options['fields']['nid']['empty_zero'] = 0;
$handler->display->display_options['fields']['nid']['link_to_node'] = 1;
/* Field: Fields: field_web_gallery_image */
$handler->display->display_options['fields']['entity_id']['id'] = 'entity_id';
$handler->display->display_options['fields']['entity_id']['table'] = 'field_data_field_web_gallery_image';
$handler->display->display_options['fields']['entity_id']['field'] = 'entity_id';
$handler->display->display_options['fields']['entity_id']['label'] = '';
$handler->display->display_options['fields']['entity_id']['alter']['alter_text'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['make_link'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['absolute'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['trim'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['word_boundary'] = 1;
$handler->display->display_options['fields']['entity_id']['alter']['ellipsis'] = 1;
$handler->display->display_options['fields']['entity_id']['alter']['strip_tags'] = 0;
$handler->display->display_options['fields']['entity_id']['alter']['html'] = 0;
$handler->display->display_options['fields']['entity_id']['element_label_colon'] = 1;
$handler->display->display_options['fields']['entity_id']['element_default_classes'] = 1;
$handler->display->display_options['fields']['entity_id']['hide_empty'] = 0;
$handler->display->display_options['fields']['entity_id']['empty_zero'] = 0;
$handler->display->display_options['fields']['entity_id']['click_sort_column'] = 'fid';
$handler->display->display_options['fields']['entity_id']['type'] = 'colorbox';
$handler->display->display_options['fields']['entity_id']['settings'] = array(
  'colorbox_node_style' => 'thumbnail',
  'colorbox_image_style' => '',
);
$handler->display->display_options['defaults']['arguments'] = FALSE;
/* Argument: Taxonomy: Term ID */
$handler->display->display_options['arguments']['tid']['id'] = 'tid';
$handler->display->display_options['arguments']['tid']['table'] = 'taxonomy_index';
$handler->display->display_options['arguments']['tid']['field'] = 'tid';
$handler->display->display_options['arguments']['tid']['default_action'] = 'summary asc';
$handler->display->display_options['arguments']['tid']['style_plugin'] = 'gallery_summary';
$handler->display->display_options['arguments']['tid']['style_options']['items_per_page'] = '25';
$handler->display->display_options['arguments']['tid']['style_options']['gallery_display'] = 'web_gallery_page';
$handler->display->display_options['arguments']['tid']['default_argument_type'] = 'fixed';
$handler->display->display_options['arguments']['tid']['validate_type'] = 'taxonomy_term';
$handler->display->display_options['arguments']['tid']['validate_options']['vocabularies'] = array(
  'web_gallery' => 'web_gallery',
);
$handler->display->display_options['arguments']['tid']['validate_options']['transform'] = 0;
$handler->display->display_options['arguments']['tid']['break_phrase'] = 0;
$handler->display->display_options['arguments']['tid']['add_table'] = 0;
$handler->display->display_options['arguments']['tid']['require_value'] = 0;
$handler->display->display_options['arguments']['tid']['reduce_duplicates'] = 1;
$handler->display->display_options['arguments']['tid']['set_breadcrumb'] = 0;
$handler->display->display_options['path'] = 'web';
$translatables['web_gallery_view'] = array(
  t('Defaults'),
  t('more'),
  t('Apply'),
  t('Reset'),
  t('Sort By'),
  t('Asc'),
  t('Desc'),
  t('Items per page'),
  t('- All -'),
  t('Offset'),
  t('Nid'),
  t('All'),
  t('Page'),
);

westie’s picture

It is currently in Beta but looks promising. http://drupal.org/project/media_gallery

Personally I can think of a number of different ways a Gallery could be implemented in Drupal but they are all different and completed depend upon the particular requirements for your project...

CTI Digital

yelvington’s picture

Now I need to have a front page for the gallery that, like any other gallery, shows a thumbnail from each Taxonomy Term and the name of the gallery. Views seems to be unable to do this, showing only a simple summary list of links to the Terms, which works as expected but it's not what I need.

Views has access to all the attributes of a taxonomy term.

Since fields are in core as of Drupal 7, and fields apply to all the entities, you can make images a property of taxonomy terms. This means every taxonomy term may have a unique image associated directly with the term -- and if it's missing, you can choose to default to a generic image (picture of a camera, for example).

This isn't exactly how a conventional "gallery" tool might work; in the more usual case you'd see the system grabbing the most recent image that's in a gallery, unless instructed to do otherwise.

We had methods of embedding views in nodes in D6; perhaps we'll be able to embed them in taxonomy terms in D7. That would allow a term to find an image from a flagged node, or fall back to grabbing one from the first or last matching node.

I don't see a direct way of doing that as of today with Views 3, but then I haven't tried all the D7 modules. http://drupal.org/project/viewreference for D7 might be an avenue to explore.

WorldFallz’s picture

ah-- this seems an even better method. I'm still working on retooling my thinking for d7. excellent suggestion.

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

fuzzplugjones’s picture

After not hearing back from anyone on this all night I went ahead and installed Drupal 6. I installed the "feature" package of the Lullbot solution, and after creating a few galleries, I went to add images and it says there are no galleries.

I started looking again and found the Gallery Assist module. Set it up, everything worked like a charm until I installed Gallery Assist Lightboxes, and none of the lightboxes work.

I don't know how much more of this I can take.

d_l’s picture

This is a wildcard idea ..

create a free account at www.drupalgardens.com

experiment with media gallery creation in D7 ..
see tutorial here http://www.drupalgardens.com/videos/217681

export the working drupalgardens prototype gallery to your main D7 site.

WorldFallz’s picture

I did spend some time trying to get this to work properly but had to get to back to real life before finding an acceptable view. I did however find the http://drupal.org/project/gallery_summary module which looks to do exactly what's necessary to get a properly formatted summary view.

However, since you've gone back to d6, i find the http://www.lullabot.com/articles/photo-galleries-views-attach (captured by the views_gallery module) method to be the 'best' most flexible gallery solution.

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

ressa’s picture

The Lullabot solution's views-gallery-views.txt file in the attached zip file (views-gallery-exports.zip - 4.79 KB) is empty.
Here it is, exported from the feature version:

$content['type']  = array (
  'name' => 'Gallery',
  'type' => 'gallery',
  'description' => 'A collection of photographs maintained by a user.',
  'title_label' => 'Title',
  'body_label' => 'Description',
  'min_word_count' => '0',
  'help' => '',
  'node_options' =>
  array (
    'status' => true,
    'promote' => true,
    'sticky' => false,
    'revision' => false,
  ),
  'show_preview_changes' => true,
  'show_diff_inline' => false,
  'enable_revisions_page' => true,
  'old_type' => 'gallery',
  'orig_type' => 'gallery',
  'module' => 'node',
  'custom' => '0',
  'modified' => '1',
  'locked' => '1',
  'reset' => 'Reset to defaults',
  'comment' => 2,
  'comment_default_mode' => 4,
  'comment_default_order' => 1,
  'comment_default_per_page' => 50,
  'comment_controls' => 3,
  'comment_anonymous' => 0,
  'comment_subject_field' => 1,
  'comment_preview' => 1,
  'comment_form_location' => 0,
  'page_title' =>
  array (
    'show_field' =>
    array (
      'show_field' => false,
    ),
    'pattern' => '',
  ),
);
Kirk’s picture

For the 'Lullabot' solution, galleries are a separate content type from images. So before you can add images to a gallery, you have to create the gallery.

I use their method frequently and have never had an issue with it.

Kirk from Fantombox
http://fantombox.com

lyosef’s picture

Thank you for expressing this issue so well. I second your opinions and observations completely. After spending weeks looking for solutions to a problem, testing modules, researching and trouble-shooting the results and still not getting what I want (which is always something I see everywhere and therefore is being done and will be expected by my client), I've still had to rig my own solutions.

A simple screenshot of the finished product would save me so much time. How do I know I want to use a particular module unless I can see it? Which is what the WEB is all about, right?

halftone’s picture

The OP eloquently speaks for many - perhaps a silent majority - of the Drupal community. Who are the lumpen proletariat of not-especially-skilled users, newbies, part-timers, SoHo's who need sites beyond what they can afford.

This is a debate that needs to be had, somewhere, and the developers will not like it. The invariable response is contextually correct but unhelpful: "this is FOSS. If you don't like it, participate, fix it yourself". It also misses a significant part of the point.

What we are complaining about is the sheer impossibility of mere mortals being able to keep pace with a moving, shape-shifting target whose complexity appears to be increasing exponentially. Each successive edition of Van Dyck's Pro Drupal Development seems to increase page count by 66%.

What we are complaining about is that Drupal seems to eschew evolution for perpetual revolution.

Each new version sees mass disruption of modules and recreation of problems that had been solved along with a whole lot of new ones. Exactly because of the way FOSS works, it is not the community as a whole who chooses this path but a relatively small elite of expert developers. There is no consensus to this, it is boiling Darwinism. This ecosystem produces stunning software for sure. But FOSS isn't a food chain that needs to care about users who for the most part are getting something for nothing and not paying in kind by participation. It is, however, like any ecosystem: a delicate balance between healthy sustainability and inadvertent mass murder, or at least mass misery, that begs some important questions.

Aside from the moral and philosophical arguments that make FOSS interestingly bipolar political, there are times when I wonder whether any CMS that regards its content as secondary to its innovative ingenuity has gone off the rails.

After years of coming to hate static HTML I thought and still think that content is primary. In a CMS the means to access and present it should never disappear. Yet look at what has happened to the Image module & image gallery and the 80,000+ users now trying to wrangle half-working migrations to other modules. Drupal is a bit mad in this. Imagine the outcry if Facebook or Flickr innovated users out of access to their material. OK FOSS is different, but "fix it yourself" or "just carry on using the old version" are at best power without responsibility if it allows developers to trash things that people depend upon. You can't really call that community.

I got into Drupal c.2006 4.3, after 10years of static HTML and a year with a commercial Perl-based CMS that promptly went bust. The company, Arborior was killed off by FOSS just as I was completing my site and waiting for a bugfix. I tried several of the victors. Most seriously Mambo/Joomla but after a month I hit a wall of limitations that ruled it out for me. Drupal seemed vastly superior with its Lego-like philosophy. Even if the learning curve was ferocious, the flexibility was unbounded. That was the theory.

I am not a programmer, I am a photographer. I was right about the learning curve. It took me months before I had any sort of basic comprehension of Drupal, over a year of late nights before I had a working site as I wanted it. I'd managed to integrate Menalto G2 and that was great for 10,000 client photos, all segregated into tightly permissioned private photolibraries, but wrong for portfolio and photo stories. After trying every Drupal solution, Image was the only one that worked for me, with the fewest limitations. Those were so blindingly obvious I was sure the community and I could sort them out.

I'll tell you want they were, because it illustrates perfectly how Drupal is capable of blind spots.

One was that although multi-taxonomies are fundamental to Drupal, Image had no means of keeping track of the current taxonomy when advancing through images that inhabited several terms. If I had an image that was categorised as both and "reportage" and another categorised as "reportage" and "animals", paging through "reportage" would switch the category to "animals" by the 3rd and subsequent photo. Hopeless.

The other problem was that there was no "next" or "previous" link on each image node, you had to go back to the image gallery thumbnails to navigate. An absolutely fundamental omission, even a paperback allows you to turn pages without having to return to the index. Yet that couldn't be solved without curing the multi-taxonomy derangement.

Another was that there was no means of setting the order of image nodes except date or weight. Which is fine if you have just a few pics, and insoluble if you have a lot and update frequently. And if you wanted to exhibit a lengthy photo narrative, which like one of mine runs to 84 pages, you were in a mess.

The "community" had noticed all of these, and there were countless support threads raising the issues and suggesting workarounds and half-baked hacks. Being new to Drupal and Php I couldn't tell which were likely to work, and most didn't. It took me until D5 was replaced by D6 to solve these problems on my 4.7 site. I then moved to D5 and had to do it all again. But I was slowly getting better at this Drupal lark. I created and offered patches (mostly not my own work, adapted hacks from the community of the afflicted) to fix multi taxonomies, to get Image working with Nodeorder, and a custom Image pager module. The maintainers dismissed them as "too specific for Drupal" without further discussion. They worked fine, were built to Drupal coding standards and were just what dozens of threads had asked for. But the gods had by then decided that CCK, Views, Imagefields and the whole unfathomably complex rats nest was a better solution than a single simple module that a muppet like me could understand with a few years effort.

These were simply not issues that concerned the expert maintainers who could have coded solutions in minutes back in D4.5 days. But they clearly frustrated large numbers of users over and over again and were absolutely basic usability issues. Yet they never got fixed in 6 years and still are not as Image is consigned to the dustbin of history, and those of us with hundreds of images invested in it are left floundering with dozens of modules now required to perhaps do the same simple thing if we can only figure out how, no clear migration path to D7, no clear outcome. I think the reasons for this are interesting and important.

One reason for this disconnect is given on the Image module page, that few developers use Image as a site component. Perfectly understandable. Images are incidental for many people, it was never that important to them, and easy to move on.

Also I suspect the people at the cutting edge of Drupal development and direction simply have different priorities to the bulk of people who actually use the stuff they make. I've worked with a pro programmer and seen that the interest for him was doing clever stuff. He was undaunted by complexity as it increased the intellectual challenge. As skill increases, so does the capacity for going to new, esoteric solutions, and learning is the reward. And stuff never gets quite finished. Once the exciting stuff is done, the dopamine ebbs away and it's on to the next big challenge.

So sticking a couple of next & previous links into Image gallery was banal unappealing drudgery. I even offered $200 at one point, with no takers. Later, when I actually managed it, I was terribly pleased with myself as I'd managed this simple task that took me many days. Someone who knew what they were doing could have done it over coffee, but they had moved on.

So instead we got the impenetrable shining black marble obelisk of Views, and a lot of puzzled monkeys like me dancing round screaming in terror. For the high-level developers who shape Drupal, I'm sure it's the constant challenge of the bleeding edge that fires them. But for the long tail of users, this constant reinvention is often disruptive and overwhelming.

That old chestnut, stick with the old version, is advice that I followed. Until a few months ago I clung on to my hacked and patched D5 whose Image handling worked properly. Then one day it didn't work because the hosting co. retired PHP5.2 which broke the site. Since when it's D6... and no pictures... on a pro photographers's website. Image gallery is now just a stub for Views. I can't simply hack its code to reinstate my stuff, and what I get now is incomprehensively disordered and deranged, missing text, the lot. I'm sure it's possible to get working with the new regime, I just don't know how many weekends and late nights.

I am seriously thinking I've had enough. Maybe it's time to admit defeat by Drupal's relentless learning curve. The only reason I haven't is my investment in content and getting to where I was. Oh, and my sister's site (tapestry fine artist) and friend's site (painter), both favours, not paid work. But Image deprecation makes it likely I'll have to start from scratch anyway with D7. I live in fear of D7, and whatever D8 turns into.

I've worked with other CMS a bit, especially Textpattern on a legacy site I've been lumbered with. I've not found Drupal's snakes n'ladders repudiation of version continuity at all. OK, it doesn't have Drupal's CERN-like atomisation, but you don't need a PhD to get next and previous links on images.

I find this so exasperating. I like Drupal. I am not asking anyone to do anything for me, never have. But when the FOSS mantra of "fix it yourself" gets trotted out, I have actually done exactly that and offered it to the community that has been asking for fixes for years, and it has been refused.

I understand Drupal is not a democracy, it is necessarily hierarchical based on engagement and competence at Drupal. Someone has to guide the overall direction of the project as a whole and it can only be those who are expert and I certainly am not. But I do wish the experts would recognise that bumbling phpidiots like me may have something to offer in other ways. If over and over again people whose interest and expertise is images point out the shortcomings in Drupal image handling, we don't mean the engineering, whether nodes or files or fields or any else of whatever-the-hell-they-are burgeoning Drupal constructs. We mean simply that Drupal is not very easy to deploy or nice for visitors when it comes to images. This matters for the health and value of the whole project.

Fantastical complexity just seems the wrong way to satisfy diverse requirements when most of the people implementing those requirements have simple needs and simple minds. I once thought the modularity of Drupal would resolve this with relatively simple modules around an image API. Now, I haven't a clue what to use or how, and that's after reading tutorials, discussions and docs. It appears that in order to put up a show of pics I have to get my thick head around not only Image but Views, CCK, Filefield, Features, Imagefield, NodeReference, Ctools, Litebox2, ImageAPI, Imagecache, Custompagers, and about a dozen submodules. ... Perhaps it's time to fork Drupal to an idiots lite version. There are a lot of us.

Regards
Tony Sleep http://tonysleep.co.uk

TauTau’s picture

excellent. I'm exactly in the same boat, trying to get away from Joomla and it's components, which are hard to maintain, and thought Drupal could be a solution. Even being in IT with some little programming knowledge, it's hard to get my head around Drupal and how to setup a site primarily made for galleries. Guess I'll move on and look for easier solutions (or maybe pay dupalgardens)

mcfilms’s picture

Hi Tony,

Your message should be read by Dries and Angie. I totally feel your pain.

I spent many weeks working on a Flash/Drupal integration when the Services module I was depending on went through some tremendous changes. It entered a "Beta" stage for a long time. When I expressed my frustration I was told, "It's Drupal. The drop is always on the move."

In my case, because I am as stubborn as a mule, even when it goes against my best interests, I kept after Drupal. Today, about half of the work I do is developing Drupal sites. Ultimately, I'm happy I cracked it.

I don't know what the solution would be. Maybe the person above has the right idea and it would make the most sense to use a service provider like Drupal Gardens. Maybe some people can get behind an initiative to document how to implement the most requested features. Maybe at some point the Features module will be less complicated than just installing the modules and following a step-by-step tutorial.

In any case, I agree with you that Drupal's constantly morphing state is a strength for coders and a weakness for almost everyone else.

A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com

WorldFallz’s picture

...is a strength for coders and a weakness for almost everyone else.

It may be hard to appreciate sometimes-- particularly after something like you describe or a painful major version upgrade, but that's actually not true.

Drupal would not be the powerful flexible tool it is today for anyone if it was forced to drag around the baggage of prior versions.

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

mcfilms’s picture

Well lets cross dragging around legacy code off the list. Maybe there are other solutions.

Maybe more care and consideration needs to be taken before switching to the next new thing. Maybe a clear migration path needs to be outlined and planned before switching. Maybe before starting on a brand new feature more thought needs to be put into how it will grow and where it will go down the line.

Since I began using Drupal the "box of Legos" paradigm has sprouted in the Drupal community. It's one of the big ways Drupal distinguishes itself from Wordpress and Joomla. Instead of one big module that tries to cover it all, Drupal has many smaller modules that you can snap together to suit your needs. Cool. But in reality new features and trends completely overshadow the very practical needs of the 99%.

Love it or hate it, you have to hand it to Wordpress for identifying the most common pain points for someone that is managing a web site and making it easy to service them. A clear and easy to manage back-end, easy-to-install WYSIWYG, the ability to insert images with captions, and image galleries are all there. Of course we all realize when you try to go beyond that capability you soon get stuck.

When Drupal 7 was announced, one of the hot new features was RDF. To this day I do not know anyone who is using it. On the other hand, I have encountered at least 20 people who are frustrated with trying to create or update an image gallery. But creating image galleries isn't considered sexy. That challenge has already been met and for most developers it's time to move on.

Meanwhile the OP and halftone still don't have an image gallery.

A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com

WorldFallz’s picture

Ah ok, that's actually a separate issue. The 'drop is always moving' meme refers specifically to backwards compatability (dragging around legacy code) so that's what I thought your main point was.

Priority setting is definitely a valid point and criticism-- I still have no clue why so much time and effort was thrown at overlay and toolbar in core (especially since toolbar was created new rather than adapting the existing and insanely popular admin_menu module) while the entity api was left incomplete and the profile module simply abandoned. To this day I turn them off on every site. In this particular area, it seems the bigger shops and/or companies, and therefore professional developers, carry far more weight than average site builders or users. I don't think it intentional-- it's just that devs working for big shops have far more luxury to decode the core contributor labyrinth than the single site builder (someone who just wants to create an image gallery easily).

_
Care about the future of the Drupal.org forums? Please join our conversation and show support for improving the forums infrastructure.

mcfilms’s picture

By the way, while composing that message it caused me to give some thought to Tony's situation. Thinking about it, why not just build a Drupal 7 site with the gallery styled in the way you desire. Then migrate your images with taxonomy to it? I honestly don't believe it should take more than a day.

A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com

halftone’s picture

As far as I know there is no migration method to get from D6 Image module to D7 core Image (formerly CCK Imagefields) that doesn't break existing content nodes where Image nodes have been inserted using Image Assist. That's all existing content on my site bar about 3 pages, and the Image nodes themselves.

Worse still, Menalto Gallery 2 integration (http://drupal.org/project/gallery) is absent in D7. That's absolutely mission critical for me. I have 10,000 client images within G2, and access to them is permissioned by Drupal roles and navigated by custom Drupal menu blocks . Although I could migrate to Menalto Gallery 3 that isn't so much a version upgrade as a simplified fork with no integration API, so that isn't supported either.

3 years ago when G3 first arrived there was sort-of a developer consensus to expand Drupal image handling to do what G3 does, as lack of a G3 API made integration impossible. G2 integration was deprecated in the process.

Needless to say this hasn't really happened, and it's hard to see how it could. G2 is a one-of-a-kind industrial-strength image CMS which you simply won't find outside commercial photolibraries and hosting services like Photoshelter, with its own specialist modules and theming. It would take many years for Drupal to reinvent that wheel, and a specialist perspective and dedication to images that appears not to exist within the Drupal developer community. All those guys are working on Menalto Gallery!

This is all a showstopper for me. Integration of G2 was and is the sine qua non. Integration seemed certain not to disappear back in 4.5, 4.7, 5 days. Heck, even Menalto's own site was and is a Drupal-G2 integration, the two CMS seemed synergistically wedded if not welded together.

So from my PoV the handling of images within Drupal has degenerated to the point where it is a frigging disaster. A more casual user of images, or someone starting with D7, won't encounter the same problems, they'll be able to re-upload their few dozen images, recreate the occasional content nodes which have missing Image Assist insertions, and move with the evolving "drop". But anyone who has hundreds or thousands of images in existing Drupal content, or had needed G2 integration to continue, has walked into a cul-de-sac. D6 is the end of the road.

I don't have any choice now but to abandon Drupal. For all its flexibility it has headed off in a direction I can't follow or adapt to. G2 can be integrated with other CMS, and I guess I am now doomed to Wordpress and an awful lot of work recreating my Drupal content from scratch. Exactly what I believed I would avoid by adopting and investing in Drupal's peerless flexibility and learning curve for the last 5 years. It'd be funny if it wasn't.

Regards
Tony Sleep http://tonysleep.co.uk

ressa’s picture

You probably have already seen it, but it seems like somebody is working on releasing a module for D7, according to this post: http://drupal.org/node/1177732#comment-6426824

halftone’s picture

Thanks for pointing to that, it's really good news.

Regards
Tony Sleep http://tonysleep.co.uk