[support] Best way to deploy Drupal.

[Seth Freach]

Unai,
(d) really is the tricky part.  Some modules will play nice, others 
won't. Some of the easiest modules to configure in your code will be 
ones that use /system_settings_form()/ to return their administrative 
options and configuration forms.  /system_settings_form()/ just stores 
things as variables.  This means that, for a low maintenance module that 
does all of its settings configuration on its admin screen, the API to 
configure that module from other code consists of /variable_get()/, 
/variable_set()/, & /variable_del()/.

I would not recommend doing this in the contrib module's .install file, 
ie: directly in that module's update_N hooks.  If you take 
mighty_contrib_module.install and add the function 
/mighty_contrib_module_update_1()/ (or, more correctly, ...update_6101() 
), things will work fine only until the next release of that module is 
available and the author has added his own first update hook.  Besides 
the version control conflicts in the files themselves, there will be 
schema version fixing needing to be done in the system table.

I would recommend creating your own local module that exists mostly to 
just contain the update_N hooks to configure other contrib modules (say, 
housekeeping.module).  Kind of like the junk drawer in you kitchen... 
everything useful (and not) that's together in one place just to keep it 
out of the way... Assuming that mighty_contrib_module had an admin 
setting to set the max number of words allowed in something, we could 
find the name of the FAPI element, and then inside of 
housekeeping.install write:

<code>
function housekeeping_update_1() {
  variable_set('mighty_contrib_module_max_words', 100);
  $ret[] = array(
    'success' => true,
    'query' => 'this is just a message masquerading as called sql 
statement for reporting purposes.',
  );
  return $ret;
}
</code>

You'll find all sorts of things to shove into the housekeeping module ;) 
Including some core config stuff too.

Looking at the classifications you've set out below, I'd say that (b) is 
really a subset of (d).  When it comes to contrib modules, there are 
going to be two main categories: those that play nice and those that 
don't.  views happens to fall into the 'plays nice' category.  Others 
won't.  It's an important distinction you'll need to make when you're 
deciding which contrib modules to use from your solution's onset, an 
important criteria that cannot be overlooked.

Seth

Unai Rodriguez wrote:
> Dear All,
>
> Thank you so much for the contributions. 
>
> I have classified different parts that currently compose our Drupal system
> along with a suggested method of "putting everything in code and update
> functions":
>
> a) THEMES.- We just copy the code over, there is no settings to be applied
> really
> b) VIEWS.- We will be using what is suggested here:
> http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views
> (This is similar to what Seth sent but applied to Drupal 6 -- THANKS SETH!)
> c) MODULES DEVELOPED BY US FROM SCRATCH.- We will make sure that all the
> settings that need to be put into the database are being updated on the
> hook_update function. Ideally these settings could come from a
> configuration file in php. We will use DRUSH to invoke our update.php upon
> deployment, as suggested by Kathleen.
> d) 3rd PARTY MODULES (aka contributed modules by the Drupal Community).- I
> am not sure how to proceed with this one; for now I am trying to check if
> the modules that we use implement the hook_update function and modify if
> possible so the settings get loaded from configuration files, similar to
> (c).
>
> My questions are:
>
> 1) How would you handle (d)? What I have now in mind seems a bit tricky...
>
> 2) What do you think of the classification? Am I missing something? Does it
> make sense?
>
> Thank you so much.
>
> With Best Wishes,
> unai
> --
> [ Drupal support list | http://lists.drupal.org/ ]
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.drupal.org/pipermail/support/attachments/20090714/8e193e90/attachment.htm>