When a view with an exposed filter with a 'locked' operator is exported, the exported version of the view will show the operator as 'unlocked'.

During export, each options value is checked against the default value for that option; if it's a default value, the option does not get exported. The 'operator' setting for exposed filter options, though, is never the same as the default value, because it gets set by the expose_options() method as $this->options['id'] . '_op'. That would be fine, except that there is a snippet of code that sets use_operator to TRUE when 'use_operator' is not set but 'operator' is set--and with exported views, this is exactly the case (because of the default values behavior).

The snippet of code in question is in the views_handler_filter class's init method:

// Compatibility: Set use_operator to true if the old way of using
// the operator is set and use_operator is NULL (was never set).
if (!empty($options['exposed']) && !empty($options['expose']['operator']) && !isset($options['expose']['use_operator'])) {
  $this->options['expose']['use_operator'] = TRUE;
}

There are probably a couple of ways to address this; the attached patch implements views_handler_filter::expose_submit() and unsets the 'operator' value when 'use_operator' is falsey so that the 'operator' value doesn't get saved.

CommentFileSizeAuthor
#18 933716-6.x.patch917 bytesbojanz
#18 933716-7.x.patch948 bytesbojanz
#4 933716-4-views-export_exposed_filters.patch869 bytesbecw
#2 933716-3-views-export_exposed_filters-6.x-3.x.patch1.27 KBbecw
views-export_exposed_filters.patch1.05 KBbecw

Comments

dawehner’s picture

dawehner
Primary language German
commented
Version: 7.x-3.x-dev » 6.x-3.x-dev
Status: Active » Needs review

This should be a bug in 6.x, too.

becw’s picture

becw commented
StatusFileSize
new 933716-3-views-export_exposed_filters-6.x-3.x.patch1.27 KB

I confirmed that this is also an issue with 6.x-3.x. The same fix works--and the original patch applies with a little fuzz. If it's more convenient, here's a fresh patch against DRUPAL-6--3.

(edit: oops, used the wrong comment # in the patch file name, and I can't fix it now.)

dagmar’s picture

dagmar
Primary language Spanish
Location Argentina
commented
Status: Needs review » Needs work

I can confirm this bug, and the patch fix a part of the issue.

However, I found a case that is not covered.

To replicate.

Create a view with an exposed filter without operators.
Apply the patch.
Export the view.
Import the view with other name.

As you can see, the operator is locked again. So this patch work only if user 'save' the view after apply the patch. I think this should be fixed in the export and not in the filter submission.

becw’s picture

becw commented
Status: Needs work » Needs review
StatusFileSize
new 933716-4-views-export_exposed_filters.patch869 bytes

One alternative way to solve this is to force Views to export the 'use_operator' setting for filters; here's a new patch that fixes the issue that way, by changing the default value to FALSE instead of 0 (functionally equivalent, but since forms will return 0 for false, the filter setting will be 'different' according to the === operator). I think this is less sensible than the first patch.

Either way, views exported before this patch will need to be either edited (delete the 'operator' setting for filters without exposed operators) or re-exported.

Remon’s picture

Remon commented

subscribe

Hwangar’s picture

Hwangar commented

subscribing too...

blakehall’s picture

blakehall commented

Subscribing.

(And the patch in #2 seems to be working for me)

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

sorry for doing this, but subscribe

robertgarrigos’s picture

robertgarrigos commented

I had this problem with views-7.x. patch #2 didn't fix the problem, but it did it patch #4.

Will you commit this to views-7.x also? I've seen this issue (http://drupal.org/node/963010) for views-7.x tagged as duplicate of this one, so I don't know where to ask.

merlinofchaos’s picture

merlinofchaos commented

What if we just remove that compatibility code? It's 2 years old at this point, and dates back to pre 2.0 changes. I don't think it matters anymore.

robertgarrigos’s picture

robertgarrigos commented

I think it matters if you need to add a view to a feature. In this case you get this problem in D7

merlinofchaos’s picture

merlinofchaos commented

No no, I don't mean the patch; I mean the compatibility code that causes the setting to be changed.

i.e, what if we remove this:

// Compatibility: Set use_operator to true if the old way of using
// the operator is set and use_operator is NULL (was never set).
if (!empty($options['exposed']) && !empty($options['expose']['operator']) && !isset($options['expose']['use_operator'])) {
  $this->options['expose']['use_operator'] = TRUE;
}
merlinofchaos’s picture

merlinofchaos commented

Certainly in Views 3, that code is not necessary at all.

danielnolde’s picture

danielnolde commented

Okay, this flaw in views' exportables support caused many people unnecessary trouble over months (years?) and makes ugly form_alter-workarounds necessary (or you could fix it manually in the features file but would always get an "overridden" status...).

So what's the status?
Does either the patch from Rebecca in dev or the troublesome compatibility code out of dev, as proposed by Earl??

entrigan’s picture

entrigan commented

I commented out the lines in views_handler_filter.inc specified in #12, and this appears to have resolved the issue.

kehan’s picture

kehan commented

I have a features based set of modules which use views & exposed filters extensively. Above fix works for me too 7.x-1.x-beta3

daniel_j’s picture

daniel_j commented

Subscribing

bojanz’s picture

bojanz commented
StatusFileSize
new 933716-7.x.patch948 bytes
new 933716-6.x.patch917 bytes

Okay, let's do this (per #10)

damien tournoud’s picture

damien tournoud commented
Version: 6.x-3.x-dev » 7.x-3.x-dev
Status: Needs review » Reviewed & tested by the community

Just as the doctor ordered :)

klausi’s picture

klausi
he/him||they/them
Primary language German
Location 🇦🇹 Vienna
commented

Confirmed, patch solves the problem.

jsenich’s picture

jsenich commented

The patch works for me.

betz’s picture

betz commented

good

scor’s picture

scor commented

#18 worked for me in D7. RTBC++

merlinofchaos’s picture

merlinofchaos commented

Yes, let's kill this for all 6.x-3.x branches. Any views relying on this code are > 3 years old.

dawehner’s picture

dawehner
Primary language German
commented
Status: Reviewed & tested by the community » Fixed

Oh there are more then one 6.x-3.x branch ;)

Commited to both 3.x branches.

Bevan’s picture

Bevan commented

Confirmed fix in latest 7.x-3.x-dev release.

Status: Fixed » Closed (fixed)

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