Automatically setting up content types, fields, and imagecache presets makes deploying Node Gallery with sites built with Features difficult. For example, if I want to rename the node_gallery_image content type, I'd have to export the new content type to a Feature, and then in production delete all of the extra settings that Node Gallery will create on install.

Two ways I see to address this:

    Move all of the content type setup to a separate module.
    Move it to a separate module, but change the install logic so that the entire setup is an exported Feature. This would make the Features module a requirement for the "example" setup.
CommentFileSizeAuthor
#10 1202976.10-optional-type-imagecache-installation.patch4.21 KBdeviantintegral
#7 1202976.7-optional-type-imagecache-installation.patch2.95 KBdeviantintegral
#6 1202976-6-optional-type-imagecache-installation.patch1.34 KBjustintime

Comments

justintime’s picture

justintime commented

As a heavy features user, I hear you, but unfortunately I can't implement either of the above.

The problem is that Node Gallery's primary audience is greatly comprised of, shall I say, beginners. The kind of users who would uninstall if they couldn't get things going in just a couple clicks.

I do have one other idea though.

What if we had a "secret" variable, say 'node_gallery_skip_creation', that when set to true, hook_install() could skip the specific pieces that create the content types, fields, and imagecache presets. You could set that variable before enabling node_gallery via:
1) variable_set() in your install profile
2) a feature using strongarm
3) hardcoded in settings.php

Thoughts?

dddave’s picture

dddave commented

My gut-feeling when I read the OP was similar to yours but I wanted to wait for some other feedback. The "beauty" of NG is that is so easy to use for "light" users, we keep pushing other features in this regard (navblock discussion and such) in and I think this is a good thing. The out-of-the-box readiness of NG is awesome and I strongly vote to keep it this way.

I cannot evaluate your idea but it sure sounds like a cool compromise where everybody wins.

scroogie’s picture

scroogie commented

Isn't there a way to check if the module is installed through a feature?

The imagecache presets could be changed to use hook_imagecache_default_presets if that helps: http://drupal.org/node/558664#comment-2912630

Not sure about the other stuff.

deviantintegral’s picture

deviantintegral commented

Having a variable would work. Getting anything that can be exported, such as imagecache presets, would be a big improvement.

With the current system, what's the procedure if the default configuration is changed in a node_gallery update? Just documentation? The other big advantage of using Features is that by default, upstream changes will be pulled in unless the user has modified them. So, if there's a bug in a some part of the setup code, at least we can fix it without worrying about trouncing over customziations.

If we did do a Features module containing the default setup ("node_gallery_quickstart"), the additional overhead for new users would be:

  1. Adding Features to the contrib modules to download.
  2. Having a second module to enable. On first install, we could also set a dsm() to point the user to the module as a recommended module to enable.

Is there something I'm missing here? I'm just not seeing how much more difficult it is compared to the current setup, with big gains in both maintaining the module and for advanced site builders.

justintime’s picture

justintime commented

Is there something I'm missing here? I'm just not seeing how much more difficult it is compared to the current setup, with big gains in both maintaining the module and for advanced site builders.

What you're missing here is that out of the ~ 4,000 users of Node Gallery, you're asking me to add a (albeit small) inconvenience for about 3,975 of them that will only benefit the remaining 25. That doesn't make much sense to me.

I'll see if I can get the variable in place before 3.0 release. I do agree with you that it's a cleaner approach, but realistically I'm not going to make such a major change until 6.x-3.1 at the earliest -- more than likely the 7.x-1.0 branch will be the first place.

justintime’s picture

justintime commented
Status: Active » Needs review
StatusFileSize
new 1202976-6-optional-type-imagecache-installation.patch1.34 KB

Something simple to get the ball rolling

deviantintegral’s picture

deviantintegral commented
StatusFileSize
new 1202976.7-optional-type-imagecache-installation.patch2.95 KB

Here's an update that fixes some minor code style issues and uninstalls the variable if the admin has set it using drush vset instead of in settings.php.

justintime’s picture

justintime commented

Looks good to me. If you can test that this does what you're needing it to and mark it RTBC, I'll get it committed in.

deviantintegral’s picture

deviantintegral commented
Status: Needs review » Needs work

Just noticed that the variable should be a boolean instead of an integer.

deviantintegral’s picture

deviantintegral commented
Status: Needs work » Reviewed & tested by the community
StatusFileSize
new 1202976.10-optional-type-imagecache-installation.patch4.21 KB

I've used this patch on our development environment testing our features setup and I think it's good to be committed.

justintime’s picture

justintime commented
Status: Reviewed & tested by the community » Fixed

Committed to 3.x-dev.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.