drupal

I like Espresso from MacRabbit for server-side scripting a lot. The latest version (2.0) has merged a wonderful code editor with the best-of-the-class CSS editor, giving one awesome, unified experience. And, of course, you can edit your files directly over an SSH connection (the latter, alas, is not as straightforward as it is in Panic's Coda, but, well, we love both of them for different reasons).

Nothing in this life is perfect, however. One glaring shortcoming of Espresso is: no UI for assigning a syntax highlighter to custom file extensions. Espresso recognizes most common file extensions, but if you do something slightly different, e.g.: use .tpl files in Drupal (which are PHP files) or use Handlebars templates in Javascript (which are basically HTML), you won't get default syntax highlighting because Espresso does not know what type of files these are.

Let's see how we can teach Espresso custom file types. I will do this for .handlebars files, which are template files I use for my Javascript coding.

1. Right-click on Espresso.app in Finder and select: "show package contents".
2. Go to folder: Contents > SharedSupport > Sugars
3. Right-clic on "XML-and-HTML.sugar" and select: "show package contents".
4. Open Languages.xml for editing (with vi, Textmate or whatever your favorite text editor is)
5. Scroll down to detectors section which should read something like:
   

   <detectors>
     <extension>html</extension>
     <extension>htm</extension>
     ...
   </detectors>

6. Add more extensions to the section, e.g. for handlebars, I added:
   

   <extension>handlebars</extension>

Drupal uses extended version of SimpleTest for automated testing. It provides two parent classes for test cases: DrupalWebTestCase and DrupalUnitTestCase. Documentation describes the DrupalWebTestCase as the one appropriate for "typical Drupal tests". However, a quick look at its setUp method is enough to notice that when this class is used a lot is done at each test run, including a lot of pretty slow database work.

MacRabbit's Espresso (http://macrabbit.com/espresso/) has been my favorite editor for server-side scripting for a while now. I was an avid Coda user before that, and Coda is a fine editor, but I like several features of Espresso better (e.g. large file browser in the center and ability to simultaneously open files from any number of servers).

Espresso is much "younger" than Coda and it was a little behind on language support (and availability of plugins in general), initially. We even had to post a hacking instruction for how to "teach" Espresso Drupal files. (UPDATE: new instructions at: http://freshblurbs.com/espresso-and-syntax-highlight-custom-file-formats)

The situation is much different now. There's a wonderful abundance of quality plugins now at http://fileability.net/coffee/ that work like a charm. We are using Combined Python&Jango, JQuery, YAML and Drupal-PHP sugars and they are simply awesome. To install, all you need is download appropriate tar.gz, unarchive. rename resulting folder so it has extension .sugar and move that to ~/Library/Appplication Support/Espresso/Sugars

Ack is a recursive grep-replacement Perl script that you can download from: http://betterthangrep.com It is somewhat similar to "egrep", but is much smarter and has ten times nicer output format. It also automatically ignores annoying .svn files and you can teach it different file types.

If you are a Drupal developer you need to put the following line in your /etc/profile:

export ACK_OPTIONS=--type-set=php=.php,.module,.inc,.install

After which you can enjoy yourself some:

ack --php "check_plain"

Acquia and Phase2 Technology will be hosting Tattler (app) and OpenPublish™ Webinar tomorrow Wednesday, September 23, 2009 1:00 PM - 2:00 PM EDT.

To sign up visit: http://bit.ly/2nypWj

There has been increasing amount of complain about how Drupal is ugly or not designer friendly yadda, yadda, yadda. Well, sure - it's not WordPress, because it is much more complex and used for building much more complex websites. Neither do I, personally, think should it try to copy WordPress. Whilst there's always room for improvement, Drupal and WordPress have very distinct niche areas that each should strive in and not try to compete with each other.

But, for the skeptics that think Drupal is just Garland, check out the new, shiny, semantically powered The New Republic [http://www.tnr.com/] website built using the OpenPublish distribution of Drupal. And it was built in a matter of couple months with a small team and without any crazy work hours.

Drupal is awesome and Drupal can be pretty.

> perl -i -pe 's/oldname_/newname_/g' `find | grep "\.module$"`

Or if you want to first check the results:

> perl -pi.bak -e 's/oldname_/newname_/g' `find | grep "\.module$"`

which will create backup of original files. Those you can delete later with:

> find . -name "*.bak" -exec rm -rf {} \;

You can replace ".module" with ".inc" or "tpl\.php" if you also need those processed

If you have misfortune of having to upgrade Drupal5 website to Drupal6, there's a very good chance that at some point you will run into a fatal error:

Fatal error: Unsupported operand types in...

Fatal errors are never fun, but this one is particularly annoying and hard to hunt down. It helps to understand the cause of the problem, thought. Basically, the main problem is that Drupal url() and l() functions have changed their signatures in a major way. Function operands that used to be literals are supposed to be an array now.

Solution

You need to hunt-down all url() and l() functions and change their signature to Drupal6-compliant format. The functions can be used (and causing problem from) multiple locations: a tpl.php file, a module file or a code in a block in the database! This last one is particularly troublesome to hunt down and can cause the most problem. We suggest disabling all blocks for the time of upgrade by running:

UPDATE blocks set status=0

Also, to find which function causes the problem. open includes/common.inc and at the begining of url() and l() function definitions paste following code:

    if (!is_array($options)) {
      echo "<pre>";
      $backtrace = debug_backtrace();
      var_export($backtrace);
      exit();
    }

Typically first function call in the backtrace is the offender function.

UPDATE: instructions for Espresso 2.0 at: http://freshblurbs.com/espresso-and-syntax-highlight-custom-file-formats

Espresso From MacRabbit (you may remember them for their splendid CSSEdit eidtor) is a new Web editor, for Macs, worth paying attention to. It handles the usual suspects: PHP, CSS, HTML, servers over SFTP, Amazon S3 etc with style out of the box and has numerous extensions for other things like Python, LUA, SQL, Regular Expressions etc. And it's only 1.x version, so you bet you can expect much more in coming versions.

One little shortcoming it had, for Drupal developers is that, there's no easy way to configure custom-for-Drupal PHP extensions: .module and .install to make Espresso recognize these as PHP files.

Joe Shindelar of Dreamformula has posted a nice blog post detailing the configuration of custom PHP extensions in Espresso.

Thank you, Joe!

Drupal requires its source documentation to be compatible with DoxyGen. If you are working on a large project, you want to install DoxyGen and run it on cron to have nice, up-to-date API docs.

Unfortunatley, if you install Doxygen via yum (or any other auto-updater, I assume) it installs a fairly old 1.4.x branch that is incompatible with Drupal. Specifically, it completely ignores the .module and .install files and has poor support for .inc, from what I can tell. That's because Doxygen does not realize these are PHP source files.

What you want to do is to install the latest Doxygen release (1.5.8 at the time of this writing). In the new version, the author of Doxygen has generously added a configuration tag that allows mapping of arbitrary file extensions with language types. The setting you need in your doxygen configuration file is: