0

note: I'm currently exploring hook_entity_property_info_alter and clearing the cache forcibly by truncating the cache table as I've had many iterations of work on this over the years. (Though I wouldn't recommend you trying that and if you do, back up first!)


I've defined entities in hook_entity_info. But when I have I get differing results and none of them work in Views as I was hoping.

"Paid subs" doesn't give me control of individual fields and therefore allow me to mix one field here with another of a joined entity there. But it does give fairly decent information.

This is its definition in hook_entity_info:

$info['paid_sub'] = array(
    'label' => t('Paid subscription'),
    'plural label' => t('Paid subscriptions'),
    'description' => t('company paid subscriptions (in theory
        this could be just postage or the full cover price etc.'),
    'base table' => 'company_paid_subs',
    'entity keys' => array(
        'id' => 'psid',
    ),
    'uri callback' => 'entity_class_uri',
    'entity class' => 'PaidSubEntity',
    'controller class' => 'PaidSubEntityController',
    'admin ui' => array(
        'path' => 'admin/paid-subs',
        'controller class' => 'PaidSubEntityUIController',
        'menu wildcard' => '%paidsubentity',
        'file' => 'paidsubentity.admin.inc',
    ),
    'module' => 'company_subs',
    'access callback' => 'paidsubentity_access_callback',
    'label callback' => 'paidsubentity_label_callback',
    'views controller class' => 'EntityDefaultViewsController',
);

paid subscriptions

Paid subs setup in Views

Add fields paid subs in Views

Configure field paid subs in Views

Resulting view in paid subs



Subscription

This one: "Subscription" doesn't do anything remotely useful.

hook_entity_info code:

$info['subscription'] = array(
    'label' => t('Subscription'),
    'plural label' => t('Subscriptions'),
    'description' => t('A subscription (as opposed to
        user registrations, paid recipients of magazines, promo readers etc.)'),
    'base table' => 'subscription',
    'entity keys' => array(
        'id' => 'sid',
        'revision' => 'revision_id',
    ),
    'entity class' => 'SubscriptionEntity',
    'controller class' => 'SubscriptionEntityController',
    'module' => 'company_subs',
    'access callback' => 'subscriptionentity_access_callback',
    'label callback' => 'susbcriptionentity_label_callback',
    'revision table' => 'subscription_revision',
);

Subscription setup in Views

Subscription add fields

Configure field Subscription

Resulting view in subscription

Is it because I have been overriding default configurations? What's the cause? Ideally I'd like to be able to select individual fields within an entity rather than having to rely on a rendered entity because I'd like to be able to select one field from one entity and another from another entity by using joins in hook_views_data_alter, like this (which worked just fine until I stopped defining each field in hook_views_data and turned the bespoke tables into entities specifically to try and utilise the extra functionality of core and contrib modules etc.):

$data['subscription']['user_id']
['relationship']['handler'] = 'views_handler_relationship';
$data['subscription']['user_id']
['relationship']['base'] = 'users';
$data['subscription']['user_id']
['relationship']['base field'] = 'uid';
1

1 Answer 1

0

If you've tried conventional approaches and they haven't worked (like me) then you might find that there are a few things that you need to do:

Firstly for me was truncating the cache table just to get rid of a whole heap of old data from previous iterations of my designs. Then it was simply defining hook_entity_property_info as suggested. To check if things are working you can debug and use hook_views_data_alter(&$info) and check out the variables. You'll probably see views has two varieties (unless I'm still doing something wrong):

entity_subscription and views_entity_subscription...

entity_subscription Array [3]   
    table   Array [2]   
        group   Subscription    
        entity type subscription    
    user_id Array [4]   
        title   user id 
        help    user id of registrant   
        field   Array [2]   
            handler entity_views_handler_field_entity   
            type    user    
        relationship    Array [5]   
            handler entity_views_handler_relationship   
            base    entity_user 
            base field  uid 
            relationship field  user_id 
            label   user id 
    magazine_id Array [4]   
        title   magazine id 
        help    magazine id of this subscription    
        field   Array [2]   
            handler entity_views_handler_field_entity   
            type    magazine    
        relationship    Array [5]   
            handler entity_views_handler_relationship   
            base    entity_magazine 
            base field  mid 
            relationship field  magazine_id 
            label   magazine id 
views_entity_subscription   Array [1]   
    rendered_entity Array [3]   
        title   Rendered Subscription   
        help    The Subscription of the current relationship rendered using a view mode.    
        field   Array [3]   
            handler entity_views_handler_field_entity   
            type    subscription    
            real field  entity object   

And then as is suggested a whole heap of different places, those fields will be available and if you go to "Relationships" in the Views config then you can also add other entities and their properties. For example 'user' as is the case with "entity_subscription" above, defined by specifying "type" as "user".

Oh, and also - the views_entity_subscription was just a rendered entity, I presume this is for a direct entity/views use, for example when creating a view just of that entity type.

One final thing: the entity api module itself actually has, in the folder within that module called 'modules' (i.e. sites/all/modules/entity/modules/...) a whole heap of hook_entity_property_info() for the main (core) Drupal entities. This means you can open user.info.inc for example and see how the module authors wrote the entity_property_info for the user entity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.