August 2008 - Development - lists.drupal.org

[Fwd: [support] Staging]
by Christopher M. Jones 19 Aug '08

19 Aug '08

I have been looking for a clean solution to the problem of how to stage a drupal site, using the common dev->QA->production development cycle. I originally posted to [Support], but someone there suggested that I post my questions here, as well. My original message follows below. -------- Original Message -------- Subject: [support] Staging Date: Thu, 07 Aug 2008 15:22:54 -0400 From: Christopher M. Jones <cjones(a)partialflow.com> Reply-To: support(a)drupal.org To: support(a)drupal.org I'm looking for a decent approach to staging a drupal site. The production site will be a collaborative authoring project, with forums, blogs, and lots of media. The client will have access to this site, and will be maintaining some of the content. Other content will be maintained by us. The development company that hosts this project prefers to make all of their changes, both to content and templates, in a testing environment. Once their client has approved the changes, they like to 'push' them to production. However, while these changes are taking place, the client may be administering forums and writing blog posts in the -production- version. To further complicate things, my company wants a three-stage cycle. They want a dev site, where they make changes for in-house review, which they then push to testing for client review before everything is pushed to production. I'm unsure how to approach this. The site in question has always been static html created in Dreamweaver. At some point they started adding other things, so now there are two wordpress blogs, and two phpbb forums. The forums and blogs presently are excepted from the development cycle. They simply appear to be part of the site, because their templates have been designed so. But that means that we've got to propagate template changes across five templates. Things are breaking constantly, and this is why I piped up to them about drupal. I've seen a lot of discussion about this topic, but I really need some hard answers. What should I do? I've seen the Staging module for 6.x. Is it safe to use? If so, then we could use that for the database. Templates could be pushed with rsync or svn... whatever. But would this work two ways? Could we sync the dev / testing sites to the production site, then sync the other way? Would we need to? Also, I envision using a multisite environment so that all sites share the same modules, media, etc, but use different templates. I desperately need the detailed advice of someone with experience, here. -- [ Drupal support list | http://lists.drupal.org/ ]

2 1

What about reviewing patches?
by Karoly Negyesi 16 Aug '08

16 Aug '08

All this rant about this and that and noone reviews patches. Shame on you.

25 46

$custom_theme when does it take effect... when does it not
by Jon Saints 15 Aug '08

15 Aug '08

I notice a bug in D6.4 and CVS in the block module. This post, however, is not to report the bug (i will use bug tracker for that). This post is to ask a development question that will help me create a patch for the issue. On our website we use different themes for different sections of the site. As the user browses to different sections of the site, the theme is changed automatically by changing $custom_theme global in hook_init(). Bug background: The bug occurs when administering blocks. For example, if my current active theme is foo_theme and I click admin/build/block/list/bar_theme a list of blocks for bar_theme is not displayed. Instead, a list of blocks for the active theme foo_theme is displayed. When the user clicks the link "Bar theme" they could reasonably expect that a list of the blocks for bar_theme should display. The development question: I think the bug has something to do with the code in the block module function block_admin_display(). In this function the author of the code tries to display a list of blocks for the theme the user selected by changing the global variable $custom_theme. The problem with this approach is that outside of hook_init() I have found that changing $custom_theme variable has no effect on changing the active theme. Have others found this to be the case that changes to $custom_theme variable have no effect on changing the active theme outside of hook_init()? If this is the case then we need to rethink how we are pulling the list of blocks in the block module admin. Thanks Jon

4 9

[from support] Staging
by Yuval Hager 14 Aug '08

14 Aug '08

I'd like to draw the dev list members' attention to a thread from support about staging: http://lists.drupal.org/pipermail/support/2008-August/009492.html The reason I am sending this here, is that I believe there is no structured and well defined solution to the problem. There are many trials to handle this (e.g. even/odd nid numbering scheme, dbscripts), but most of them are cumbersome and/or limited in many ways. I believe this is a very common problem, and that the only real solution should come from core. I think the most difficult part here is to separate content from configuration. The first step would be how to define what is content and what is config (for example - site name - is it a content property or a config property?). The next step then would be to find a way to transfer config from a staging/dev site onto production, without overwriting any content that might have been added there during development. -- Yuval Hager [T] +972-77-341-4155 [@] yuval(a)avramzon.net

20 65

best pratices, test environment, patch review: clues how to make easier to contribute
by Ivan Sergio Borgonovo 14 Aug '08

14 Aug '08

There are a lot of good tools for helping coders and reviewer. There should be a lot of experience in building up a dev environment *and* a patch review environment spread in the community but "hidden". If I had to put up a dev/review environment now I would: * install drupal HEAD * install coder devel modules(?) * fill drupal with some data using devel * backup * update from cvs * restore db connection setting * apply a patch - check if any schema change * test (benchmark?) * report * restore db Still this look very naive and I think there are a lot of tools that could help without getting into module frenziness and a lot of details that could streamline the process or setup that may hide some problems. There is not a compact knowledge base of several techniques that may make more profitable for people that already maintain drupal sites to contribute to core and contrib. I think that most developers are still applying common wisdom and their own hand made recipes. code coverage, deploy, drupal automated staging toolkit, drush, simpletest and auto test??? If tests are already automatically made on submitted patches, preparing a testing environment isn't so critical for a patch reviewer, but it could come handy for a developer. If I had to improve the above naive method I'd start from writing a script that given a patch url: * update from cvs * restore db connection setting * apply the patch Second thing I'd do would be to replicate the simpletest environment and start testing the patch. Then I'd choose a set of "important modules" and see if patches or HEAD breaks them. I think this looks a bit more tricky and may require some rcs wizardry especially if I've my modules to test too. Another thing I'd like to learn to do better is how to maintain modified drupal core, supposing I submitted patch waiting and I'd like to check if they still works when I update to HEAD/review a patch and mix svn (or any rcs of choice) with drupal cvs. A DVCS could come handy here... but... that's not the point here. The material about how to put up a dev/review environment is sparse. Something that may be interesting and I would like to read more about or see them grouped or add some glue so that it would be possible to guide people to a more rationalised dev/review environment: Using CVS to maintain a Drupal website http://drupal.org/node/93966 R. Keeping Your Local and Remote Sites Synchronized http://drupal.org/node/120617 Drupal development server configuration http://www.garfieldtech.com/blog/drupal-dev-server K. Moving Entire Drupal Site with Databases http://drupal.org/node/120627 Migrating Database Changes From Development to Live Websites http://drupal.org/node/199771 Drupal Performance Measurement & Benchmarking http://drupal.org/node/282862 Drupal with safe mode enabled and open basedir http://drupal.org/node/82223 More than one Drupal site on one machine http://drupal.org/node/274 Transforming a default table names installation into a prefix table names installation http://drupal.org/node/195758 How-To: Virtual Hosting with Drupal http://drupal.org/node/80472 -- Ivan Sergio Borgonovo http://www.webthatworks.it

6 7

Patch reviewing best practices [was] What about reviewing patches?
by Jerad Bitner 14 Aug '08

14 Aug '08

So I'd like to hear from those of you who do a lot of core patch reviews to find out what is your workflow? It was pointed out in the last thread that it's not a matter of it taking a long time to actually review a patch, but to get everything in place in order to review a patch and having a standard environment setup that is conducive to reviewing patches. I'm sure there are many devs out there that have a standard set of steps they go through to test out a d6 patch and something similar for then testing out a d7 patch. I'm sure it would help many people to hear some of these setups in order to replicate these practices on their own machines and get some patch reviewing done. If anything, comparing notes from different developers on how they approach this could lead to some great standard set of practices and therefor, handbook pages ;) ~Jerad sirkitree.net drupalmao.com

1 0

Please help fix db_rewrite_sql in search
by Robert Douglass 13 Aug '08

13 Aug '08

Did you know that Drupal's search module doesn't properly use db_rewrite_sql? Surprised? Well, it's been in the issue queue since 2006. http://drupal.org/node/54622 There is also a patch that has been waiting for review ever since the Minnesota Search Sprint (May 10) that nobody has looked at. I've marked the bug as "critical". As Drupal's standards get higher bugs like this aren't acceptable. Hopefully this mail will stir up some interest.

2 2

Unique/Random IDs and drupal
by Ethan Fremen 12 Aug '08

12 Aug '08

Gentlebeings, I've read the recent thread on devel->staging->deployment, and I wanted to share what I've done in the area. My main interest lies in moving away from monotonically incrementing integers as id values so I have a greater chance of being able to "shard" the drupal DB for high performance. As a first step, I am working on moving drupal core to using 64 bit integers. It was relatively trivial to change schema to create 64 bit tables, but right now there's nothing in schema that marks "foreign keys" as also being special. Would anyone object to schema requiring foreign ID references to be marked specially? Anyway, the direction I'm interested in heading is a 64 bit int + creation date timestamp for every row; the two can be combined to form a valid UUID if there are useful reasons for doing so. Note that Postgresql has UUID creating functions and MySQL 5.1 has uuid_short() which generates a 64 bit random int based on the UUID algorithm. The UUID() algorithm in mysql 5.0 isn't viable for scaling purposes because it's not cluster-safe. I do have some preliminary performance data on the speed at which one can create UUIDs: http://mindlace.net/archives/2008/06/23/generating-uuids-in-php-for-drupal/ I'm very interested in any feedback about the feasibility of at least widening the ids to 64 bits in D7. ~ethan

7 12

PHP 4 is dead, long live PHP 4
by Johan Forngren 11 Aug '08

11 Aug '08

Yep, no more PHP 4. The PHP development team would like to announce the immediate availability > of PHP 4.4.9. It continues to improve the security and the stability of > the 4.4 branch and all users are strongly encouraged to upgrade to it as > soon as possible. This release wraps up all the outstanding patches for the > PHP 4.4 series, and is therefore the *last* PHP 4.4 release. > http://www.php.net/archive/2008.php#id2008-08-07-1 http://www.computerworld.com.au/index.php/id;1239055978 -- Regards, Johan Forngren :: http://johan.forngren.com/

1 0

Choosing the N number for .install's hook_update_N
by Zohar Stolar 09 Aug '08

09 Aug '08

Is there some policy, or a thumb rule, about choosing the N number for .install's hook_update_N? I've proposed this patch <http://drupal.org/node/288946>, and I chose the number of the update to be the next one available. However, by the time this patch is applied (if it is accepted), it has a good chance of failing on this sequential number, if a former patch is applied before. Any directives I should be aware of? Thanks -- Zohar Stolar

17 42