Drupal 9 Computed Fields Module - drupal

I installed the computed fields modules and I'm trying to make a computed field hook for the below.
But I am not sure whether I put the code in the right place.
I just added the code below to the existing compute_field_api.php that comes with the compute field module. Is this the correct place to put this hook?
It doesn't seem to work and it doesn't display.
function computed_field_field_rating_average_compute($entity_type_manager, $entity, $fields, $delta)
{
// Get rating fields to compute
$facilities_and_services = $entity->field_facilities_and_services->value;
$fairway_rating = $entity->field_fairway_rating->value;
$recommendable_to_friends_rating = $entity->field_recommendable_to_friends->value;
$food_rating = $entity->field_food_rating->value;
$value_rating = $entity->field_value_rating->value;
$english_rating = $entity->field_english_rating->value;
$layout_rating = $entity->field_layout_rating->value;
$quality_rating = $entity->field_quality_rating->value;
$greens_rating = $entity->field_greens_rating->value;
$length_rating = $entity->field_length_rating->value;
// Set Computed field value
$value = ($facilities_and_services + $fairway_rating + $recommendable_to_friends_rating + $food_rating + $value_rating + $english_rating + $layout_rating + $quality_rating + $greens_rating + $length_rating) / 10;
return $value;
}
I tried to clear all the caches after adding this code. But it doesn't seem to work.

Had the same issue. Had to do the following:
Installed the module per the readme instructions (follow those).
Create the computed field function as you have above inside an enabled module (you may need to create a custom module for that). Note that the name of your custom module should not precede the function name (so it shouldn't be mymodule_computed_field_field_rating_average_compute, but rather as you have it above - i.e., how you've written your function is fine).
Flushed all caches.
Edit and save the node(s) where the new value should appear. That causes it to create a row in the field table.
After that, the computed value should appear in the saved content, and in views for that resaved content.
Note that it doesn't seem to be dynamic (like the old dynamic fields in D6 used to be), so it won't just magically appear for all existing content. To achieve that en-mass, I had to do a bit of back-end SQL to avoid having to manually re-save every entity (didn't want to do that for over 120 of 'em). Still figuring out if I have to do some other trickery to keep the field up-to-date despite my cache settings, as the value I'm attempting to display is dynamic, and not dependent upon the node in which the field exists...

Related

Fetching translated allowed_values of non-translatable list_string field

I'm attempting to get the allowed_values of a non-translatable list_string field. The allowed_values of this field are translated though and we want to get those allowed_values into a specific language & not the current UI one.
Here is my draft attempt:
// Override language before loading field configuration.
$this->languageManager->setConfigOverrideLanguage($this->languageManager->getLanguage('fr'));
// Load the field configuration in the language forced before.
$field_info = $this->fieldConfigStorage->load('profile.customer.field_title');
$label = $field_info->getLabel();
$allowed_values = $field_info->getSetting('allowed_values');
// Dump values for debugging.
dump($label);
dump($field_info);
dump($allowed_values);
With my current code, I get the proper forced label (here fr) but when I use the ::getSetting('allowed_values') I receive the allowed_values in the current UI language instead of forced one.
Does any one have any idea ?
Many thanks.

premake5 adding new complex fields

I am trying to add a new premake5 field in my premake5 script but am having trouble understanding how to specify the field.kind .
I want to add a field that contains a list of (path, string ) pairs but can't work out how to specify the kind spec .
The documentation and examples are not particularly clear.
This is how I have registered my new field
premake.api.register( {
name = "mypathmappings",
scope = "config",
kind = "list:path:string", or "list:keyed:path:string"
}
)
and inside of a config scope I declare the field item like so
project myproject
mypathmappings { ["path/to/file1"] = "stringvalue1", ["path/to/file2"] = "stringvalue2"}
However when it comes to processing time I don't get what I'm expecting in the field:
function processpathmappings(cfg)
local pathmappings = cfg.mypathmappings
for path, value in pairs(pathmappings) do
--do something with the path and value but
--value is not a string as expected
end
end
Can someone explain how the complex kinds can be built up correctly from the field kinds registered in api.lua?
I get that "list:integer" specifies a list of integers but don't know how the "keyed" element works for example.
Right now, it is not possible to control the "kind" of the keys in a keyed value. The best you will be able to get with the current system is kind="keyed:string", which should give you the values (the strings) that you want, but the paths will not be processed by Premake (made absolute, etc.)
If it is feasible, you might want to flip it around to kind="keyed:path" and set the values like this:
mypathmappings { ["stringvalue1"] = "path/to/file1" }
But that relies on your string values being unique within a map.
In theory, Premake's field API could be extended to support kinds of keys; feel free to open a ticket or submit a pull request.

Theming view for multiple value field

