admin's blog

the drush (drupal.org/project/drush Drupal Shell) toolset provides some nice featured for moving database for drupal sites.

to see all the drush commands related to sql type: drush | grep sql

davidhazel@Macintosh-10:/workspacessd/example.local/sites/all/modules$ drush | grep sql

SQL commands: (sql) sql-cli (sqlc) Open a SQL command-line interface using Drupal's credentials. sql-connect A string for connecting to the DB. sql-drop Drop all tables in a given database. sql-dump Exports the Drupal DB as SQL using mysqldump or equivalent. sql-query (sqlq) Execute a query against the site database. sql-sync Copy and import source database to target database. Transfers via rsync.

From within the drupal tree do the following: for exporting the db snapshot from the source database

drush sql-dump

you'll get a file drush_nameofdatabase.sql.

for importing that file into your local database drush sql-connect

will give you the local db connection string

"psql --dbname=example --host=localhost --port=5432 --username=postgres" which you can use to import

so psql --dbname=example --host=localhost --port=5432 --username=postgres < drush_snp.sql

will load the file into your local database.

Whenever your building a new Drupal site or troubleshooting a problem on an existing site, it helps to have a local development copy to make it easier to do things like populate test data, try new modules, or run xdebug against.

It's pretty easy to move the code around using svn, rsync or my new favorite git. Moving the database is a bit more complicated.

I've gotten in the habit with the MySQL databases of exporting the database into a .sql file, committing it to git, pulling a copy local, then loading into my local MySQL instance.

You can of course do the same thing with the Postgres databases but it's a little different.

First off Backup and Migrate doesn't appear to work properly with PostGres, basically refusing to allow configuration of the source database.

This leaves a couple of options:

drush sql-dump / sql-connect or pg_dump

drush sql-dump is nice because it is db engine agnostic, making the appropriate adjustments based on the db your using.

However even with this method I was experiencing some Notice: unserialize() [function.unserialize]: Error at offset 0 of 22765 bytes in errors on my local machine.

After some hair pulling I found this bytea_output setting in postgresql.conf Thanks to this post http://postgresql.1045698.n5.nabble.com/Bytea-error-in-PostgreSQL-9-0-td3304087.html for pointing me in the right direction.

Lately I've been working a bit with Postgres and after many years using MySQL I'm finding it a bit challenging to make the syntax switch. One of the things that has helped is the vast resources online, but until it becomes second nature, I'm finding myself having to keep digging through those Postgres resources over and over. As a result, I've decided to start this running thread on command I keep using. They're here in no particular order.

bulk grant permissions to a user instead of having to do it table by table. GRANT SELECT ON ALL TABLES IN SCHEMA public TO username;

As I get more and more into test driven development, a couple tools have really helped speed up development and deployment of those tests.

Running your tests from the command line can make things really quick, especially if you are repeating a test multiple times, trying to track down a bug.

If you have installed XDEBUG, you can trigger breakpoints in your IDE from the cmd line by executing:

export XDEBUG_CONFIG="remote_port=9000 remote_enable=1"


After that is setup, you can run your tests like so:

drush test-run -l http://example.local //runs all your tests
drush test-run -l http://example.local ExampleFunctionalTest //runs only the ExampleFunctionalTest


Most serious drupal developers know how awesome Drush and Features are.

That fact was reinforced to me this week when I "discovered" a couple drush commands that were extremely helpful for deploying new features.

During a site buildout you often go through many iterations of a particular feature, for example the many views that can make up a custom Ubercart store. If you have those Views in Features, you can version them in source control and leverage "svn up" or "git pull" to deploy them to different servers.

When those views change, instead of updating your feature through the UI, just use "drush features-update (fu) mysite_store" (where mysite_store is the name of your feature) to update the code on disk for that feature. Use source control to deploy it, then on the target site, if you've made some tweaks that got stored in the database, use "drush features-revert (fr) mysite_store" to reset so that your using the code on disk.

It's always exciting to find ways to work smarter, and the awesomeness of Features and Drush never ceases to amaze me.

While Ubercart is a very powerful eCommerce solution for Drupal, sometimes the product entry pages can be a little intimidating.

Altering the Ubercart product entry form a bit can help easy the learning curve for new users.

For one such scenario, I wrote a small module which re-arranges some of the fields, putting the basic fields like price and product description at the top, while moving other fields like physical dimension and catalog settings into an advance collapsible fieldset.

I recently had the opportunity to update an email for so that it was translatable. One of the byproducts of that work was translation files for the country lists in French, Spanish, and Arabic.

*.po files attached.

In Drupal 5 and 6, when a user submits the contact form, and email gets generated and sent to the site maintainer (or whatever address is set in the conact form). This email is sent from the server so clicking reply will send an email back to the server, not the email address the submitter set int he form.

The core hack to contact.pages.inc below fixes this so that reply-to address is the sender.

Slight hack of contact.pages.inc file so that if a users submits a contact form through your site, when you receive the email and click "reply" you'll reply to the email value entered on the form, not the server that sent the email.

Note: in some providers, like gmail you need to make sure that the from email set in contact, is not the same as the email that contact forms get sent to. This is something that gmail sets as it's getting routed through smtp.gmail.com

Contact Form Fix For Drupal 6 (From and Reply-To Formation) Chad_Dupuis - May 17, 2009 - 04:03

Recently came across this fix for email handling of contact form results.

In Drupal 5 and 6 email gets sent from the server (unless you have SMTP module installed) so if a user sends you an email through the contact form, when you go to hit reply you will just be replying to the server.

Unfortunately until Drupal 7 comes out, you need to hack core to fix this.

Contact Form Fix For Drupal 6 (From and Reply-To Formation) Chad_Dupuis - May 17, 2009 - 04:03