Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
This happens on the update.php page, following the 'continue' button on the form.
I get:
Notice: Undefined index: entity type in views_handler_field_entity->init() (line 39 of /var/www/html/sites/all/modules/views/handlers/views_handler_field_entity.inc).
with the latest stable version of views module.
This did not happen in 3.0-rc2 and earlier.
When I do a drupal_set_message() in the said line of code for when the said array key does not exist, I get:
table = Array ( [group] => Killfile [join] => Array ( [node] => Array ( [left_field] => nid [field] => nid ) [users] => Array ( [left_field] => uid [field] => uid ) ) )
Which is from the killfile module.
The problem here is killfile does not use an entity, so why is views module trying to look for a an entity type when there is none?
What should be done here?
Should I be defining an 'entity type' of 'node' in the appropriate place in killfile.views.inc file?
Comment | File | Size | Author |
---|---|---|---|
#10 | patch-1364064-10-views-7.x-3.x-undefined-index.patch | 955 bytes | INAScon |
Comments
Comment #1
Hardik C CreditAttribution: Hardik C commentedHi,
Please try with this code:
<?php
/**
* A handler to display data from entity objects.
*
* Fields based upon this handler work with all query-backends if the tables
* used by the query backend have an 'entity type' specified. In order to
* make fields based upon this handler automatically available to all compatible
* query backends, the views field can be defined in the table
* @code views_entity_{ENTITY_TYPE} @endcode.
*
* @ingroup views_field_handlers
*/
class views_handler_field_entity extends views_handler_field {
/**
* Stores the entity type which is loaded by this field.
*/
public $entity_type;
/**
* Stores all entites which are in the result.
*/
public $entities;
/**
* The base field of the entity type assosiated with this field.
*/
public $base_field;
/**
* Initialize the entity type.
*/
public function init(&$view, &$options) {
parent::init($view, $options);
// Initialize the entity-type used.
$table_data = views_fetch_data($this->table);
$this->entity_type = $table_data['table']['entity type'];
}
/**
* Overriden to add the field for the entity id.
*/
function query() {
$this->table_alias = $base_table = $this->view->base_table;
$this->base_field = $this->view->base_field;
if (!empty($this->relationship)) {
foreach ($this->view->relationship as $relationship) {
if ($relationship->alias == $this->relationship) {
$base_table = $relationship->definition['base'];
$this->table_alias = $relationship->alias;
$table_data = views_fetch_data($base_table);
$this->base_field = empty($relationship->definition['base field']) ? $table_data['table']['base']['field'] : $relationship->definition['base field'];
}
}
}
// Add the field if the query back-end implements an add_field() method,
// just like the default back-end.
if (method_exists($this->query, 'add_field')) {
$this->field_alias = $this->query->add_field($this->table_alias, $this->base_field, '');
}
$this->add_additional_fields();
}
/**
* Load the entities for all rows that are about to be displayed.
*/
function pre_render(&$values) {
if (!empty($values)) {
list($this->entity_type, $this->entities) = $this->query->get_result_entities($values, !empty($this->relationship) ? $this->relationship : NULL, $this->field_alias);
}
}
/**
* Overridden to return the entity object, or a certain property of the entity.
*/
function get_value($values, $field = NULL) {
if (isset($this->entities[$this->view->row_index])) {
$entity = $this->entities[$this->view->row_index];
// Support to get a certain part of the entity.
if (isset($field) && isset($entity->{$field})) {
return $entity->{$field};
}
// Support to get a part of the values as the normal get_value.
elseif (isset($field) && isset($values->{$this->aliases[$field]})) {
return $values->{$this->aliases[$field]};
}
else {
return $entity;
}
}
return FALSE;
}
}
Comment #2
dawehnerI would say this is already fixed in 7.x-3.x-dev
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedNo, not fixed. The only change is the line # for the error.
I can resolve this by going to my hook_views_data implementation and adding $data['mytable']['table']['entity type'] = 'some entity' and then clearing the cache tables. However, the entity type parameter isn't documented at http://api.drupal.org/api/views/views.api.php/function/hook_views_data/7.
What should the value represent?
Comment #5
thekevinday CreditAttribution: thekevinday commentedIn my case, killfile is associated with a node, so I used 'node':
$data['killfile_nodes']['table']['entity type'] = 'node';
But this is merely a guess because killfile is not a node entity at all.
It is simply extra data to associated with a node.
Perhaps the proper solution is to define a custom entity type for the killfile module?
I still suspect what I am doing is a workaround and not a solution.
As @earnie mentioned, there is indeed is a lack of documentation problem that is making this harder to figure this out than it should be.
Comment #6
Anonymous (not verified) CreditAttribution: Anonymous commentedI found the following in help/api-upgrading.html
I then went looking at some of the implementations in core via api.drupal.org, e.g. http://api.drupal.org/api/views/modules%21book.views.inc/function/book_v..., and find that 'entity type' isn't specified in some of them.
Comment #7
Kars-T CreditAttribution: Kars-T commentedDear fellow Drupal enthusiasts,
This issue is now lasting for a very long time in the issue queue and was unfortunately never solved. As Drupal is a open source project, everyone is helping on a voluntary basis. That this was not solved is nothing personal and means no harm. But perhaps no one had time to deal with this issue, maybe it is too complex, or the problem was not described comprehensibly.
But this issue is not the only one. There are thousands of issues on Drupal.org that have never been worked on or could not be processed. This means that we are building a wave that is unmanageable and it is a problem for the Drupal project as a whole. Please help us keep the issue queue smaller and more manageable.
Please read again, "Making an issue report" and see if you can improve the issue. Test the problem with the current Core and modules. Maybe the problem doesn't exist anymore, is a duplicate or has even been solved within this issue but never closed.
Help can also be found for it on IRC and in the user groups.
In order to close this issue, I have set this issue to "Closed (won't fix)".
If there is new information, please re-open the issue by changing the status to active.
--
This issue was edited with the help of Issue Helper
Comment #8
deanflory CreditAttribution: deanflory commentedI'm not using the killfile module and I'm getting this error:
Notice: Undefined index: entity type in views_handler_field_entity->init() (line 44 of /.../sites/all/modules/views/handlers/views_handler_field_entity.inc
Drupal 7.26
Views 7.x-3.7+20-dev
Comment #9
tomarnold2 CreditAttribution: tomarnold2 as a volunteer and commentedHmm. I'm getting this error on line 44 in the latest update to VBO.
I updated line 44 to be the following to help me get past this:
was: $this->entity_type = $table_data['table']['entity type'];
new: $this->entity_type = (isset($table_data['table']['entity type'])) ? $table_data['table']['entity type'] : null;
Bit of a newbie here, so I welcome a more correct patch.
Comment #10
INAScon CreditAttribution: INAScon commentedFWIW: the cause of this issue begins at hook_views_data, where it is perfectly OK not to define an 'entity type' for a table entry. This however generates the error notification that the index 'entity type' is missing (obviously).
For example, the module simplenews causes this issue; see: simplenews_views_data where the table simplenews_mail_spool is defined, having only indexes 'base' and 'group' (and no 'entity type').
Even without this index 'entity type' everything seems to work fine, so the patch is rather simple: only use the index if it exists.
Hope this helps anyone still bumping into this problem (like I did).
Comment #11
dat deaf drupaler CreditAttribution: dat deaf drupaler as a volunteer commentedI can confirm the patch has fixed this issue. Thank you @INAScon!
Comment #12
g33kg1rl CreditAttribution: g33kg1rl commentedPatch in #10 fixed the issue for me as well.
Comment #14
DamienMcKennaCommitted. Thanks.