Generic entity support

We can support my_entity_type/%entity_object my using hook_entity_view_alter instead of hook_entity_view.

Attached is a patch that is working on my local.

Sorry, there's a parse error in that last patch...

Update attached.

Here's an updated patch that won't throw php notices when viewing a node.

This seems like what I need, but I can't apply the patch, there is no 7.x-3.x-dev branch, and the patch throws an error when applied to the 7.x-3.x branch so I don't know how to apply it except by hand... thankful for any hints.

Update: Ok so I applied it "by hand" and it works brilliantly, didn't solve my problem however. (The problem being to be able to set a context for when a referenced product in drupal commerce has a certain taxonomy term).

I've re-rolled the patch against latest 7.x-3.x code.

I'm interested in the entity type and bundle context, and that appears to be working fine. I haven't tested the entity taxonomy functionality much.

Thanks,
-mike

Ultimike's patch from #6 was missing the two new files, so I recovered them from #4.

Should the list of entities include things like menus, taxonomy_vocabulary, etc? How about excluding anything that doesn't have a 'view modes' ? I also think that for entities which have a bundle label the same as the entity label, e.g. users, it should just show the entity label.

This is what the patch from #8 looks like showing two Bean types, three EntityForm types, three Field Collection types and two content types:

Did this patch ever work for taxonomy terms tagged with other taxonomy terms... to explain:

I'm using Omega and Delta to create different layouts for my site (showing sidebars or not, different sidebar widths etc).

I'm building around the concept that there will be a taxonomy for Topics and Layouts taxonomies like so:

This would pull in all content regarding say IT into a page with say articles in the main content region and an events view on the right, whereas the no sidebar one for HR might just have the events above the articles in the content region.

Basically the term within Topics has a taxonomy term reference to choose a Layout term which would allow editors the ability to add a new Topic and set the layout without having to come to me to ask me to update the contexts to include the path to their Topic:

I've created a delta for each of those options in the image above and set up contexts for them to fire using the Entity Taxonomy condition from the patch in #8 but the condition isn't met for some reason. Any reason why taxonomy terms (which are entities if I recall correctly) tagged with a term for Layout don't match the condition for Entity Taxonomy.

I've used both patched versions of 7.x-3.1 and 7.x-3.x-dev but I get the same result every time.

@Chris Graham: Your request is regarding the fields on a specific entity, not the entity itself, so at the very least should be a different issue.

@DamienMcKenna I am completely confused, based on the descriptions within the patch and what Taxonomy conditions used to do before the split into Node and Entity variations, the patch you gave in #8 should be working for my use case based on what it says in #1:

Adds a entity type condition (checks entity type and bundle), and a entity taxonomy condition (supports taxonomy reference fields on any entity). [sic]

I figured the patch would include taxonomy terms given that they are core entities with a view mode and you only excluded entities with no view mode. Maybe I didn't explain it well enough so I'll try again using the descriptions for each of the new conditions:

Node Taxonomy: Set this context when viewing a node with the selected taxonomy terms

I have a content type of article, I add a term reference field to my layouts vocabulary. When I add an article I tag it with "Single column" and voila the context condition of Node Taxonomy: "Layouts > Single column" is met so, when I view the node, the single column layout shows with no sidebar (default theme has a right sidebar).

Now onto the entity version, which is where I am getting confused:

Entity Taxonomy: Set this context when viewing an entity with the selected taxonomy terms

So, as I understand it, here is a way to have a context condition (like what we have for user and node entities) on any entity that has a term reference field. I add my Topic vocabulary, manage fields (like I did with the article content type) and add a reference field to the layouts vocabulary.

I then add a context with a condition of Entity Taxonomy: "Layouts > Single column" and set the reaction to fire my single column delta. (Pretty much the same context as the one for articles, just changed the condition).

I add a topic term of IT and tag it with "Single column". I go to view the term page... sidebar still showing... What am I missing? Is it not the intended behaviour to allow any entity with a term reference field to load a context based on the term reference as a condition?

I added a Devel dsm($plugin) into context_entity_prepare_view in context.core.inc to see which plugins were being called on the term page, but the only one being invoked is context_condition_taxonomy_term.

I even tried the Entity Type condition to force a single column on all Topics and it lists Taxonomy Term: Topics as an option but if I set up a context to even load a block on the page it doesn't work, so why list it as an available option? What does it apply to if not the term page for terms under the Topics vocabulary?

Figured it out... couple of problems.

/**
 * Implements hook_entity_view_alter().
 */
function context_entity_view_alter(&$build, $type) {
  $object = menu_get_object($type);
  if ($object && isset($build['#entity'])) {
    list($object_id) = entity_extract_ids($type, $object);
    list($entity_id) = entity_extract_ids($type, $build['#entity']);

    if (isset($object_id) && $object_id == $entity_id) {
      context_entity_condition($build['#entity'], $type, 'view');
    }
  }
}

The alter above uses menu_get_object() with no position parameter, so the $object is never defined as taxonomy paths are taxonomy/term/%.

This works to populate the object:

$object = $type == 'taxonomy_term' ? menu_get_object($type,2) : menu_get_object($type);

But I haven't checked other entities for their path positions so might need to be a switch.

The other problem then arises with using $build['#entity'] as it is actually $build['#term'] for taxonomy term entities.

