I am new to Drupal and working with Drupal 8, I have not work in Drupal 7 or 6 so have less knowledge of it.
I am working on some dynamic fields of Drupal content type.
I have one content type attached with a vocabulary ( select list of terms ). I am using improved multi select (https://www.drupal.org/project/improved_multi_select) there.
Now I have some code in module which are creating vocabulary dynamically from some incoming API data.
I want, whenever my code create a vocabulary it automatically attached to field storage information that I am using in content type one.
You need to add target bundle to storage setting for this, Below code will help you.
/**
* Attach vocabulary to field
* #var $field_storage
*/
$field_storage = \Drupal::entityManager()->getStorage('field_config')->loadByProperties(['field_name' => 'field_machine_key']);
$field_storage = $field_storage['node.content_type_machine_key.field_machine_key'];
$settings = $field_storage->getSetting('handler_settings');
// $vocab_id will be your newly created vocabulary
$settings['target_bundles'][$vocab_id] = $vocab_id;
$field_storage->setSetting('handler_settings',$settings);
$field_storage->save();
See Complete Code Here
Related
I am trying to migrate files into a custom filetype with a lot of custom defined fields. However they seem to be getting migrated in the document filetype rather than into my custom created filetype.
I'm using the MigrateDestinationFile as my destination like this:
$this->destination = new MigrateDestinationFile();
I've tried to map the type like this answer suggested like this:
$this->addFieldMapping('type')->defaultValue('custom_file_type');
This solution doesn't work, when checking the mappable fields for the MigrateDestinationFile there is no type field specified so I think this is the reason why that solution doesn't work.
If some one could point me to an example of how to migrate into a custom file type that would be highly appreciated. Maybe I'm using the wrong destination? Or did I miss something very obvious.
The other part of the migration doesn't matter for this question.
Apparently I had two issues. The first one being that when we created the file type we called it file which for some reason you can't set as a migrate destination since it's already default in the MigrateDestinationFile constructor (see code below).
From file.inc:544
/**
* Basic initialization
*
* #param array $options
* Options applied to files.
*/
public function __construct($bundle = 'file', $file_class = 'MigrateFileUri', $options = array()) {
parent::__construct('file', $bundle, $options);
$this->fileClass = $file_class;
}
Second issue was the mapping to the field bundle itself. I simply had to set the correct destination like this after re-creating the file type with a different name:
$this->destination = new MigrateDestinationFile('product_download');
After doing this the migrated files where created in the correct content type rather than the document file type.
I am very new to drupal. I am using drupal 7. I have created a view and it is working fine. What i need to create my own custom filter in drupal view.I need to create my own custom filter in views. Please help me.
There is a hook available i.e. hook_views_data_alter() It will help you to create custom filter type. Below us the code
function my_module_views_data_alter(&$data) {
$data['node']['title_count']['title'] = 'Title word count';
$data['node']['title_count']['help'] = 'Count the number of words in titles.';
$data['node']['title_count']['filter']['handler'] = 'my_module_handler_filter_field_count';
}
Here my module name is my_module.
Here custom filter is being display in the filter list.
Hope it will help you.
I am integrating Drupal Webform with the CRM Highrise - I'm using the Highrise Drupal module (https://drupal.org/project/highrise) to create some mapping - however I want to extend the module to pass additional form values to the "background" field designated within Highrise, the issue I'm running into is that rather than passing the form value of say "Birthday Party" it's simply returning "array" in Highrise, below is the code I have right now:
//initial variable declaration
$form['#get_eventtype'] = drupal_render($event_type);
//making the call to post to Highrise
case 4:
$background = $form_state['values']['submitted'][$row['cid']];
$background .= $form['#get_eventtype'];
$new_person->setBackground($background);
break;
Have you dumped the value in $background after you retrieve it from the form? It is going to be an array and your value will be in one of the array elements. If you haven't already, I would suggest installing the devel module to help you dig into the form structure.
As a FYI I ended up just using Formstack.com - which gives you the ability to easily map custom fields created in Highrise with the form you create using Formstack. Upon creating a form with Formstack I embedded the JavaScript tag provided and was good to go.
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.
I looking for the best way to implement a block that lists all terms of a certain vocabulary. Each term should link to page that lists all nodes associated with that term. Any help would be greatly appreciated. Thanks!
See here for a great tutorial to achieve exactly what you want
http://chrisshattuck.com/blog/how-add-block-menu-tags-or-other-taxonomy-terms-drupal-site
The easiest way to approach this would probably be to use Views, and simply create a new view of the type "term". Here's a quick example which assumes that you have some basic familiarity with the Views UI:
Visit Views > Add (build/views/add), give your new view a name, and select Term from the "View type" radio buttons.
On the next page, start by adding a Taxonomy: Vocabulary filter and selecting your vocabulary in the filter settings.
Add a Taxonomy: Term field and enable the Link this field to its taxonomy term page option in the field settings. You might also want to remove the field's label, since this is just a simple listing.
You probably want your display to display all terms in your vocabulary, so change the "Items to display" 0 (unlimited). By default, new views only display 10 items at a time.
Check out the Live preview below to see if it's outputting what you need.
Add a new Block display using the dropdown on the left side of the Views UI.
Give your new block a name in the "Block settings" area. This is the description that will appear on Drupal's block admin page.
Save your view and visit admin/build/block to place and configure your block.
It's worth noting that Views does indeed have some overhead, but in my experience, its flexibility and ease-of-use far outweigh the relatively minor performance hit.
If you'd like to avoid using Views, you could write a pretty simple custom module using hook_block() and adapting http://drupal.org/node/247472. If you'd like, I can edit this answer with an example module based on that.
(Posting this as another answer, since this is a different approach than my first answer.)
As I mentioned above, here's another approach involving a custom module based on the code at http://drupal.org/node/247472. You could also just drop that code into a custom block with the "PHP" input format selected, but that's generally considered to be bad practice.
Add a new folder in sites/all/modules called vocabulary_block. Customize and add the following two files:
vocabulary_block.module
<?php
/**
* #file
* Exposes a block with a simple list of terms from [vocabulary].
* Each term is linked to its respective term page.
*/
/**
* Lists terms for a specific vocabulary without descriptions.
* Each term links to the corresponding /taxonomy/term/tid listing page.
*/
function vocabulary_block_get_terms($vid) {
$items = array();
$terms = taxonomy_get_tree($vid, 0, -1, 1);
foreach($terms as $term) {
$items[]= l($term->name, "taxonomy/term/$term->tid");
}
if(count($items)) {
return theme('item_list', $items);
}
}
/**
* Implementation of hook_block().
*/
function vocabulary_block_block($op = 'list', $delta = 0, $edit = array()) {
switch ($op) {
case 'list':
$blocks[0]['info'] = t('List of [vocabulary] terms');
return $blocks;
case 'view':
if ($delta == 0) {
$vid = 43;
$block['subject'] = t('[Vocabulary]');
$block['content'] = vocabulary_block_get_terms($vid);
}
return $block;
}
}
vocabulary_block.info
name = Vocabulary Block
description = Exposes a block with a simple list of terms from [vocabulary]. Each term is linked to its respective term page.
; Core version (required)
core = 6.x
; Package name (see http://drupal.org/node/101009 for a list of names)
package = Taxonomy
; Module dependencies
dependencies[] = taxonomy
Notes
Be sure to change $vid = 43; to
reflect the ID of the vocabulary that
you'd like to load. You can find the
VID by visiting
admin/content/taxonomy and looking at
the destination of the edit
vocabulary link for your
vocabulary. The VID will be the last
fragment of that URL:
admin/content/taxonomy/edit/vocabulary/[vid].
I wouldn't normally hard-code the
$vid into the module itself. However,
setting up the necessary Drupal
variable and administration form (to
allow users to select a vocabulary
from the Drupal interface) would be
overkill for this answer.
For your own documentation purposes,
don't forget to search/replace
[vocabulary] in those two files and
use your own vocabulary's name
instead.
This method may not necessarily be more performant
than the Views method I described
earlier, especially once you start considering caching,
optimization, etc.
Since performance is a priority,
I recommend thoroughly testing a
variety of different methods on this page and
choosing whichever one is fastest for you.