deprecate drush.make file

[ohthehugemanatee]

Is this used for any projects anymore? Perhaps we could reduce the hundreds of modules it includes to just the handful that we KNOW are a requirement on every project?

[slucero]

One thought I had for improvement on this specifically was some optional integration into the generator to help define some of the core dependencies included here. This would allow us to still define dependencies based on various criteria and even include sets of modules/patches to meet these requirements.

[wwhurley]

Yeah, I think there are more opportunities to leverage yeoman to scaffold out basic site features.

[ohthehugemanatee]

agreed. IMO that means:

1. cut out 99% of the existing drush.make file as a starting place.
2. define additive sections in the generator-web-starter project. For example, "do you want to include standard dev tools? (Y/n)" includes a section with devel, diff, etc. Some of these might be built in to existing questions, for example if you say you're using Features we know to include a section with features/strongarm. Exactly what modules to include in each question can be discussed on that issue queue.

[wwhurley]

The notion I've been kicking around for a few years now is being able to inject configuration for some of these as well. OpenPolicy was a first stab at that, but was a little too monolithic and hard to maintain.

[azinck]

I just went through and cleaned out a bunch of stuff so I'm with you on this being excessive as it currently stands. My take on it: adding modules as you need them is so simple that I just can't see the point in trying to maintain some sort of tool for this. Maybe it's justified if there's functionality that you know has a bunch of dependencies. But for most of those sorts of things drush manages that anyway.

[ohthehugemanatee]

I agree with @azinck that for 99% of this we already have a great tool. My only interest is in filling out the make file with a) things we already have to know about to set up vagrant/capistrano, like features and config mgmt, and b) EXTREMELY common modules that we know we need on every. single. project.

If the theme is gesso:

• gesso
• blockify
• clean_markup
• elements
• html5_tools
• jquery_update
• magic
• simplehtmldom

if using features

• features
• strongarm

if using config mgmt

• configuration
• bad_judgement (just kidding... sorta)

Include on every project

• memcached
• varnish
• devel
• pathauto
• entity
• ckeditor
• ckeditor_filter
• module_filter
• context
• ctools
• ds
• views
• admin_menu
• service_links
• link
• date
• email
• disable toolbar module
• disable overlay module

did I miss anything? Having those modules enabled automagically would be a real convenience for me.

[azinck]

I hardly think that we need those modules on every single project. Many of those modules I've never used. I won't waste a lot of time arguing this. If people think this is valuable then so be it. I just see it as yet another thing that has to be maintained which will save me all of 5 mins per project.

Also: are we using the CKEditor module now instead of WYSIWYG?

[ohthehugemanatee]

tbh I think this is also about standardizing approach. If there are modules up there you've never used, remove 'em from the list please! I'd love to learn what you DO use. I think that we should have a standard approach, and this is a pretty lightweight way to maintain that.

[azinck]

Modules I'd nominate for removal from Campbell's list:

• Context
• ds (not sure we always use this anymore)
• link (surprisingly, not always the best way to manage links)
• email (same as link)

I don't want to speak out of turn about theming, but do our themers always use all those modules now? I personally wouldn't include any of those modules by default and would only bring them in as necessary.

[ohthehugemanatee]

out of interest, what do you use instead of link and email?

re context/ds, I think we should try to standardize around a layout approach. I always use DS, if only because of the entitycache benefits and simplicity in theming. I'm not religious about it though, happy to move to a better approach.

and as for the theme modules, we should ask @dcmouyard but I added them because I think they're effectively required for Gesso. If not, they should be pruned for sure.

[azinck]

Instead of link and email I often end up with just plain text fields. It's been a while since I messed with them but have at times found their validation incorrect or annoying for some use-cases. Have also found their views integration and field formatters to not always be quite what I want.

[azinck]

Also, DS and Context are probably the most borderline. I can understand including them. I've just gotten the sense that we've been inching away from these slightly. If I understand correctly Dan's been leaning more towards a template-driven approach rather than a DS-configuration-driven approach. And with Panels Everywhere there's some argument for not using Context.

[azinck]

Oh, and I'm still curious about CKEditor vs WYSIWYG. I've always tended towards WYSIWYG.

[dcmouyard]

Here are the required modules for Gesso:

• html5_tools (which requires elements)
• magic

Here are the modules I use on every project:

• blockify
• clean_markup

If we’re using Context for sitewide blocks in header/footer, then we also need:

• context_condition_theme

@azinck I still use Display Suite on every project, but usually only for detail pages. I switched to using tpl.php files for theming view modes. There’s a huge additional benefit to using template files if all of the field names are the same across content types, but I know that’s another can of worms. :)

I wouldn’t mind trying out entity_view_mode instead of DS though, especially if we don’t need ds_extras on a project.