CCK's standard "Display Fields" settings are good for configuring per-content type field visibility and can save a lot of custom coding time. If a field is shared over a dozen content types, however, a change to one has to be made to the others, and that's a lot of clicks.

The Content Type Selector module adds a little dropdown to the right of the tabs on the CCK settings pages. So you change the field settings on one content type, pick the next type in the dropdown, change it there, etc. It's still a lot of clicking but it's a few seconds trimmed with each page and feels more seamless.

On a site we're starting to build, Drupal's core "Sticky at top of lists" functionality isn't necessary (using Nodequeue for lists), but nodes need to be included or excluded from search results on a per-node basis. Rather than create a custom CCK field, and since we're building search (as usual) through Views, I decided the simplest answer was to rename "Sticky" to "Appear in Search Results," and filter accordingly in the view.

So how to do this? hook_locale() only works on non-English languages (see t()) and seems to define groups rather than strings.

The simplest solution, it seems, is to use settings.php (or in this case, a common.settings.php used by all the others). Like so:

$conf['locale_custom_strings_en'] = array(
	'Sticky at top of lists' => 'Appear in search results',
);

I've started using and loving the Popups API module. It allows other modules to create lightbox-type ajax popups of other pages and forms. Out of the box, it includes the option to convert several admin UI pieces into popups, like the Configure Block links, Taxonomy Add/List/Edit links, etc. Saving a few seconds here and there adds up to a lot of time!

(Note: Make sure to set the Content Selector in your theme settings (/admin/build/themes/settings/themename). The default is strange, but in most themes div#content should do it.)

One of our clients has a simple enough request. They wanted a PDF form to be populated in with a set of values gathered from a web form. We decided to settle on xfdf as a method to do this.

I wasn't familiar with xfdf, but was pleased to discover it is an easy format.

<?xml version="1.0" encoding="UTF-8"?>
<xfdf xmlns="http://ns.adobe.com/xfdf/" xml:space="preserve">
<fields>
  <field name="firstname">
    <value>Dan</value>
  </field>
  <field name="lastname">
    <value>Cocos</value>
  </field>
  <field name="email">
    <value>dan@echoditto.com</value>
  </field>
</fields>
<f href="example.pdf"/>
</xfdf>

Now that the xfdf problem was solved we had to move on next to adding the fields to the PDF. We were unable to find suitable PHP libraries to handle it. Luckily there is a free and open source Java* library iText that does all of this and more.
Miles an EchoDitto intern took the first crack at it and had a working example in no time. A little bit of code clean up and voila a short while later a working tool to merge form data into a PDF.

*There is also a C# port for those so inclined.