Category: Development

So I’m putting the finishing touches on an UberCart 2 module, and I’m thinking it’s as good as it’s going to get. Then I go ahead and test it—the most visible test would be the creation of a custom node type and product class—and… no go. The class is created, but the node type isn’t.

After a bit of googling, I realised I’d been doing it the wrong way. My code just had straight db_query‘s to insert the records in {node_type} and {uc_product_classes}. Well, the latter may have been okay, but the former totally wasn’t. db_query does execute correctly, but at some later point the node_type is deleted. Unfortunately I can’t find the particular page that told me this anymore.

Using node_type_save() won’t help, either, since that just calls INSERT or UPDATE commands.

I’ve got options, though. Implementing hook_node_info() and hook_form(), for one, as detailed here. This means I don’t have the option of leaving the node type in the system until the module is uninstalled; also, it still doesn’t answer the question of creating a corresponding product class. I tried adding code to my hook_node_type() implementation to insert the class, but that just had the effect of not creating the node type while creating the product class. Weird.

Still, I’m feeling very positive. This isn’t the first bump I’ve encountered on my Drupal learning curve. Won’t be the last, either, as just today I started porting this module to UberCart 3 / Drupal 7. About time, too, I’ve been itching to dig into D7!

Here’s a little something I figured out just recently. Let’s say you have Ubercart installed. Let’s say also that you want to add a custom field to the uc_orders table. There are a couple of ways to do this.

One is to hack the uc_orders.install file’ and add the field to its schema definition. That seems untidy, and of course not upgrade-safe. Not to mention it won’t work if Ubercart is already installed. Wouldn’t you need to uninstall/disable uc_orders, drop the orders table, then reinstall it with the new scheme?

THere’s a better way, though. What I’ve done is write a separate module. Call it “mymodule,” just for originality. In mymodule.install, use db_add_field() like so:

mymodule_enable() {
  $ret = array();
  db_add_field($ret, 'uc_orders', 'newfield', array(
    'type'=>'varchar', 
    'length'=>50)
  );
}

Simple! So now I’ve added a field to the database. Calling uc_order_load() works fine: the new fields are part of the order object since it just reads from the orders table; however, calling uc_order_save() will not update the new field.

There’s one more thing I needed to do. uc_order_save() calls drupal_write_record(), which depends on the schema. So mymodule needs to add its new field to the schema, using hook_schema_alter():

So what you do is write the following in mymodule.module:

mymodule_schema_alter(&$schema) {
  $schema['uc_orders']['fields']['newfield'] = array(
    'type' => 'varchar',
    'length' => 50,
    'description' => 'custom field',
  );
}

And it works! I’m wondering if I could put this code in the .install file instead, in mymodule_schema(). Would that work? None of the documentation I’ve read says anything pro or con.

Most of my Drupal experience in the last year has been either purely back-end development, or superficial front-end stuff: JavaScript, AJAX, tweaking templates and styles, that sort of thing. But in the last couple of weeks, in two different small-scale projects, I’ve been digging more into theme development, menu management, and various other issues site admin issues. It’s fascinating stuff, though hard to wrap my head around. Plain old development on the Drupal platform was a lot more straightforward, at least to me. Still, it’s good to get out of my comfort zone, right?

Here’s one particular problem I dealt with, which I had a hell of a time googling for: the client wanted to change the content type descriptions on the “Add Content” (/node/add). It took me some trial and error and googling to find out that’s taken from two places:

1. The content type description, as set in each Content Type.
2. Overriding that if they exist, the descriptions of the “Add Content” menu item’s children.

There are still a lot of things I’m figuring out, like how to change the text on top of the Add Content page. Seems a simple thing, right? Maybe it is if you know how, but I don’t. It’s definitely not the menu system, though interestingly the menu item description does display as expected on its parent menu page…

Consider this problem: you want to disable a few fields on the node edit screen for particular node types. Let’s say the body, although this could apply to any and all fields. The reason for this is that for our client’s e-commerce system, the products are synched from an external POS system, and most fields should not be touched AT ALL… and certainly shouldn’t be overwritten with content copy-pasted from MS Word, which has happened a few times and prompted us to take preventative measures.

I should clarify that at least one field (images) does still need to be editable, which is why we’re not just taking away edit permissions altogether.

Okay, so I’m not saying what follows is the best solution, just what I came up with, inspired by a Stack Overflow thread I can’t seem to find right now. It uses hook_form_alter() to (a) hide the body edit field group, and (b) replace it with static markup displaying the body content. I thought about replacing it with a disabled textarea, but in Firefox, for instance that’ll show up with a medium grey background that really doesn’t look very good.

$CONTENT_TYPE = 'product'; 
function MODULE_form_alter(&$form, $form_state, $form_id) {
  if(isset($form['#node']) && $form_id == $CONTENT_TYPE . '_node_form') {
    $form['displaybody'] = array(
      '#value' => '' . $form['body_field']['body']['#title'] . ':
' . $form['body_field']['body']['#default_value'] . '
',
      '#weight' => $form['body_field']['#weight'],
    );
    $form['body_field']['#access'] = FALSE;
  }
}

A few notes:

Line 3: I’m not really sure what the first condition is for. At first I thought it was to cover only editing existing nodes, but that doesn’t appear to be the case. The second condition is to cover only certain node types

Lines 4–10: we insert a new form element, ‘display body’. It will show the body field label and content, and will be have the same weight as the existing body field, so it shows up in the same position on the screen.

Line 11: This hides the body field, unconditionally.

But what if we wanted to allow some users to edit that field? That’s certainly doable, but it gets a bit awkward. I could use hook_perm() to create a special permission—call it ‘edit body’—and replace line 3 above with:

if(isset($form['#node']) && $form_id == $CONTENT_TYPE . '_node_form' && !user_access('edit body')) {

However, that permission would show up in my own module’s section, not with the other uc_product permissions, so that’s a bit annoying. I could hack uc_product.module, but that’s not really a good solution. If there were a way to add to a third party module’s permissions, that would be very awesome!

I’ve been working with Drupal a lot in the last few months, and enjoying the hell out of it. Every day I’m learning some new tidbit, some interesting new scheme that at first seems confusing, but them usually makes me go, “Wow, that’s brilliant!”

Forms, for instance. Drupal offers a nice API to build and process forms; hook_form_alter() lets your modules modify forms defined in other modules, by adding fields, removing fields, even changing the back-end logic. At first I thought all this hook could do was fields, and I looked for something like hook_form_validate_alter(). But no, the real solution is even more elegant:

mymodule_form_alter(&$form, $form_state, $form_id) {
  if($form_id == 'form_whatever') {
    $form['#validate'][] = 'mymodule_form_validation';
  }
}

The $form['#validate'] looks like it contains an array of functions to be called when validating the form (likewise for $form['#submit'], I think). Simple and beautiful. The best part is, nothing is overwritten. Any module may alter any given form, and all their functions will be run. (The order in which they’re run can also be set: turns out modules have weight). I’ve thought for a while that Drupal seems ridiculously over-engineered, but that’s its strength: it allows developers to try out all sorts of crazy schemes like this. The more I learn about Drupal, the more I respect it.