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:
Book: Drupal E-commerce with Ubercart 2.x
I am in the middle of several ecommerce website applications right now, so I need all the help I can get. So reviewing this book not only helped me but also served as an excellent acid test for its real world contributions to the hard working ecommerce site builder.