The simplest solution I found was to use a separate hook_taxonomy_term_view call instead as it is a specific use case like nodes:

/**
 * Implementation of hook_taxonomy_term_view().
 */
function MYMODULE_taxonomy_term_view($term, $view_mode, $langcode) {
  if ($view_mode === 'full') {
    $object = menu_get_object('taxonomy_term', 2);
    if (isset($object->tid) && $object->tid === $term->tid) {
      context_entity_condition($term, 'taxonomy_term', 'view');
    }
  }
}

Now it works for taxonomy term entities with a term reference field. The Entity Type condition still isn't working for me, I'd need to look into that further to see why.

The patch from #8 works for me, thanks.

This patch applies but does not function for me on the latest context version. This would be a really nice feature to have!

The patch in #8 worked for me too. I'm using Context 7.x-3.6.

What about adding a "Set on entity form" option just like there is for the Node Type condition (with options of No/Yes/Only on entity form)? Otherwise I believe it's necessary to write a custom condition to accomplish this.

Ah, I see that my comment is mentioned by @DamianMcKenna in the referenced issue (https://www.drupal.org/node/2002862#comment-7475868):

The only thing the patch doesn't provide is a condition for entityform submission forms, not just the display page.

Any thoughts on if this is expected to be included at some point in the future? Thanks.

The only thing the patch doesn't provide is a condition for entityform submission forms, not just the display page.

@ron_s try the latest Entityform 7.x-2-dev version. I think other changes in Entityform might have made it work with patch. Not sure haven't tested it yet.

@tedbow, the 7.x-2.x-dev version doesn't work, but it's due to the patch. I looked at the code in #8 a bit more closely, and there is no options_form function in the context_condition class within context_condition_entity.inc. Without the options form, it's not going to present any options to the user.

For example, this is what exists in context_condition_node.inc (http://cgit.drupalcode.org/context/tree/plugins/context_condition_node.inc), and there's no such function for entity support:

  function options_form($context) {
    $defaults = $this->fetch_from_context($context, 'options');
    return array(
      'node_form' => array(
        '#title' => t('Set on node form'),
        '#type' => 'select',
        '#options' => array(
           CONTEXT_NODE_VIEW => t('No'),
           CONTEXT_NODE_FORM => t('Yes'),
           CONTEXT_NODE_FORM_ONLY => t('Only on node form')
        ),
        '#description' => t('Set this context on node forms'),
        '#default_value' => isset($defaults['node_form']) ? $defaults['node_form'] : TRUE,
      ),
    );
  }

I've marked as "needs work" since this option is not currently supported by the patch, but if @DamienMcKenna and others feel this feature is acceptable without the options_form it can be moved back to "needs review."

I've created an updated patch based on what Damien wrote in #8. This leverages concepts in context_condition_node.inc to create an options form for the Entity Type condition. I've tested this with Entityform and Bean, and works well.

One area I would like to bring to everyone's attention is the changes made to the context_entity_view_alter function. I noticed the original code had no issues with entities that can be retrieved using menu_get_object, but ran into a problem with Beans. Beans are entities but also blocks, and their paths are defined by delta, not id.

So, I added some logic for the situation where an $object is not defined, then perform an entity_load using the entity key id. From there I check to see if delta is set, and if so I use it as a comparison option.

I'm not sure if this is the best approach, or if I might be missing some situations where this would not work correctly. I'd appreciate any feedback. Thanks.

------

PS: Not sure why the interdiff has some of the original code shown as removed and then re-added. Much of the code is the same as the #8 patch.

Not sure why the test is returning as failed... I manually performed the testCreateContext test and had no issues. These don't seem to be issues that are related to the patch, unless I'm missing something.

+++ b/context.core.inc
@@ -118,6 +118,38 @@ function context_entity_prepare_view($prepare, $entity_type) {
+  if (isset($build['#entity'])) {

This won't work for all entity types. For example, file entities store under $build['#file']

I don't know if this is related to the setup/use-case I'm working on, but this patch has resulted in a Notice.

Notice: Undefined variable: delta in context_entity_view_alter() (line 145 of /mypath/sites/all/modules/contrib/context/context.core.inc).

Attached is a new patch for review.

Patch #27 is no longer resulting in Notice. Thanks!

Otherwise, I can confirm that the patch seems to work as expected.

Could we add some test, please?

@hass, I'd like to, but unfortunately I'm quite busy at the moment. Can anyone help with some tests? Thanks!

We've found there is an issue with handling a few other entities like Fieldable Panel Panes. Attached an updated patch that provides a better solution. Please, review thanks.

The patch in #32 works like a charm for me.

Actually, never mind. This doesn't work for me when trying to set context on Entityform forms (to be used by Entityform Select View Per Context). Triggering the entity condition in the form #after_build seems to be far too late to be of use in this case, as the context is not set when the form is being built.

It seems like we might be able to check for this condition with a hook_entity_load() implementation, and get the context in place a lot sooner.

For PHP 7.3, there needs to be a minor change to the patch in 32. The evaluation order changed and the entity_load() call no longer gets valid data. The change is to explicitly evaluate the $info[$type]['entity_keys']['id'] first, then use it as the $entity property.

See the interdiff for details.