I know this is probably a n00b question but I've searched everywhere for an answer and havent found anything.
I have a CCK multiple value field for "Features" where a product can have a random number of multiple features entered for it. I am editing the view so I can style the output of the features on the product page.
Right now in my view I can output the entire list of features at once using:
<?php print $fields['field_features_value']->content ?>
This will give me a list all the features given for a product. But what I want to do is loop through and pull out each individual feature and format/style it separately. How exactly would I do this?
I ran into this yesterday again, and spent hours trying to Google the syntax, to no avail.
I was able to get this to work, but I must admit it is not the best way. It is duplicating some of the work that Views has already potentially done for us, and should be considered a brute-force approach.
My use case involved theming each filefield file in a node separately, per node-based row:
<?php
// $Id: views-view-field.tpl.php,v 1.1 2008/05/16 22:22:32 merlinofchaos Exp $
/**
* This template is used to print a single field in a view. It is not
* actually used in default Views, as this is registered as a theme
* function which has better performance. For single overrides, the
* template is perfectly okay.
*
* Variables available:
* - $view: The view object
* - $field: The field handler object that can process the input
* - $row: The raw SQL result that can be used
* - $output: The processed output that will normally be used.
*
* When fetching output from the $row, this construct should be used:
* $data = $row->{$field->field_alias}
*
* The above will guarantee that you'll always get the correct data,
* regardless of any changes in the aliasing that might happen if
* the view is modified.
*/
?>
<?php
$output = explode('|', $output); // I've rewritten the field output in Views like this: [field_portfolio_image-field_name]|[nid]
$paths = $output[0]; // I've set filefield to show file paths rather than the file
$nid = $output[1]; // The NID is all that's really needed for this approach
$node = node_load($nid);
$slots = $node->field_portfolio_image;
foreach($slots as $prop) {
print ''.$prop[data][description].'';
}
?>
I used the Devel module heavily here (image reference for this example attached), in order to get the nested values I needed.
I know there is a better, proper way of doing this, rather than reloading the node data, since views should already have access to this upon page load.
When theming views is too specific I set conditions, relationships, parameters and all the views stuff except fields. The only field I use is node id.
Then when doing the theming I use...
$node = node_load($nid);
... to get the node object. You can inspect the node object with the dpm function that comes with the devel module.
dpm($node);
This "technique" works well for nodes and when you don't care about optimization or speed, because if you are going to do this with 1000 nodes you should load the nodes on batch.

Drupal 6: how to make CCK default values translatable?

In my multilanguage Drupal 6 website I need to make my CCK field default values translatable, i.e.
Hello - in the English version
Bonjour - in the French one
I cannot find this text with Translation Table, neither are these values in variable table so that I can use multilingual variables.
Do You know how to have different default values in different languages?
When you define the CCK field, you can enter a PHP code snippet to override the default value of the field.
Enter the following there :
return array(0 => array('value' => t('Hello')));
Now access a node add page with this CCK field from a non-English version so that it gets added to translatable strings.
Now you're able to translate it using the "Translate interface" menu (it might take a visit to the "create" page of your cck type first though). It doesn't require any extra modules in fact, just basic D6 (and it probably works in D5 and D7 as well).
This method is a bit of a hack. Im not sure I would deploy this without really considering the consequences. For a simple usecase it MIGHT be ok.
Create a custom module, lets say def_translate. To def_translate.module, add a function
function def_translate_nodeapi(&$node, $op, $a3 = NULL, $a4 = NULL) {
if($node->type == "sometype"
&& $op == "load"
&& $node->field_some_cck_field_type[0]['value'] == "your default value")
{
$node->field_some_cck_field_type[0]['value'] =
t($node->field_some_cck_field_type[0]['value']);
}
}
Ok - so what is this doing?
When a node is loaded, hook_nodeapi gets called, with $op set to "load". This gives us an opportunity to do manipulate the node before it is rendered. Before we do anything we check
Is this the right type of node?
Is our op = "load"?
Is the value our default value?
What we then do is pass the existing default value through the t() function. This will make the default string available to i18n translation table, and you can then use the normal way of translating strings.
*DISCLAIMER*
I have not tested this myself in production. Im not entirely sure what the effects will be. You probably want to think this through before implementing it, and you probably want to put some features in to look up the default values from the DB incase they are changed in the CCK UI.
Hope this helps - or possibly shakes a hint of a solution to your problem!

How to change Drupal input filter behaviour based on output location

I have a Drupal filter module whose output I would like to alter, depending on where the output is going to be displayed. Specifically, I want to the filter to give the full output for nodes, but trim the content down for blocks.
I don't think this would be possible. It's hard enough to figure out what context something is being displayed in. It's doable but quite hard to code on your own. However the way the filter system works I don't think its possible within a filter to determine then context of the text being filtered. It's simply not made for something like that.
I'm the OP (but just registered an account).
I did manage to find a solution/workaround. Here's what I did:
Create block.tpl.php in my module which is a copy from system/block.tpl.php, with a constant added at the top.
Put my template file at the head of the theme registry using hook_theme_registry_alter():
function hook_theme_registry_alter(&$theme_registry) {
// using our own block.tpl.php file.
$theme_registry['block']['template'] = 'block';
$theme_registry['block']['path'] = drupal_get_path('module', 'module_name');
$theme_registry['block']['type'] = 'module';
$theme_registry['block']['theme path'] = drupal_get_path('module', 'module_name');
$theme_registry['block']['theme paths'] = Array();
}
Checked for the constant while constructing the filter output, changing as necessary.
Celebrated the outcome.

Resources