Scenario:

* two vocabularies: functionality and product type. Product type has a term reference field to functionality (field_functionality).
* a content type named products sharing field_functionality and also with a term reference field to product type (field_product_type).

Create a view called "x" and:

1. Added Filter criteria: Taxonomy term: Functionality (field_functionality)

2. Added Filter criteria: Content: Product type (option limit) (field_product_type)

3. Check: Filter criterion: Field: Functionality (field_functionality)

4. Click Apply & continue

5. crash with

An AJAX HTTP error occurred.
HTTP Result Code: 500
Debugging information follows.
Path: /admin/structure/views/ajax/config-item-extra/x/page/filter/field_product_type_tid_option_limit
StatusText: Service unavailable (with message)
ResponseText: PDOException: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ')) AND (field_data_field_functionality0.deleted = '0') AND (taxonomy_term_data.v' at line 2: SELECT field_data_field_functionality0.entity_type AS entity_type, field_data_field_functionality0.entity_id AS entity_id, field_data_field_functionality0.revision_id AS revision_id, field_data_field_functionality0.bundle AS bundle
FROM 
{field_data_field_functionality} field_data_field_functionality0
INNER JOIN {taxonomy_term_data} taxonomy_term_data ON taxonomy_term_data.tid = field_data_field_functionality0.entity_id
WHERE  (field_data_field_functionality0.field_functionality_tid IN  ()) AND (field_data_field_functionality0.deleted = :db_condition_placeholder_0) AND (taxonomy_term_data.vid = :db_condition_placeholder_1) AND (field_data_field_functionality0.entity_type = :db_condition_placeholder_2) ; Array
(
[:db_condition_placeholder_0] => 0
[:db_condition_placeholder_1] => 2
[:db_condition_placeholder_2] => taxonomy_term
)
in field_sql_storage_field_storage_query() (line 577 of /var/www/venexma.xsto.info/htdocs-dev2/modules/field/modules/field_sql_storage/field_sql_storage.module).
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

jonhattan’s picture

On inspecting the SQL I see the error is at

WHERE (field_data_field_functionality0.field_functionality_tid IN ())

I figure out that's caused because of the live preview.

jonhattan’s picture

Further testing reveals the error is gone if I Select terms from vocabulary Functionality in the first exposed field. Also, It is not related to exposing the filters or not.

Now that is not failing, it doesn't work :p
The option-limited exposed field doesn't react to changes in the matching field.

Anonymous’s picture

FileSize
62.61 KB

yep, same problem here. also if I'm not selecting any terms from dependee filter - I get this (attached png) on the created view page. I'm using 7.x-1.0-beta1

Anonymous’s picture

@jonhattan have you figured out how to fix that issue?

ykyuen’s picture

i have the same problem.

Anonymous’s picture

I guess everyone have it, here the quote from the code)

// Here we probably need to switch out depending on whether we are:
// a filter, an exposed filter, or an argument.

// Case: filter.
// This is the only one in my use case at the moment; if you want more
// post a patch ;)

joachim’s picture

It's always a good idea to have a browse through the source code when you find a bug ;)

So, is there anyone able to work on a patch for this?

Anonymous’s picture

Unfortunately I haven't got needed programming skills, all I can is to test a patch on several sites!

Anonymous’s picture

Priority: Normal » Major

Hey Joachim, could you please make a patch for this? As I understand there's something about 10-30 lines of code need to be added, I can pay for your work time =) Really need this to be done as soon as possible...

joachim’s picture

Status: Active » Needs review
FileSize
1.68 KB

Could someone try this patch please?

You'll need the latest version from git to apply it on, as I've made other fixes there today too.

Anonymous’s picture

Just tested it. Exposed filter (with option limit) is limiting only when I'm selecting value from matching field and applying it with a button, otherwise it doesn't react to changes in matching field and stays empty.

jonhattan’s picture

I confirm #11. It lacks ajax, that's the big challenge here.

Also, when using it as a exposed filters, there're two warnings because the filter values are not set on first page load. I fixed it with isset() in attached patch.

joachim’s picture

Ajax inside Views form is going to be a nightmare.
I briefly tried with D7 core #ajax and it doesn't do anything at all.

jonhattan’s picture

Ajax and views are not my forte.

I did try to accomodate the exposed form to leverage the code in the hook_form_alter and it simple does nothing. Attached the patch for reference, although it's mostly garbage.

In the following comment I'll comment out about the patch.

jonhattan’s picture

Sorry wrong patch. Here it goes.

jonhattan’s picture

Status: Needs review » Needs work

For this patch to "work" (not raise any warning) the filter identifiers must be changed to meet the field name, so for example an auto assigned value of field_functionality_tid must be changed to field_functionality and field_product_type_tid_option_limit renamed to field_product_type.

This is so because the hook_form_alter implementation wants the form items to be named the same as the fields. It was just a proof. The idea I had in mind is to refactor the hook_form_alter once I got it working with this scam.

+++ b/reference_option_limit_handler_filter_limited_options_term_reference.incundefined
@@ -94,15 +99,42 @@ class reference_option_limit_handler_filter_limited_options_term_reference exten
+      foreach ($this->options['options_limit_fields'] as $olf) {
+        $type = substr($olf, 0, strpos($olf, ':'));
+        $field = substr($olf, strpos($olf, ':') + 1);
+        $field_match = $this->view->{$type}[$field]->definition['field_name'];

This is the quick way I found to get the other field. Perhaps there's an api for that?

+++ b/reference_option_limit_handler_filter_limited_options_term_reference.incundefined
@@ -94,15 +99,42 @@ class reference_option_limit_handler_filter_limited_options_term_reference exten
+        // Here we're altering other field. Is this legitimate?
+        $form[$field_match][LANGUAGE_NONE] = array('#default_value' => $form[$field_match]['#default_value']);

The comment says it all. It would be no longer a problem if I don't try to leverage hook_form_alter.

+++ b/reference_option_limit_handler_filter_limited_options_term_reference.incundefined
@@ -94,15 +99,42 @@ class reference_option_limit_handler_filter_limited_options_term_reference exten
+      $settings = array(
+       'field' => $this->definition['field_name'],
+        'fields_match' => $fields_match,
+        'entity_type' => $this->view->base_table,
+        'entity_bundle' => 'article', // TODO !

I found no way to get the bundle.

jonhattan’s picture

This issue explains a way to do ajax within exposed filters form #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback

joachim’s picture

Status: Needs work » Fixed
FileSize
2.04 KB

Thanks for the fix to my patch in #12!

I want to go for a slightly different approach of $match_values always being populated.

Committing this patch.

Issue #1532124 by jonhattan, joachim: Fixed error in views with exposed filters as controllers.

Let's move the AJAX stuff to another issue (that is, if anyone's got the stomach for it!). Marking this as closed.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.