The current issue I’m having is that nodes created by the aggregation module get their taxonomy stripped when they’re updated because of how another module uses the security functionality, which is just hilarious in a site that’s largely organized organically by taxonomy. So, after talking with the people I’m working for on the site, I ended up creating a simple PHP script to run through cron that fixes the issues ‘the hard way.’

If you check out this query…

function fix_object($name, $sqlcon)
{
  $query = "SELECT term_data.name name, term_data.tid termid, node.nid nodeid, node.title title FROM node LEFT JOIN term_node  ON ( term_node.nid = node.nid ) LEFT JOIN term_data ON ( term_data.tid = term_node.tid ) WHERE node.type = 'aggregation_item ' AND node.title LIKE 'Xxxxx " . $name . "%'";
 
  // Perform Query
  $result = mysql_query($query);
 // ... and so on...

You can see that this is a fairly normal sql query that looks for all the nodes of type aggregation_item and titled a particular pattern. Because of the way the joins are structured, that means that any nodes that have lost their taxonomies will have NULL for termname and termid. Those nodeids with NULL termids can then have the proper taxonomy entries stuffed back into them…

function insert_taxo_4_node($node_id, $taxo_id, $con)
{
  $query = "INSERT INTO term_node (nid, tid) VALUES (". $node_id . "," . $taxo_id . ")";
 
  $result = mysql_query($query);
  // Check result
  // This shows the actual query sent to MySQL, and the error. Useful for debugging.
  if (!$result) 
    {
      $message  = 'Invalid query: ' . mysql_error() . "\n";
      $message .= 'Whole query: ' . $query;
      die($message);
    }
}

I’m largely posting this up in case people run into the same problem — this is a hilariously simple fix for a difficult to fix problem in drupal, but it’s a generic information architecture issue of what to do when the system that you’re working on is unreliable. I should probably mention that the issues with security in drupal aren’t related to authentication, but instead are related to item ACLs denying access to things for strange reasons, and are not crucial security bugs in the OMG MUST PATCH NOW sense.

My current interests (this week) are macintosh development, semantics (RDF), embodied philosophy and category (Lakoff), drupal, iPhone development, good coding practices, and project lifecycle management (from soup to nuts.) My interests next week will be getting a website off the ground that I unexpectedly ended up owning after a contract fell through. That was suprising and not entirely pleasant, but will see what can be done to have matters turn out positively.

One part of this is taking a lot of content over email — the scientists creating a lot of the content on the site are in the middle of the North Atlantic. Because of this, I’ve been using the drupal module mailhandler for a lot of things that would normally be done directly through the site.

Basically, changing the comparison from $data[0]=='taxonomy' to a case-insenstive comparison:

 if ((0==strcasecmp($data[0],'taxonomy')) && !is_numeric($data[1][0])) {

allows users to send in messages and have their mostly unambiguous intention followed. This is, in general, a good thing, and reflects the general net protocol practice of “be conservative in what you send, be liberal in what you accept.’ This is a general guide to good behavior and successful implementation and is generally called the Robustness Principle. I advise everyone to check out RFC 1122, because it has many entertaining things to say about the nature of the Internet at the protocol level.

Anyway, so when you can actually figure out what the person meant to be doing, you should probably accept it. This is a generic problem that pops up every now and then with computers. Surprisingly often, it pops up with case sensitivity at the protocol level. Here’s another moment for me with that same issue from about 7 years ago in Apache SOAP:

I proposed changing it to:

for (int i = 0; i < pds.length; i++) 
{ 
    if (0 == propertyName.compareToIgnoreCase(pds[i].getName())) 
      { 
        return pds[i].getWriteMethod(); 
      } 
}

from:

for (int i = 0; i < pds.length; i++) 
{ 
    if (propertyName.equals(pds[i].getName())) 
      { 
        return pds[i].getWriteMethod(); 
      } 
}

This does more or less the same thing, but is in Java. This was a case where the apache implementation wasn't interoperating with the Microsoft implementation because the MSFT implementation had a different valid interpretation of the SOAP specification than the Apache server did. Both implementations had completely reasonable behavior, but when the MS SOAP implementation responded to Apache, it did so with its own capitalization semantics (based on COM -- PropertyName) instead of the Apache SOAP capitalization semantics (based on Java -- propertyName). So, this is an ongoing problem that keeps showing up again and again.

I appear to be destined to run into it and advocate for the robustness principle in every technology i use, apparently. Either that, or it's just a slow day and I'm rambling. ]]> http://www.corprew.org/blog/2008/04/04/being-liberal-in-what-you-accept-implementation-interoperability-semantics/feed/ 2