Drupal and the damned machines

The Greenman's occasional blog of Drupal discoveries and questions.

[damnedmachines-blog]

Drupal 7, Simpletest and Custom Languages

So, after setting up my own translations of drupal english, I decide it's time to run all my tests again...... and the whole system is broken. Every test gets aborted with some version of an error message starting with : Base table or view not found. No test will run. 

It turns out that drupal's core testing framework only works if you have your default language set to "en" - the core drupal english.

So far, it looks like the issue might be with us for a while. So I have written a drush command include module that will allow languages to be enabled and disabled, and the defaults set. 

[damnedmachines-blog]

Drupal 7: Custom Language and Fallback

If you want to change any of the core language strings in Drupal, you need to create yourself a new language. With your new language created, you then disable the core "en" language and set your new language as default. 

Here is the code that will create a new version of english, in this case "en-gb". Put this in your install file.

// Include the code if we need to 

 if (!function_exists('locale_add_language')) {     include_once 'includes/locale.inc';    }

// create a custom language

  locale_add_language('en-gb', 'Custom English', 'Custom English', LANGUAGE_LTR, '', '', TRUE, TRUE); // set this as our default language

  // disable the default english 

  db_update('languages')     ->condition('language', 'en')     ->fields(array(       'enabled' => 0,     ))     ->execute();

  // Changing the language settings impacts the interface.   cache_clear_all('*', 'cache_page', TRUE);

If you create a language after you already have some content, you might have some fields in the wrong language. This means that their data will vanish... unless you set up fallback. 

There is no core interface for fallback, so you need to implement a hook. I have done this: 

function [hook]_language_fallback_candidates_alter(array &$fallback_candidates){

  // fallback for default language to our custom language   $fallback_candidates['en'] = array('en-gb'); 

// let our local language fall back to original english   $fallback_candidates['en-gb'] = array('en'); 

}

This should allow any fields that are defined in the original "en" still be loaded if we request "en-gb". Since the fallback is not recursive, we can create a loop to allow us to callback the other way to. (Just in case) 

A little note: Language codes are case sensitive. 

[damnedmachines-blog]

Use the Drupal 7 registry!

My advice here is probably not yet valid, follow this issue for the real deal: http://drupal.org/node/996236

Drupal best practice summary

Always define your classes in include files

Always make sure you declare any include files in a module info file

Drupal 7 maintains a registry for all files that define classes. This allows it to make use of PHP's autoloading functionality. These PHP features help Drupal reduce it's memory footprint and speeds things up a little by not including files unnecessarily.

In early D7 coding, this registry applied to all code, but it got rolled back. Registries are useful, but they are tricky. If you move a file that is in the registry, or change the file in which a class is defined, you could run in to trouble.

Not using the registy however will get you into even more trouble. If your (non-registry) code defines an extension to a class that is defined in an autoloaded include, and that class moves - you are a bit screwed. There is no way Drupal can bootstrap far enough to be able to rebuild the registry. You have to get into the database and get your hands dirty.

If you define your classes in include files, the class will not be defined at bootstrap time, and you will be able to get the registry rebuilt with "drush updatedb".

[damnedmachines-blog]

How do I update Drupal7's file list

Fatal error: Class 'Entity' not found in .....

I keep hitting this problem: I update or move a module and everything breaks. Most of the time the issue is to do with Drupal's cache of files, objects and includes.

How do I update this list ? Unfortunately Drush is even more sensitive to this issue than core, so a drush script is probably not the best way to go.

Any ideas on how to re-build the file list ?

[update]

The worst offender with this is the object cache. I eventually managed to get the cache cleared by disabling the module that was trying to create an instance of an autoloaded object (og) , and then running "drush updatedb". Once that had run, the cache was clear, I could re-enable my modules with the new registry.

[damnedmachines-blog]

Drupal 7 EntityFieldQuery and Joins (delta_group)

Drupal no longer requires SQL! Yay!

You can no longer use SQL to list your data! What ?

