Grayside.Org - drupal6

Drush Snippets: Menu Trace

Grayside — Sat, 11 Aug 2012 19:08:54 +0000

Random snippet of the day, find out what modules are involved in building out a given menu route definition. When you type a URI into your browser, Drupal’s menu routing system connects that to your page content by processing the path into instructions for how to build the page.

To use this script, copy the text or clone from github as a file, make it executable. It will automatically run with drush php-script. You can use --verbose for “full array notation” of each module’s change to the menu route. Or you can just use --pipe to get a list of modules and go look at the code directly.

In theory this should work with Drupal 7, but I haven’t gotten around to testing it yet.

Terms:

Release: Organic Groups 6.x-2.3

Grayside — Wed, 28 Mar 2012 21:27:05 +0000

Today was the release of OG 6, Version 2.3

We have a fine assortment of changes (see the changelog), ranging across:

Extensive og.module commenting.
Views integration improvements.
Many “OG, what are you thinking?” bugfixes.
And even some performance enhancements.

This release covers three classes of issues:

The remaining low hanging fruit languishing in the issue queue over the last two years.
Lowish-hanging fruit that I had the time to finish myself.
Development of enhancements and bugfixes I ran into during the work hours.

As I presented last time, I have a bit of a manifesto on how I’m approaching changes to OG6. Unusual levels of conservatism have led to such oddities in a Drupal project as a function with a @deprecated tag.

There are still items in progress in the issue queue, but since most everyone has moved on to the fantastic Drupal 7 version of Organic Groups, there are very few people contributing their efforts. That’s fine, but you can start to expect most changes to OG6 to come by way of my own itches. I don’t use Notifications, I don’t use multi-group posting, I don’t use the audience widget. If you care about these things, please help the many people that share your plight and present some patches and reviews in the queue.

Terms:

drupal6

organic groups

Release: Organic Groups 6.x-2.2

Grayside — Fri, 13 Jan 2012 19:16:45 +0000

I have just tagged the first OG6 release since March of 2010.

We have a fine assortment of changes (see the changelog), ranging across:

New Hook API Documentation
Views integration improvements
Localization improvements
Miscellaneous areas of moderate interest

This release locks in some changes, clarifies the status of Notifications (sticking with the 2.x line for now), and sets up OG6 for a stable position to start looking at what should happen next. I’ve posted a sort of maintainer’s philosophy position on how I see OG6 moving forward, you can read it at the d.g.o address of Organic Groups. What does all that translate into for my next steps?

Well, aside from a few clear cases, it’s still very much up to the community. I’m going to focus on a few good patches, and see if I can help the groups.drupal.org-related issues, performance, and the Weirdness subqueues. I’m hoping to have enough cool stuff pulled together to release 2.3 in honor of Drupalcon Denver.

Terms:

drupal6

organic groups

D7 Upgrade Process: Backports to Close the Gap

Grayside — Wed, 17 Aug 2011 05:40:01 +0000

The following post originally appeared on the GoingOn.com blog.

After more than a year of continuous investment in GoingOn’s Drupal 6 platform, the idea of upgrading to Drupal 7 is incredibly daunting. We have custom modules from form behaviors down to the access layer, we have features encapsulating hundreds of exported components, and an aggressive feature release schedule that does not set aside 6 months for a complete rewrite of the codebase just for a new version of Drupal. What to do?

We’ve been playing around with the idea of iterating our Drupal 6 platform toward Drupal 7. By pulling markup, design patterns, APIs, and architecture in Drupal 7 down into platform incrementally, we hope to shorten the final leap that will come when upgrading the entire system.

Driving Current Drupal Version Closer to Expected Drupal Version

^{Usability metaphors in site architecture and development practices sometimes works.}

The extra work involved might well take more aggregate time to develop, but that time will be amortized across small, manageable pieces that can be more intelligently inserted into the development schedule.

Here are the backport opportunities we’ve identified:

Design Patterns

Vertical Tabs, Contextual Links, Toolbar, Elements, Contact

Many of the design patterns in Drupal 7 are available through a combination of backport modules and creative theming. The Toolbar module doesn’t have a backport, but peeking into the repository for the Admin Menu I spy something that makes it look like D7’s Toolbar.

By pulling these patterns from D7, we gain two benefits:

We can build out the rest of our user interface around D7 design assumptions, instead of D6 assumptions. This will save effort in a theme redesign and upgrade.

We can trickle D7 designs in front of our users, allowing them to adjust to a few changes ahead of time instead of waking up one morning to find a completely rearranged website.

Our use of Vertical Tabs liberally around node forms is not cutting edge, but has allowed us to package complex forms with a Drupal 7 pattern, instead of resorting to harder-to-maintain multi-step forms.

System Plumbing*

Drupal Queue, Admin Role, Password, File, Mail System, Simpletest

The flow of code that goes on under the hood has a few interface points where it is relatively easy to grab a D6 backport and make your modules look just a little more like Drupal 7 code.

Judging by an IRC chat I just overheard the files[] mechanism might be dropped for something simpler in one of the next few point releases.

I hadn’t realized until writing this that URL Alter was cooked into core. The ability to ignore the special rules around around custom_url_rewrite_inbound() and go straight for hook_url_inbound_alter() is great. It also makes our custom code using it D7 ready.

* For purposes of this post, plumbing refers to the flow of code and data between its storage and the rendering process. Pretty broad category.

Database & Performance

Pressflow, DBTNG, Cache Backport

You can get a lot closer to Drupal 7 performance behaviors simply by using Pressflow, which has held backports from and experiments for Drupal 7 for years.

Most members of the Drupal community are already well aware that if performance is important for your project, grabbing Pressflow is an easy and non-threatening win. By using it for D6, you will be coding against session handling that is closer to D7’s, as well as being able to make use of other performance enhancing systems, such as serving images via Varnish as an ongoing improvement across your upgrade process.

Contrib Backports

This is a category of another sort. Usually when you think about Contrib modules for D7, you are looking for the upgraded version of the modules you are already using. However, what if there is a D7 module you want to use, or at least, could use? The D6 version of that module has just become a backport to facilitate your upgrade path.

This is a good solution to deal with unmaintained modules that have since been eclipsed by more energetic projects, as well as custom code you don’t really want to see again. We’re pretty excited to start playing with the Boxes module for this reason.

I’m going to skip listing competing modules in which one has an upgrade path and not the other. The Similar Module Review group might have information that will help you find competing modules that may just be a cleaner path forward.

Thanks to Lullabot’s Friday Roundup (June 24th) for pointing out backports of Password, Contact, and File. Thanks to David Reid for creating and maintaining what seems like most of these modules.

So, did this work? We are still putting together the details of this plan. A followup post in a few months will report on how it goes. If you have thoughts about this approach to the upgrade, additional worthwhile backports, or alternate ideas on how to make the time for an upgrade, please post a comment!

Terms:

Node Form Dominos via Node Reference and Prepopulate

Grayside — Thu, 02 Sep 2010 20:47:04 +0000

I like Prepopulate. I like to have that pseudo-RESTful way of preloading a form to minimize the amount of work a user has to do to get to the point of submitting a form. But I also like clean URLs. This post reviews in detail a technique to use a single prepopulated nodereference field to prepopulate a bunch of other fields based on that reference. Since Prepopulate’s recent 2.0 release, it because a whole lot more difficult to use the Form API to work magic on what it provides.

I use this in conjunction with nodereference to tailor node forms for their relationship with the referenced node.

Step 1: Setting up your links

In order for anything to happen, first you need to shape your links properly. The way to use Prepopulate with Node Reference fields (any many others) has subtly shifted. In the case of nodereference, you now what your querystring to look like this:

edit[field_my_nodereference_field][∆][nid][nid]=[nid: ###]

Where ∆ is the delta of your field (probably 0), and ### is the Node NID.

Step 2: Set up a module

Create a new module, or use any old custom module you have laying around. Be sure it’s weight is higher than Prepopulate’s lofty “10”, because your module needs to react to what Prepopulate does. Read up on setting your module’s weight if need be.

You could avoid worrying about module weight if you wanted to wrangle the URL on your own, but at that point why are you using Prepopulate?

Step 3: hook_form_alter() and #after_build

This post won’t review how to use hook_form_alter(), but if you do not know about this amazing function, I am shocked. Go read up on it. Master it. And return here.

hook_form_alter() is great to change a form before it’s built. But Prepopulate now applies it’s changes after the form is built. That means you need to use #after_build to specify another function to come along after Prepopulate, grab the values it has applied, and make your changes.

function custom_form_alter(&$form, &$form_state, $form_id) {
  // You might want to put a check somewhere that this should only apply to
  // new users or new nodes. For example, if ($form['#node']->nid == NULL)
  $form['#after_build'] = 'custom_prepopulate_after_build';
}

Step 4: Grab the referenced node.

In order to inherit some values from the referenced node, you need to load it.

function custom_prepopulate_after_build($form, &$form_state) {
  $node = node_load(custom_prepopulate_nodereference_nid($form['field_my_nodereference_field']));
  if (empty($node)) {
    // Bad reference from prepopulate. Nothing more to be done.
    return;
  }
 
  // Do stuff to your form here.
 
  // DO NOT FORGET THIS!
  return $form;
}
 
/**
 * Get the nid from the string [nid: #]
 *
 * @param $value
 *  String containing the nid.
 *
 * @return
 *  Integer value of a prospective nid.
 * @see nodereference_autocomplete_validate
 */
function custom_prepopulate_nodereference_nid($form_field) {
  preg_match('/^(?:\s\*|(.\*) )?\[\s\*nid\s\*:\s\*(\d+)\s\*\]$/', $value, $matches);
  if (!empty($matches)) {
    // Explicit [nid:n].
    list(, $title, $nid) = $matches; 
    return $nid;
  }
  return NULL; 
}

Step 5: Time for dominos

Now that we have a code skeleton with all the data we need, we can start in with some magic.

Put things like this in the “do stuff” section commented in the code block above.

Title Inheritance

if (empty($form['title']['#default_value'])) {
  $form['title']['#value'] = 'Discussion of "' . $node->title . '"';
}

Taxonomy Inheritance

foreach ($form['taxonomy']['tags'] as $vid => $taxonomy) {
  if (!is_numeric($vid)) {
    continue;
  }
  if (empty($form['taxonomy']['tags'][$vid]['#default_value'])) {
    $form['taxonomy']['tags'][$vid]['#value'] = taxonomy_implode_tags($node->taxonomy, $vid);
  }
}

Was that complex?

Seems a bit involved, so I’m working out the best way to produce a helper module.

If what you want is to inherit values into your output, check out the Field Inherit project.

Terms:

prepopulate

drupal6

nodereference

Single Group Login Redirect

Grayside — Wed, 28 Apr 2010 21:39:37 +0000

Community.OA had a request for functionality that would redirect a user with a single group membership to that group’s homepage.

I packaged that functionality up as a Feature, so you can use it too. The oa_ prefix refers to the support for spaces_og/purl to generate a group URL.

Terms:

Freelinking 1.9 Release Sighted

Grayside — Sun, 28 Mar 2010 06:31:37 +0000

Freelinking 1.x was previously announced as feature-frozen, and the next thing to unsupported. Looking at the long development cycle for Freelinking 3 reaching stability, the issue queue was dusted off.

Freelinking 1.9 will fix a number of bugs in 1.8, and smooth out the transition to FL3. Please go on over to the Freelinking homepage and download the dev version to try it out.

Freelinking 1.9 will be released this week.

Terms:

freelinking

modules

drupal6

Overriding Prepopulate: Do Not Use hook_form_FORM_ID_alter

Grayside — Fri, 12 Feb 2010 19:31:30 +0000

> EDIT: As of Prepopulate 2.0, you cannot directly use hook_form_alter() anyway. See Node Form Dominos to learn about using #after_build to work with Prepopulated values. – 2010/09/09

The Prepopulate module works some great magic to preload forms from URL variables. But suppose you need some extra magic to modify the titles it puts in place?

You can always use hook_form_alter (and here is one of countless little tutorials on that).

If you already know about that, you might be someone that enjoys the use of hook_form_FORM_ID_alter(). If you do, you cannot use it to override Prepopulate-set fields. It turns out that regardless of module weight, hook_form_FORM_ID_alter is called before hook_form_alter for any given form, meaning that the more specific function will always set the value, then Prepopulate will come along and reset it to your URL value.

There is a nice issue (#300481) that details this problem, and hopefully will find itself fixed in Drupal 8.

Terms: