With Drupal 7, drupal.org re-design, and all the "awesomeness" and hot source and the full pantheon of mythical gods on our web application development horizons, Drupal will still always suck if I can't stage content. Actually using an "awesome" Drupal web application over time (and not just developing it) means needing to be able to cleanly export content from one site, with its references, assets and dependencies, and import it into another. Because you can't be editing a live production site, even with as few as a few hundred simultaneous visitors.
Neither can you go around saying you're a "free as in beer" open source wonder child if you have to be a database management genius to arrange for database clusters and database migration (a la whitehouse.gov) solutions for this; seeking the "up" market (large corporations) instead of the "down" market (working stiffs, small and medium businesses, NGO's), like WordPress does, is all very well, but if you have to be a rocket scientist to cleanly move content from one site to another in order to stage content, then maybe we ought to be more honest about the real costs involved in using Drupal these days.
But, enter stage left the Deployment module! It was designed to solve this problem, and to the extent that that is true, then why wouldn't I develop all my sites using it? Otherwise:
"Ceiling cat is watching you perform search and replace node reference id's on the output of node export module content before importing to live site"
This article takes a look at the architecture of the Deployment module, sets up an initial test bed, drafts an initial acceptance test, runs the test and reports back.
Features driven development -- the nitty gritty and thoughts on the future of sustainable "in code" developmentWed, 2010-10-06 09:16 — victorkane
Features driven development in the Drupal sense involves placing code into versionable text files and packaging functionality into reusable components rather than relying on error prone user interface based configuration with scripting stored in the database along with the content rather than in code. It has been a great step forward for Drupal developers. It is simply a joy to once again be able to develop without infecting the code repository with database dump blobs. And to be able to install functionality in multiple servers running different applications irrespective of the content production workflow. But it is not without its contradictions and limitations, which I would like to mention in this article for the sake of discussion. However, while I will propose ideas for a better solution, I am mostly concerned with leveraging development in code right now by finding a comfortable process for using features driven development today, based on the promise of Adrian Rossouw's now classic "Database Is Silver, Code Is Gold" article The Development -> Staging -> Production Workflow Problem in Drupal.
I can hardly believe it, but it's been almost three years since I wrote the original VPS! Getting Drupal up and running on a linode article. These days, I'm still with http://linode.com, where a lot of my clients end up hosting their web app sites; and I'm still installing everything by hand, which is still the best way in all but a few cases, since it gives me what I came to a VPS for in the first place: control over what's going on, and avoiding locking myself into immediately obsolete schemes unless I choose to do so. Of course, there are some excellent install scripts, which Linode calls Stack Scripts, with many of them dedicated to getting Drupal up and running in a variety of excellent manners, even including Pantheon Mercury and Aegir turnkey "single click" scripts. Certainly a great way to go in certain alternatives.
You've heard about the advantages of Panels Everywhere. Now its time to actually get it going. A drush makefile, a few configuration steps, and we should have a starter site up and going and never have to look back on ugly, deficient and crippled admin/build/block.
In a recent Buenos Aires Drupal Dojo online virtual lab, we did just that, so I shall lay out a series of simple steps here on the basis of what we learned together that night.
Let's summarize the advantages of Panels Everywhere, take the steps to get it going, and think about next steps.
Accessing a Drupal xmlrpc server using api key and session id from php - a working example you can actually useSun, 2010-08-08 12:55 — victorkane
So Drupal has this amazing services module that I have used and written on before in earlier versions. Now I am upgrading an important site to Drupal 6 which uses an xmlrpc server to receive published articles, and so an upgrade is in order. However, despite copious and varied handbook documentation for this module, I just could not find clear directions on getting this to work in a secure fashion without adopting relatively complex solutions. Others have also stated that they wanted to save people hours of futzing about but they leave out the all important sessionid, for example. Where's it supposed to go exactly? So here is a working example (attached as text) you can actually use, even from a Drupal 5 site. We will: