Drupal | SysArchitects

Safari contextual menu for applying Drupal patches

I wanted an easy way to test patches, so here's what I did.

Copied the OMCEdit application folder to Applications.

Ran the script Install OnMyCommandCM (I checked it out in Script Editor first.)

Logged out and logged back in.

I created a contextual menu item named Apply patch to Drupal installation with the following code:

#!/bin/bash

DRUPAL_HOME=/Library/WebServer/Documents/

cd $DRUPAL_HOME

touch drupaltemp

rm -R drupaltemp

cp -R drupal drupaltemp

cd drupaltemp

osascript -e 'tell Application "Safari"' -e 'get source of document 1' -e 'end tell' | perl -0ne 'print "$1\n" while (/a href=\"(http:\/\/drupal.org\/files.*?)\">.*?<\/a>/igs)' | tail -1 | sed "s/\(.*\)/--url \1/" | curl --config - > patch

bbedit patch

patch -p0 < patch

Now when I right-click on an issue and choose Apply patch to Drupal installation, the script:

Creates a working copy of Drupal.
Obtains the source of the current page from Safari.
Parses out URLs that designate patches (begin with drupal.org/files).
Find the last one, since there may be multiple patches in the issue.
Download the patch.
Open the patch in BBEdit.
Apply the patch to the working copy of Drupal.

Note: this is actually a workaround. I wanted to modify Safari's contextual menu for links, but was unable to find a way to hook in.

Sadly, this will probably not increase the number of patches I review, as it's not really the patching that takes time. This was more of an, I can't sleep...I wonder if I could create a contextual menu that... kind of a project.

[ Submitted by John on Sun, 2006-10-29 21:09. |

]

Drupal 4.6 and PHP 5

I'm running PHP 5.1.6 and wanted to do some testing with the publish and subscribe modules for Drupal. This is the first time I've had PHP5 on my development machine for a variety of mundane reasons. Drupal 4.7 runs fine with PHP5, but imagine my surprise when a fresh install of Drupal 4.6.9 looked like this:

{_BLOCK_.header.logo} {_BLOCK_.header.site_name}
{secondary_links}
{primary_links}
{_BLOCK_.header.blocks}
{_BLOCK_.header.message}...

That's because Drupal 4.6.9 ships with an XTemplate-based theme called bluemarine that doesn't like PHP5. The quick 'n' easy solution was to go to /?q=admin/themes and change the theme to chameleon. (Then I installed the phptemplate engine and used phptemplate from then on.)

Unrelated note: pick up a copy of Apache Security. It's well worth it.

And another unrelated note. In a fit of Drupal server optimization, I installed the FreeBSD port of Zend Optimizer 3.0.1. However, it wasn't long before Apache was segfaulting. It turns out that I compiled PHP with the --enable-versioning flag on (since it's on by default), which is a no-no.

[ Submitted by John on Wed, 2006-10-04 16:01. |

]

Remote PHP Debugging on Intel-based Macs with Komodo

I got a new computer. Yay! It's a Mac Pro.

So naturally I want to set up my Drupal working environment on it.

However, I use the Zend IDE and the Zend Studio Server debugger will not run on Intel-based Macs. No, seriously. It's inexcusable.

I love my real-time debugging. So I decided to try out Komodo. I've made a point to ask about OS X versions of Komodo at the ActiveState booth for as long as I've been attending OSCON. Now they've got a stable version and it supports Macintel.

Well, almost.

So, starting with my new Mac Pro, I installed XCode Tools to get cvs and all the other command-line niceties. Then I headed off to Marc Liyanage's PHP page to install PHP (even PHP treats Marc's installer as the official binary).

PHP 5 installed fine, but I got this unusual hiccup when starting Apache:

[warn] module mod_php5.c is already added, skipping

Commenting out the line

AddModule mod_php5.c

from /etc/httpd/users/+entropy-php.conf got rid of the warning. I'm guessing that Apache is somehow automatically doing an AddModule when it hits the LoadModule line. Anyway, it works fine.

Next, it was time to set up Komodo for debugging. First I wanted to make sure it found the php5 that I installed, and not Apple's php4. So I did this in /etc/profile:

PATH="/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/php5/bin"

and then moved Apple's php binaries out of the namespace:

sudo bash cd /usr/bin mv php php-old mv php-config php-config-old mv phpize phpize-old

I logged out and back in to activate the new PATH and tested:

which php usr/local/php5/bin/php

I put this
<?php phpinfo();

into /Library/WebServer/Documents/phpinfo.php and sure enough, http://localhost showed me the PHP info page. Good so far. On to installing Komodo.

I downloaded Komodo, copied it to Applications, and clicked on it.
Chose Trial version
Got email with URL for evaluation activation key.
Downloaded EvalLicense-KomodoProfessional-MacOSX.zip
Double-clicked to get ActiveState License Installer.
Double-clicked to install license.

Now I started Komodo. I built the "intelligence database" and set up Langugages - PHP.

Now it was time to set up debugging. I used Languages - PHP - Debugger config wizard to put the debugger's php.ini file into ~/komodo/ini and the debug extension into ~/komodo/extensions. It then informed me that the debugger extension could not be started. I did this many times.

Finally, I got annoyed with the debugger config wizard. Instead, I installed xdebug myself. Here's how. First download xdebug (I downloaded version 2.0.0beta6). Then compile it:

cd xdebug-2.x.x phpize ./configure --enable-xdebug make mkdir /usr/local/xdebug cp modules/xdebug.so /usr/local/xdebug/

Then I edited /usr/local/php5/lib/php.ini to include the following:

zend_extension=/usr/local/xdebug/xdebug.so xdebug.remote_enable=1 xdebug.remote_handler=dbgp xdebug.remote_mode=req xdebug.remote_port=9000 xdebug.remote_host=127.0.0.1 xdebug.idekey=komodo

While I was editing php.ini anyway, I changed memory_limit to a sane number.

Applied my changes by restarting Apache:

apachectl restart

Next I configured Komodo to listen for xdebug by going to Preferences - Debugger - Proxy. I set Listen for debug connections on port: to 9000.

Then I went to the Debug menu and chose Listen for Remote Debugger.

And, when I went to http://localhost/phpinfo.php in my browser...wah la! Nothing happened. But when I added the xdebug parameter, like this:

http://localhost/phpinfo.php?XDEBUG_SESSION_START=komodo

then Komodo was invoked and I could step through the request, just like in Zend. Whee!

Note: I have confirmed that xdebug.so that is included with Komodo, which Komodo helpfully installs in whichever directory you specify during your time with the Debugger Config Wizard, does not work. That file has an MD5 of 8cca2df563529f950219a86cfadf2e48.

However, the version of xdebug.so I compiled does work.

This writeup dedicated to webchick, who allegedly has lost a good two weeks of her life dealing with remote debugging on Macintel.

P.S. I've tried this with MAMP 1.3.1 and it works fine. Also, it doesn't seem to matter which value I use for xdebug.idekey. Also, if you want to request some pages without the debugger firing up, turn off the Listener under Debug - Listen for Remote Debugger.

Helpful references:

Komodo 3.5 Debugging Documentation
Debugging Drupal with Activestate Komodo
xdebug documentation

[ Submitted by John on Wed, 2006-09-20 13:10. |

]

MapServer and Drupal

I've been working with MapServer a bit. I needed to spit out maps of states with counties painted different colors depending on a count. Wouldn't it be nice to have a function you could call and pass it the name of the state, an array of county-count pairs, a legend setting which count ranges get which colors, and a width and height? It'd be nice if it had a smart caching function, too.

So I present a tiny but fun maps.module, in a contrib cvs repository near you. And if you're a MapServer wizard, improvements are welcome.

[ Submitted by John on Fri, 2006-07-28 19:05. |

]

Nutch and Drupal

For the past five weeks I've been working with the Nutch open source search engine and web crawler. Nutch is at the point that Drupal was a year and a half ago. For Drupal, that "meant lots of potential," "poised for explosive growth," and "lacking in documentation." We had the first Drupal conference in February of 2005, and though we expected only a handful of people, many more showed up! I hear that a similar thing happened at the Nutch meetup recently.

Doug Cutting, currently at Yahoo!, is the lead developer. The Nutch project also resulted in an interesting distributed system called Hadoop.

Here's a site running Drupal as the front end and Nutch as the back end. There is currently work being done to integrate Drupal vocabularies and terms with Nutch's search.

[ Submitted by John on Sun, 2006-06-18 07:23. |

Drupal
Nutch

]

Book progress

I'm extremely pleased to note that Matt Westgate of Lullabot has agreed to be a coauthor on the book. I'm pleased not only because Matt brings a wealth of Drupal experience to this endeavor, but because I'll be having lunch with him more often.

[ Submitted by John on Thu, 2006-05-25 21:40. |

]

Pubcookie for Drupal 4.7

I've just committed a version of the pubcookie module that's compatible with Drupal 4.7. I also added a bit to the README to explain how the pubcookie module works:

When you click on the Log In link provided by the pubcookie block, it takes you to the directory you specified for "Login directory" under admin > settings > pubcookie (by default, 'login'). The pubcookie module takes this path, adds "pc" (an arbitrary string) to the end of it and -- and here's the key -- registers it as a menu item in the menu hook. So now http://yourdomain.com/login/pc is not a nonexistent file but a registered Drupal path that is "located" inside a directory that's protected by a .htaccess file restricting the contents to pubcookie-server-authenticated users. So when you reach that path, the pubcookie module receives a call to pubcookie_page() and goes from there.

[ Submitted by John on Tue, 2006-05-09 16:22. |

]

Script for automating Drupal installation

I do a lot of testing with Drupal, so I need a quick and easy way to create a new Drupal site, create the associated database, and get started. There are probably better solutions out there, but this is what I use. It's a bash script that I developed with the help of killes sometime last year. I just updated it for Drupal 4.7.

Now when I want to create a new Drupal site I just type

newdrupal47 foo bar

where foo is the name I'm giving the new site and bar is the name of the MySQL user (the MySQL user is optional; it defaults to root). It gets the Drupal 4.7 branch from CVS, configures the settings file, creates the database, optionally runs some local SQL, and opens Safari. Here's the script (it lost the indentation, oh well):

#!/bin/bash


if [ $# = "0" ]; then

  echo "newdrupal47: usage: newdrupal47 sitename db_user"

  exit 1;

fi
# You may want to set HOST to be your box's domain name

HOST='localhost'

DB_USER='root'

# If second argument is nonzero we were given a db_user;

# use it instead of defaulting to root

if [ -n "$2" ]; then

  DB_USER=$2

fi
# This is the location of an SQL file to run after the Drupal

# database has been given to MySQL. I use it to insert one

# line into the user roles table and one line into the user

# table, thus establishing the admin user.

LOCAL_SQL=~/newdrupal47.sql
# This is the location of your htdocs directory.

DIR="/Library/WebServer/Documents"

echo "Changing directory to $DIR"

cd $DIR
echo "Retrieving Drupal 4.7 branch..."

# Pull down drupal 4.7

cvs -z3 -d:pserver:anonymous:anonymous@cvs.drupal.org:/cvs/drupal checkout -r DRUPAL-4-7 drupal
echo "Configuring..."

# Rename the drupal site from "drupal" to whatever the first parameter was,

# e.g. newdrupal47 drupaltest results in a directory named drupaltest

mv $DIR/drupal $DIR/$1
# Make a copy of the default settings folder and name it localhost

# You may want to substitute your machine's DNS name

cp -R $DIR/$1/sites/default $DIR/$1/sites/$HOST
MYSQL_LOC=`which mysql`

if [ -x $MYSQL_LOC ]; then

  echo "Enter the database password for user '$DB_USER'"

  echo -n "Password: "

  read -s PASS
  # set local database connection

  # -i means edit file in-place

  # we search only lines 85-90 in the settings file

  sed -i '' 85,90s#username:password@localhost/databasename#$DB_USER:$PASS@localhost/$1# $DIR/$1/sites/$HOST/settings.php
  # set the base url

  sed -i  '' 108,110s#www.example.com#$HOST/$1# $DIR/$1/sites/$HOST/settings.php
  echo "Creating database..."

  mysqladmin -u$DB_USER -p$PASS create $1

  $MYSQL_LOC -u$DB_USER -p$PASS $1 < $DIR/$1/database/database.4.1.mysql

  echo "Checking for local configuration..."

  if [ -r $LOCAL_SQL ]; then

    echo "Found local configuration; executing SQL"

    $MYSQL_LOC -u$DB_USER -p$PASS $1 < $LOCAL_SQL

  fi

fi

echo "Done" #opens Safari to the new site on OS X open http://$HOST/$1

[ Submitted by John on Mon, 2006-05-08 15:38. |

]

Drupal 4.7 released

Two major projects have been released. The first is Drupal 4.7.

The second is code-named Nathaniel.

Would you believe that the first project actually took longer?!

[ Submitted by John on Mon, 2006-05-01 08:25. |

Drupal

]

Progress

I'm nearly ready to submit the first set of chapters to the publisher.

I'm also revisiting the publish and subscribe modules. Finished 4.6 and 4.7 versions coming soon.

I was able to hear Ray Kurzweil speak this past week at the Human Computer Interaction Forum I attended.

Baby coming soon, too!

[ Submitted by John on Sat, 2006-04-15 11:24. |

]

Search