Any value stored in the variables table can be set in code. Read the bottom of the settings.php file for details of implementation. Many many many modules store their values here.<br><br>For your custom modules, you can set all your default variable values in code. Then, any time you need to change that default value, you'll do it in code rather than performing an action that would effect the database.<br>
<br>Read through the API of the contributed modules and see what you can use. Use provided hooks whenever possible. If necessary, you can run functions as one-off update events. For example, I used simplenews' simplenews_subscribe_user() function as part of a script to initially subscribe all users. Othertimes I have run scripts to migrate values from one field to another field, then delete the old field. I don't have a recommended best practice for automating this, but I'd look into setting up a system that will run each script in succession and then store what point it is at (e.g.: something like Ruby on Rails' migrations).<br>
<br clear="all">--<br>Kathleen Murtagh<br>
<br><br><div class="gmail_quote">On Tue, Jul 14, 2009 at 6:05 AM, Unai Rodriguez <span dir="ltr"><<a href="mailto:me@u-journal.org">me@u-journal.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Dear All,<br>
<br>
Thank you so much for the contributions.<br>
<br>
I have classified different parts that currently compose our Drupal system<br>
along with a suggested method of "putting everything in code and update<br>
functions":<br>
<br>
a) THEMES.- We just copy the code over, there is no settings to be applied<br>
really<br>
b) VIEWS.- We will be using what is suggested here:<br>
<a href="http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views" target="_blank">http://treehouseagency.com/blog/steven-merrill/2008/11/05/speed-and-version-your-views</a><br>
(This is similar to what Seth sent but applied to Drupal 6 -- THANKS SETH!)<br>
c) MODULES DEVELOPED BY US FROM SCRATCH.- We will make sure that all the<br>
settings that need to be put into the database are being updated on the<br>
hook_update function. Ideally these settings could come from a<br>
configuration file in php. We will use DRUSH to invoke our update.php upon<br>
deployment, as suggested by Kathleen.<br>
d) 3rd PARTY MODULES (aka contributed modules by the Drupal Community).- I<br>
am not sure how to proceed with this one; for now I am trying to check if<br>
the modules that we use implement the hook_update function and modify if<br>
possible so the settings get loaded from configuration files, similar to<br>
(c).<br>
<br>
My questions are:<br>
<br>
1) How would you handle (d)? What I have now in mind seems a bit tricky...<br>
<br>
2) What do you think of the classification? Am I missing something? Does it<br>
make sense?<br>
<br>
Thank you so much.<br>
<br>
With Best Wishes,<br>
<div><div></div><div class="h5">unai<br>
--<br>
[ Drupal support list | <a href="http://lists.drupal.org/" target="_blank">http://lists.drupal.org/</a> ]<br>
</div></div></blockquote></div><br>