Drupal developers are very used to using SQL to build lists of things. Yeah, views does lists a lot of the time, but, it's not always going to be the right way. Yes, Drupal now has a handy object orientated SQL layer - but that only works for the core tables - it does not work for fields.

Enter EntityFieldQuery.

When you want tp query on a field value, you create a new EntityFieldQuery object, and assign various conditions to it.The code below is used to select the members of an organic group.

We specify the type of entity we want, "user", and then we say that we want to look at the "gid" column of the "group_audience" field - and select on a specific gid.

Once executed, we will be returned an array of user entity ids, which we are then able to load (using user_load_multiple) and process further.

<code>

$query = new EntityFieldQuery;  

$query   ->entityCondition('entity_type', 'user')   ->fieldCondition('group_audience', 'gid', $gid);

</code>

Multiple Conditions

When you want to add multiple dependant conditions, you need to group your conditions into delta groups.If you don't use the groups, your conditions will not have anything to do with each other, and you might not get the results you are looking for.

A little example. The code below looks like it would select users with a specific group and a specific set of states. However, without a delta_group (the fifth parameter), the state and group are independant. So, if a user is in more than one group, the state returned may not correspond with the group specified.

<code> // This code will not produce the right results

$query = new EntityFieldQuery;  

$query   ->entityCondition('entity_type', 'user')   ->fieldCondition('group_audience', 'gid', $gid)    ->fieldCondition('group_audience', 'state', (array) $states, 'IN');

</code>

  Here is my current challenge with Drupal entity field queries.When you create a query object with two columns from the same field, the object will create two joins on the table. Unfortunately, this does not seem to get the results I need.

<code>

$query = new EntityFieldQuery;  

$query   ->entityCondition('entity_type', 'user')   ->fieldCondition('group_audience', 'gid', $gid)   ->fieldCondition('group_audience', 'state', (array) $states, 'IN');

</code>

Adding a delta_group to the statement means that the conditions are grouped together.

<code> // This code produces the desired results

$query = new EntityFieldQuery;  

$query   ->entityCondition('entity_type', 'user')   ->fieldCondition('group_audience', 'gid', $gid, '=', 0)   ->fieldCondition('group_audience', 'state', (array) $states, 'IN', 0);

</code>

[damnedmachines-blog]

You can't use SQL anymore! EntityFieldQuery takes over.

Drupal 7 now allows us to store data in any kind of backend database. Great! We don't have to use SQL anymore. 

But, wait.... if it supports different backends.... how do we find things ? We can't use SQL anymore.

All data queries need to use objects now. There is some documentation on using the next Generation DB stuff, but it still shows normal SQL selects. In practice, if you want to select based on field values, you can't do this.

So, instead we have to use the EntityFieldQuery object. This will perform you a search, and then return the entity ids you need to load.

// Load all the nodes in a specific group.

$query = new EntityFieldQuery; $entities = $query ->entityCondition('entity_type', 'node') ->fieldCondition('group_audience', 'gid', $gid) ->execute(); // just print them so we can have a look. print_r($entities);

Data is returned with the entity type as a key - but you can only select one entity type at a time.

Some problems on the event horizon

Unfortunatelty, at the moment, there is no way to page these queries! (And there is a chance there never will be for drupal 7! ) So, you can't use fields as important parameters if you want to browse by them. Well, not without some workarounds.

If you want to page on fields, you have two options, extract all the table information from the fields and then use the normal query system, or do a second query, and limit it to nodes returned in the field query.

I have gone the double query route, and done this:

$query = db_select('node', 'n')       ->fields('n', array('nid'))       ->condition('n.nid', $nids, 'IN')       ->extend('PagerDefault')       ->orderBy("field(n.nid,". implode(',', $nids).")") // keep original sort order       ->limit(12);     $paged_nids = $query->execute()->fetchCol();

A little bit of a roundabout, but thats what you get for trying to hang with the noSql kids and the Sql kids.