Providing users with source code

Re: code sanitation, you want to convert all of the special characters into html entities (stuff like < and >) in the computed field, so the output will display correctly when you print it in your tpl. Quick example:

In a computed field your node's fields are in a special object or array, can't remember what it's called, it's in the docs. So it would really be $element->your_field or some such.

Computed Code is the code that will execute to determine the value of the field. Display code is the code that will execute to render the output. Computed code stores its value in the value element of the field item inside the node. This allows the raw value to be accessible elsewhere, including in the display code. Display code could be as simple as just retrieving the stored value, but it gives you the opportunity to apply some additional output to it that you might not want used elsewhere (in another calculation, for example).

Say your content type had a numeric field 'field_cars' and another numeric field "field_trucks' and a computed field 'field_total_vehicles'. Computed code would do the calculation of cars + trucks, like this:

and Display Code would control how that value was rendered:

$node_field is a variable available to the code in the computed code block and is the field object that gets attached to the node after it's defined. $node is another variable that represents the entire node that this field is being attached to. You have access to any other portion of the node that has already been loaded (so any field that was defined before or has less weight than the computed field you're dealing with--if your computed field is the last/heaviest field defined for your content type, $node will contain all the other field definitions). Inside display code, $display is a variable that you assign the desired output to--when drupal renders the field, it will basically do a print $display. $node_field_item is another variable available to the display code that represents the item of the field being rendered. It is an array where the element with the key 'value' contains whatever was assigned to the value portion in the computed code. So display-code's $node_field_item['value'] equals computed-code's $node_field[0]['value'].

So, in my example, if you had 2 cars and 2 trucks, the computational portion would simply add 2 + 2 and store it in the fields first value. Note, this assumes those two fields referenced in the computation are single-value fields (field_cars[0] represents the first value). The display portion would take the value and wrap it in a div and your output would be '<div class="total_vehicles_computed_value">4</div>'

For your case, conditionally allowing republishing could be part of the computed code as well (e.g. if($node->field_allow_republishing[0]['value'] == 'Yes') $node_field[0]['value'] = 'Republish output goes here.').

I know very little about what's changed in d7; what I say here is based on just a cursory look at the documentation and the d7 version of computed field and a brief examination of $entity and the other variables available to computed code. It appears what's changed is that there's a language specification involved in the structure of the field. Generally it appears, field_machine_name[LANGUAGE_NONE][0]['value'] gets you the 'value' of the first (in multi-value fields) or only (in single-value fields) record of a field with the machine name "field_machine_name" in a language-neutral setting. I have no idea how translation fits into the picture here, but the computed code example provided by the module uses the constant LANGUAGE_NONE. Looks like $langcode and $entity_lang are two variables that might be useful in place of LANGUAGE_NONE if you're in a multi-language environment, but again, I'm not completely sure what's going on with the language aspect.

A few comments on the field structure: Some fields don't store a value--e.g. node reference fields store the nid instead of value (field_fieldname[LANGUAGE_NONE][0]['nid'] = 1234), although I think that may also be different in d7. Some fields store additional information besides value--e.g. date fields can store, among other things timezone (field_fieldname[LANGUAGE_NONE][0]['value'] = 2011-08-10, field_fieldname[LANGUAGE_NONE][0]['timezone'] = America/New York). For single-value fields, the number in the brackets is always 0. For multi-value fields, 0 represents the first value for the field, 1 represents the second, n-1 represents the nth value.

If you really want to know what you can reference in the computed code, you can examine the value of the variables available at the time Computed Code executes. I don't know of a good way of doing that inside the computed code block. Normally I'd suggest Drupal for Firebug, which you can use to print messages from anywhere in the php execution process to Firebug. When I tried it though, I got no output from within the Computed Code block. That code may be eval-ed in a way that makes its output unavailable to firebug. Drupal for Firebug might still be useful for you--if $entity is a node, you can examine the node section of the drupal firebug tab and you should see [field_machine_name] => array... If so, then $entity->field_machine_name is an array that will look like what you see inside that array output.

Ahh, I see. That makes sense.

I would look at Text Formats under configuration menu - creating a new one based on whatever is being applied to your node in standard display and then putting "Display any HTML as plain text" at the end should get you half way there. Then look at a function like check_markup or some such to apply that filter with php in your computed field.

Sorry this is more a point-in-the-direction post as opposed to a concrete example post, but all my projects are in planning or frontend stages and I haven't been deep in Drupal for a month or two. Hope it helps.