it would appear that views data export does not work with exposed filter, if the view is unfiltered a cvs file is created correctly but not when filter

any idea where to start looking

drupal 7.8 with views 3.x

tks
M

Files: 
CommentFileSizeAuthor
#25 patch_commit_dee0d45bbaba.patch2.52 KBJaceRider
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch patch_commit_dee0d45bbaba.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

are there any dependencies for views export, strange thing is that exposed filters work with firefox on a local system (not chrome)

when on a web server no outputs are generated only default views with no exposed filters

no errors generated - strange behavior indeed

M

Mhhh looks like you need mini-feeds selected so that exposed filters work - chrome and firefox now working

I am having the same issue.

Somes- where do I go to select mini-feeds? I am not seeing it in Mini-feeds option anywhere in the view. Thanks for your help.

Hello,

Same issue here, the filter is not taken into account when selecting one - hence my export is empty.
My data export display is attached to a page display. (which exposes the filter widget). There is no display setting that is overridden anywhere.

I try to export a view using an exposed filter but I always export the first page (There are 2 pages on the view).
I need to export all the view results,not only the first page.
Any suggestions?
Thanks

It works fine for me. Remember to set the pager settings and to inherit filters.

Same issue here, though seems to work when not exporting as batch.

Same issue here!! Please help!

@muhammadanaskhan,
can you confirm if you have the problem only with 'Batch export', of also with 'direct export' ?

I finally solved this with selecting ALL the displays the view has for the Data export.

I am facing problem even if I am doing batch export. It only works if there are no exposed filters. Have extensively tested this with different url settings. Currently am using the following format of the url as recommended below the url field:
path/%/%/feed. That is, place '%' for each of the exposed filters used in the views

Priority:Major» Critical

It doesn't work for me too. I have tried all types of configurations and other settings but nothing works for exposed filter.

It would be so great if some one could suggest some ideas to fix this issue.

Category:bug» support
Status:Active» Fixed

Sorry guys, so you need to edit the style settings, and make sure: 'Parent sort' is checked. This will cause the exposed filters to be inherited.
You only need to edit the path to insert '%' if you are using contextual filters in the view, not exposed filters.

I've tried this solution with the 6.x-2.0-beta6 and it is not working.

Status:Fixed» Closed (fixed)

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

Status:Closed (fixed)» Active

i'm using a csv export attached to a block display. I have 'parent sort' checked in the style settings, but the filter is not inherited. Could it be that it doesn't inherit filters from a block display?

Edit- I just tried it with a page display, no dice. The exposed filter simply isn't inherited.

Status:Active» Closed (fixed)

The key is to :
1) make sure that parent sort is checked in the display settings
2) have an identical exposed filter configured in the attached export display

Status:Closed (fixed)» Active

I have done the above in #17 and do get a CSV export now, but the resulting file doesn't always contain the correct data. I am using 'Remember last Selection' on the parent view for the fields- does that cause an issue?

For example, I get one view that looks great, and the subsequent views look like a mixture of searches.

I have a few different filters on a custom entity view, all are basic text fields, with two List (Select) fields.

"Name" is exposed and set to 'Contains'.
"Email" is exposed and set to 'Contains'.
"Invoice #" is exposed and set to "Contains".
"Status" is exposed and set to the types they can select.
"Type" is exposed and set to the types they can select.

While the View itself correctly filters no matter what I set, the exported CSV is entirely wrong. It only seems to get it right if I use the Email field. The filters are matched on both the View and the export view. I can't figure this out at all and is seemingly random.

If I use the Name field and nothing else, it returns all the results in the system, not the one on the view itself.

Update:

I had a field filter in the view twice, once exposed, and the other to filter out values that were blank (not exposed).

I removed this filter from both views, but in the parent view, the filter field name was still filter_field_name_1. I had to delete this field and add it back to get filter_field_name. Then, the view began to work. Still seems like a bug..

If some of you use caching for the views, that might be a cause. See #1055616: Query arguments should be replaced before generating cache ID

