<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Unai,<br>
(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 <i>system_settings_form()</i> to return their
administrative options and configuration forms. <i>system_settings_form()</i>
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 <i>variable_get()</i>, <i>variable_set()</i>, & <i>variable_del()</i>.<br>
<br>
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 <i>mighty_contrib_module_update_1()</i>
(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.<br>
<br>
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:<br>
<br>
<tt><code><br>
function housekeeping_update_1() {<br>
variable_set('mighty_contrib_module_max_words', 100);<br>
$ret[] = array(<br>
'success' => true, <br>
'query' => 'this is just a message masquerading as called sql
statement for reporting purposes.',<br>
);<br>
return $ret;<br>
}<br>
</code><br>
<br>
You'll find all sorts of things to shove into the housekeeping module
;) Including some core config stuff too.<br>
<br>
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.<br>
<br>
Seth<br>
</tt><br>
Unai Rodriguez wrote:
<blockquote
cite="mid:36fcd7bc7b2f4f8f0b1f357cc406e1ef@mail.u-journal.org"
type="cite">
<pre wrap="">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:
<a class="moz-txt-link-freetext" href="http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views">http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views</a>
(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 | <a class="moz-txt-link-freetext" href="http://lists.drupal.org/">http://lists.drupal.org/</a> ]
</pre>
</blockquote>
</body>
</html>