Hi,

I was also have the same problem witj 6.x version. The csv output file was not respecting the filters applied by exposed filter. After playing around, I changed one setting. Under "Data export settings", I set Batched export: No. And now the csv output file is rendering correct results!

Its been a while, but I think it still has a problem with multiple filters that are the same. Example, an exposed filter for 'Name' but another filter for 'Name' not exposed, and defaulting it to not be 'John Smith'.

I recently added the views data export module and experienced the same problem with the export dumping out all of my table values, not the filtered set.

Solution #17 Worked for me! I had everything set up identically (mostly) to my main view; the only difference was that I did not expose my filters on the data export view. Once I exposed them the csv/xls exports the filtered table view. Thanks for the tip tbenice.

This should really be part of the documentation, the two screen shots are fine but more could be provided.

Version:7.x-3.0-beta5» 7.x-3.x-dev
Status:Active» Needs review
StatusFileSize
new2.52 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch patch_commit_dee0d45bbaba.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

I was having trouble getting exposed filters to impact exported content when batch mode is chosen. It worked great without batch mode but it seems the query is lost when performing a batch.

The attached patch fixes this issue for me.

Status:Needs review» Needs work

The last submitted patch, patch_commit_dee0d45bbaba.patch, failed testing.

The patch over on #1871560: Exposed input not set on batch exports fixed my issue. Appears that these issues are one and the same.

Status:Needs work» Closed (duplicate)

As per #27 I'm marking this as a duplicated of #1871560: Exposed input not set on batch exports

On 7.x-3.0-beta6 I found #17 works in a situation where the main display is paged, provided you also ensure the Pager setting on the Data Export display is set to "Display all items".

Distilling the wisdom from above: (into what worked for me as well)

STEP 0 :: EXPORT your view and save that to make a backup of your view you can re-import should this not work

STEP 1 :: copying your existing display

If you have a PAGE view of whatever it is you want (may work for other displays like BLOCKs) and that display is very complex, rather than adding every field from your existing display to the new display and making sure all the exposed filters are identical on both, you can export the view thusly: (if your display is simple, then you can just recreate it if you like and skip to STEP 2)

1) Add a 'dummy' DISPLAY->DATA EXPORT to your view (so you can see the parameters of the data export handler)
2) CLONE your complex PAGE display and name it accordingly
3) Export the ENTIRE VIEW into a text editor
4) Search for the string '/* Display:' and ... :

COPY the important bits of the DATA EXPORT HANDLER parameter from your exported view:

/* Display: DUMMY Data Export */
$handler = $view->new_display('views_data_export', 'Dummy Data Export', 'views_data_export_1');

to your existing display handler:

/* Display: My Awesome CLONED Query */
$handler = $view->new_display('page', 'My Awesome Copied Query', 'page_4');

To create:

/* Display: My Awesome EDITED Export */
$handler = $view->new_display('views_data_export', 'My Awesome NEW export', 'views_data_export_1');

NOTE: depending on how many views_data_export pages you have, you may have to change the value of 'views_data_export_1' above to something larger. If you use the same number as the DUMMY display you delete, you'll be fine.

then DELETE the display part of the view that is the dummy DATA EXPORT DISPLAY

STEP 2 :: Telling the newly minted DATA EXPORT DISPLAY to pay attention to the exposed filters
(FROM 17)
1) make sure that parent sort is checked in the display settings
2) have identical filters configured in your export display (you will if you did STEP 1)
3) attach the EXPORT display to your QUERY display.

STEP 3 :: Profit.

Well Done buddies we have succesfully used your method of changing the handler for the cloned page and the csv works fine for exposed filter which is date in out case, the exposed filter works fine.thanks very much.

Confirm selecting "parent sort" does cause exposed filter to be set correctly. As mentioned in Comment #17

Issue summary:View changes

#30 works beautifuly. Thanks for this.

Not very useful, nor easily supportable, if #13 is the only solution.

Will this bug be resolved in versions beyond 7.x-3.x-dev?